How to present backend demos
rxhl.notion.site
rxhl.notion.site
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.
(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.
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.
> 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.
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)
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”)
Customers want to know what they are paying for.
On the other end of the spectrum we are being to forced to think of backend development in terms of user stories
- 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.
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.
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...
https://github.com/paxtonhare/demo-magic
Hint: pbcopy is your friend.
It's a tool, not a complete solution on its own.
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.
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.
How do we read the room when it's a Teams call?
Repeated dead silence means (to me) that no-one is interested.
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”.