How to present backend demos(rxhl.notion.site)
rxhl.notion.site
How to present backend demos
https://rxhl.notion.site/How-To-Present-Backend-Demos-861303c09e3e48fcb33a2a6999260e59
12 comments
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.
(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.
> 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.
> 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.
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.
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)
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)
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.
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.
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”)
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”)
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.
Customers want to know what they are paying for.
> 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
On the other end of the spectrum we are being to forced to think of backend development in terms of user stories
user stories can be technical. Service X needs a more generic API
That's not a user story, unless you sell an API.
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.
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.
- 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.
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.
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.
Ahhh ok, I see your point
This begets the question, why present a backend demo to a non-technical audience?
Almost every time I’ve done this, the tech part was glossed over as the audience assumed I was presenting in good faith. Usually, the business needs garner a lot more discussion time.
If you’re doing some sort of sales or fundraising pitch, isn’t it worth mocking up a minimal UI?
Reminds me of an old Joel Spolsky post: https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret...
Almost every time I’ve done this, the tech part was glossed over as the audience assumed I was presenting in good faith. Usually, the business needs garner a lot more discussion time.
If you’re doing some sort of sales or fundraising pitch, isn’t it worth mocking up a minimal UI?
Reminds me of an old Joel Spolsky post: https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret...
Also, use Demo Magic to great effect:
https://github.com/paxtonhare/demo-magic
Hint: pbcopy is your friend.
https://github.com/paxtonhare/demo-magic
Hint: pbcopy is your friend.
Any ideas on how to use Demo Magic with multiple scripts/snippets invisibly? I.e. I’d like to select from a set of prepared Demo Magic scripts (by pressing certain keys or short key sequences), but without the audience seeing the selection process.
pbpaste.. this is exactly what you want.
That seems to be a Mac thing, and also I don't see how clipboard access relates to my question.
Linux has comparable tools. Basically, you can script out the commands you want and insert them into the clipboard with Demo Magic. It's slick, but you do need to use your brain; it's not 100% automatic.
It's a tool, not a complete solution on its own.
It's a tool, not a complete solution on its own.
My question is about how to realize an invisible menu of scripts so that I can invisibly select individual scripts to run (present) from that menu. I don't see how clipboard functions would help with that.
Might be a bit too simple, but could you have each script loaded in a different tab in your terminal, and just go to the right tab?
I don't think this makes sense. First the article mentions it's for a "non-technical audience" and then the first step ("1. Start with a diagram") is a detailed architecture diagram that nobody will care about or be able to relate to.
If you really want to do a demo you should focus on how it helps the business and not how it works.
This could be showing a detail in the UI the non-technical audience is familiar with like a "Generate report" button that they use daily and is frustratingly slow. You can show a graph of the average waiting time going down.
This could also be an overview over how the page speed improved or how your core web vitals are all green now, improving your ranking. If you achieved that by optimizing a query, switching databases or rewriting an endpoint doesn't really matter in my opinion.
Of course this, as always, depends on the company, culture and audience. Maybe there's a very technical founder who wants to hear about that, in that case ignore everything I said.
If you really want to do a demo you should focus on how it helps the business and not how it works.
This could be showing a detail in the UI the non-technical audience is familiar with like a "Generate report" button that they use daily and is frustratingly slow. You can show a graph of the average waiting time going down.
This could also be an overview over how the page speed improved or how your core web vitals are all green now, improving your ranking. If you achieved that by optimizing a query, switching databases or rewriting an endpoint doesn't really matter in my opinion.
Of course this, as always, depends on the company, culture and audience. Maybe there's a very technical founder who wants to hear about that, in that case ignore everything I said.
Some ideas:
1. use bash, REPL or query language
2. if your backend exposes GraphQL API - use GraphiQL console with prepared query snippets
3. use a notebook to call commands with table or visual outputs (i.e. LiveBook in Elxir, Jupyter in Python/others)
4. use Grafana dashboard in case your backend's API or DB can be used as a datasource
5. lots of other nocode/lowcode tools which can be used to render data from your backend in a format that non-technical people can understand, i.e. StreamLit, etc.
1. use bash, REPL or query language
2. if your backend exposes GraphQL API - use GraphiQL console with prepared query snippets
3. use a notebook to call commands with table or visual outputs (i.e. LiveBook in Elxir, Jupyter in Python/others)
4. use Grafana dashboard in case your backend's API or DB can be used as a datasource
5. lots of other nocode/lowcode tools which can be used to render data from your backend in a format that non-technical people can understand, i.e. StreamLit, etc.
Regarding the last point: read the room.
How do we read the room when it's a Teams call?
How do we read the room when it's a Teams call?
Observe the percentage of people with their camera on (vs. some baseline), look at the faces you can see, watch for reaction emojis, take intermediate points to solicit questions and see how many you get, etc.
I often just honestly ask: "does it make sense, what I just said"? Often people are that "yes" but sometimes I get questions like "but doesn't X already do this, what is the difference?" etc that are very useful.
I find one thing that sort-of works for me is to stop often and prompt questions from the audience.
Repeated dead silence means (to me) that no-one is interested.
Repeated dead silence means (to me) that no-one is interested.
To keep things simple, I'll only keep three data sources: products, news, and technical data. Three unrelated data sources are sufficient to highlight the problem.
I'm using Python and Flask in the demo, but the underlying technology is unimportant because BFF is an architectural pattern.
The starting point is a monolith. The monolith provides an endpoint for each data source as well as a unified aggregation endpoint for all of them.
One of the big things that people understand is a diagram that shows lots of stuff deployed, and then what's deployed now, and the amazing cost saving, which you put on the final slide so they remember it. Any cost saving demos go down well!
OTOH one advantage of such a demo over a UI demo is that, unlike the latter, it is highly unlikely to descend into infuriating bikeshedding around tiny details such as "why can't this button be half a millimetre to the right?"
Would the same advice hold for demos of e2e solutions, say backend and frontend? At least in scrum, stories usually require input from many areas, and the demos usually center around the UI (since it’s the easiest to show).
In this case I assume at which point you talk about backend might be important. For example if it’s at the end, people will just drop off since “it’s boring”.
In this case I assume at which point you talk about backend might be important. For example if it’s at the end, people will just drop off since “it’s boring”.
[deleted]
My first thought was this Dilbert comic:
https://dilbert.com/strip/2000-02-24
https://dilbert.com/strip/2000-02-24
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.