5 ms·

What I've learned about presenting backend demos to non-technical audiences: don't bother. They don't know enough to engage with it, and they're not going to kn

by chrsig 4y ago

What I've learned about presenting backend demos to non-technical audiences: don't bother. They don't know enough to engage with it, and they're not going to know enough to engage with it by the time you're done. That's not to say they wont be thankful for your work - if you solve one of their problems or a problem plaguing the company, definitely alert them to it. By slack or email. Get those virtual high fives. No need to gather people 'round to present.

r3trohack3r 4y ago
I'm not sure I agree. It depends on the reason for doing a demo - if it's just for high fives or a pat on the back, probably not a demo worth doing. But a company needs bottom up leadership as much as top down leadership. It's important that backend engineers be able to surface critical work up through the org chart to get buy in on technical direction. Budget doesn't just manifest and if you don't align incentives with your work through bi-directional communication you're going to find yourself eternally understaffed at the expense of your teams health and the company's effectiveness. (3) here seems to be the most important from my experience - and I'd reword it: demo your product through the lens of business value. Is this going to reduce toil letting engineers further up the stack move faster? Tighten feedback loops? Reduce pager fatigue? Reduce head count growth as the business grows? My demos almost always have extra engineering work dedicated to the demo, visual aids, and a story that shows the evolution of the problem domain: how did we find ourselves working on this and what happens to the business if nobody solves this problem space? Demos of obscure backend tech are most powerful if you can root them in language directors, VPs, and execs hear from the tech org on a regular basis. Attaching your work to the reasons they hear for things taking too long, costing so much, or causing downtime will win you friends and get you valuable feedback on aligning/calibrating your work to business need.
- chrsig 4y ago
  Fair enough points From that perspective, I'd add: use graphs to tell the story. attach graphs of the system to business objectives. Make sure there's a solid communication around what the graphs mean (and what they don't mean, aren't measuring, etc). All situation dependent, but solid data is something that's generally appreciated throughout the business.
- gofreddygo 4y ago
  > what happens to the business if nobody solves this problem space > Attaching your work to the reasons they hear for things taking too long, costing so much, or causing downtime > if you don't align incentives with your work through bi-directional communication you're going to find yourself eternally understaffed This comment reads grounded in practical, pragmatic, real world experience. Talk backend stuff to decision makers and they will find a way to avoid (or worse pretend) to listen. Don't talk and they will never know your worth. The middle ground here is to connect. My hack; I maintain 2 lists of key words from town halls, skip levels, one-on-ones and company-wide communications. A green list of things we want (targets, goals, visions). A red list of things we don't want (downtime, op costs, hardware cost, incidents, bad customer feedback, etc.) Connect each chunk of backend work to at least one green item. If not, connect to the absence of 2 red items. Ideally both. A slide with "Customer support costs from our last quarter's town hall meeting was at x cents per customer interaction. This self-help feature should avoid 3 of the top 5 common customer questions reducing the load on our customer service teams, dropping costs" delivers the message strongly as compared to a demo about the ingenious AI based (ugh!) routing mechanism. The harder stuff is where things get expensive before the get cheaper.
  - rjbwork 4y ago
    Thank you for this. I've recently been promoted into a very senior engineering role and feel out of my depth, especially WRT communication and politics. I think this is a really insightful way of connecting oftentimes invisible engineering work to the concerns of the business.
    - gofreddygo 4y ago
      Congratulations on your promotion. Senior roles get harder. The work that actually matters is never discussed and impossible to define well. But once we get around the nuances, there's way more impact that can be engineered from senior positions (while also distancing from the politics tarpit that people managers find themselves in)
genmaicha123 4y ago
Not sure I agree. Framing the presentation to match the audience’s appetite is what generally helped me get insightful conversation going even with largely non-technical crowds. Each demo can be done in at least a few ways, and if one tries to demo APIs to C-suite as they would to their immediate engineering peers, one could end up at a conclusion similar to yours. I recently joined a startup, There’s about a dozen of us. Eng demos are scheduled weekly, which feels like a blog post so I won’t get into it here. Sometimes there’s UI to click around and yes, people are slightly more engaged. However, we’ve had successful demos of infra / API stuff. The key, unsurprisingly, was to surface impact on tangible business goals. No point in trying to explain how Terraform works, but there is value in demoing why it works for your team, how it helps ship and operate infra with confidence, how it helps with repeatability, makes infra changes reviewable, etc. Of course, it’s incredibly important that the group sees demos as inviting and bring their curiosity to the room. If that’s not happening well, that’s a whole other problem. Good rule of a thumb I tend to use is “half the presentation time for each X% of non-engineer audience”. If there’s 20 min of demo for eng peers, that needs to boil down to 10min as soon as one or two non-eng people join. Less time forces me to focus on value added rather than tech details. X will vary from org to org. And of course it’s always good to offer more detailed demo in a more focused group later on (e.g. “for those interested in the details of how we use Redis, I can do another demo in a smaller group right after this call”)
scarface74 4y ago
I “present” back end demos all the time to customers via diagrams, business problems that it is meant to solve and talking about them in STAR format just like I would at a behavioral interview - the only type of interviews that I will tolerate at my age (48). Yes I’m an active hands on keyboard software developer as far as my day to day work even if that’s not my official title anymore. Customers want to know what they are paying for.
peanutz454 4y ago
> don't bother. They don't know enough to engage with it, and they're not going to know enough to engage with it On the other end of the spectrum we are being to forced to think of backend development in terms of user stories
- remify 4y ago
  user stories can be technical. Service X needs a more generic API
  - robertlagrant 4y ago
    That's not a user story, unless you sell an API.
    - dylanowen 4y ago
      Even if you don't sell an API every team has users and customers. As a backend dev your users are just internal devs consuming your service.
      - chrsig 4y ago
        the 'user story' presented: - didn't identify the user - did't identify why the user needs a more generic api - what a more generic api would look like ... etc Granted, it was just a quick demonstrative HN post, not an actual user story being handed to an engineer -- but it was very much framed as a incredibly open ended task. I personally have mixed feelings on user stories vs tasks when it comes to the backend. Most managerial folk I've dealt with have an aversion to using anything internal to the company as a 'user' -- taking 'customer' a bit too literally. In the grand scheme of things, I don't care...I've reached an exhaustion point with pedantry around tickets. Is it clear what needs doing? Is it clear what done means? Great.
      - robertlagrant 4y ago
        It has users, but As an internal user I want a more generic API So I can do more generic things Is not a real user story :) Neither is: As a CFO I want the API to be rewritten in Rust So I can pay less for hosting They might be phrased like one, but user stories are meant to address specific user tasks or journeys, which doesn't work well for generic improvements.

by chrsig 4y ago

r3trohack3r 4y ago

I'm not sure I agree. It depends on the reason for doing a demo - if it's just for high fives or a pat on the back, probably not a demo worth doing. But a company needs bottom up leadership as much as top down leadership. It's important that backend engineers be able to surface critical work up through the org chart to get buy in on technical direction. Budget doesn't just manifest and if you don't align incentives with your work through bi-directional communication you're going to find yourself eternally understaffed at the expense of your teams health and the company's effectiveness. (3) here seems to be the most important from my experience - and I'd reword it: demo your product through the lens of business value. Is this going to reduce toil letting engineers further up the stack move faster? Tighten feedback loops? Reduce pager fatigue? Reduce head count growth as the business grows? My demos almost always have extra engineering work dedicated to the demo, visual aids, and a story that shows the evolution of the problem domain: how did we find ourselves working on this and what happens to the business if nobody solves this problem space? Demos of obscure backend tech are most powerful if you can root them in language directors, VPs, and execs hear from the tech org on a regular basis. Attaching your work to the reasons they hear for things taking too long, costing so much, or causing downtime will win you friends and get you valuable feedback on aligning/calibrating your work to business need.

chrsig 4y ago
Fair enough points From that perspective, I'd add: use graphs to tell the story. attach graphs of the system to business objectives. Make sure there's a solid communication around what the graphs mean (and what they don't mean, aren't measuring, etc). All situation dependent, but solid data is something that's generally appreciated throughout the business.
gofreddygo 4y ago
> what happens to the business if nobody solves this problem space > Attaching your work to the reasons they hear for things taking too long, costing so much, or causing downtime > if you don't align incentives with your work through bi-directional communication you're going to find yourself eternally understaffed This comment reads grounded in practical, pragmatic, real world experience. Talk backend stuff to decision makers and they will find a way to avoid (or worse pretend) to listen. Don't talk and they will never know your worth. The middle ground here is to connect. My hack; I maintain 2 lists of key words from town halls, skip levels, one-on-ones and company-wide communications. A green list of things we want (targets, goals, visions). A red list of things we don't want (downtime, op costs, hardware cost, incidents, bad customer feedback, etc.) Connect each chunk of backend work to at least one green item. If not, connect to the absence of 2 red items. Ideally both. A slide with "Customer support costs from our last quarter's town hall meeting was at x cents per customer interaction. This self-help feature should avoid 3 of the top 5 common customer questions reducing the load on our customer service teams, dropping costs" delivers the message strongly as compared to a demo about the ingenious AI based (ugh!) routing mechanism. The harder stuff is where things get expensive before the get cheaper.
- rjbwork 4y ago
  Thank you for this. I've recently been promoted into a very senior engineering role and feel out of my depth, especially WRT communication and politics. I think this is a really insightful way of connecting oftentimes invisible engineering work to the concerns of the business.
  - gofreddygo 4y ago
    Congratulations on your promotion. Senior roles get harder. The work that actually matters is never discussed and impossible to define well. But once we get around the nuances, there's way more impact that can be engineered from senior positions (while also distancing from the politics tarpit that people managers find themselves in)

genmaicha123 4y ago

Not sure I agree. Framing the presentation to match the audience’s appetite is what generally helped me get insightful conversation going even with largely non-technical crowds. Each demo can be done in at least a few ways, and if one tries to demo APIs to C-suite as they would to their immediate engineering peers, one could end up at a conclusion similar to yours. I recently joined a startup, There’s about a dozen of us. Eng demos are scheduled weekly, which feels like a blog post so I won’t get into it here. Sometimes there’s UI to click around and yes, people are slightly more engaged. However, we’ve had successful demos of infra / API stuff. The key, unsurprisingly, was to surface impact on tangible business goals. No point in trying to explain how Terraform works, but there is value in demoing why it works for your team, how it helps ship and operate infra with confidence, how it helps with repeatability, makes infra changes reviewable, etc. Of course, it’s incredibly important that the group sees demos as inviting and bring their curiosity to the room. If that’s not happening well, that’s a whole other problem. Good rule of a thumb I tend to use is “half the presentation time for each X% of non-engineer audience”. If there’s 20 min of demo for eng peers, that needs to boil down to 10min as soon as one or two non-eng people join. Less time forces me to focus on value added rather than tech details. X will vary from org to org. And of course it’s always good to offer more detailed demo in a more focused group later on (e.g. “for those interested in the details of how we use Redis, I can do another demo in a smaller group right after this call”)

scarface74 4y ago

I “present” back end demos all the time to customers via diagrams, business problems that it is meant to solve and talking about them in STAR format just like I would at a behavioral interview - the only type of interviews that I will tolerate at my age (48). Yes I’m an active hands on keyboard software developer as far as my day to day work even if that’s not my official title anymore. Customers want to know what they are paying for.

peanutz454 4y ago

> don't bother. They don't know enough to engage with it, and they're not going to know enough to engage with it On the other end of the spectrum we are being to forced to think of backend development in terms of user stories

remify 4y ago
user stories can be technical. Service X needs a more generic API
- robertlagrant 4y ago
  That's not a user story, unless you sell an API.
  - dylanowen 4y ago
    Even if you don't sell an API every team has users and customers. As a backend dev your users are just internal devs consuming your service.
    - chrsig 4y ago
      the 'user story' presented: - didn't identify the user - did't identify why the user needs a more generic api - what a more generic api would look like ... etc Granted, it was just a quick demonstrative HN post, not an actual user story being handed to an engineer -- but it was very much framed as a incredibly open ended task. I personally have mixed feelings on user stories vs tasks when it comes to the backend. Most managerial folk I've dealt with have an aversion to using anything internal to the company as a 'user' -- taking 'customer' a bit too literally. In the grand scheme of things, I don't care...I've reached an exhaustion point with pedantry around tickets. Is it clear what needs doing? Is it clear what done means? Great.
    - robertlagrant 4y ago
      It has users, but As an internal user I want a more generic API So I can do more generic things Is not a real user story :) Neither is: As a CFO I want the API to be rewritten in Rust So I can pay less for hosting They might be phrased like one, but user stories are meant to address specific user tasks or journeys, which doesn't work well for generic improvements.