How to present backend demos

https://rxhl.notion.site/How-To-Present-Backend-Demos-861303c09e3e48fcb33a2a6999260e59

by vadcv • 4 years ago

156 34 4 years ago

rxhl.notion.site

metadat3• 4 years ago

Also, use Demo Magic to great effect:

https://github.com/paxtonhare/demo-magic

Hint: pbcopy is your friend.

layer83• 4 years ago

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.

metadat3• 4 years ago

pbpaste.. this is exactly what you want.

watersb• 4 years ago

My first thought was this Dilbert comic:

https://dilbert.com/strip/2000-02-24

btbuildem2• 4 years ago

Regarding the last point: read the room.

How do we read the room when it's a Teams call?

jkaptur• 4 years ago

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.

Gravityloss• 4 years ago

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.

Gaessaki• 4 years ago

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...

chrsig3• 4 years 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• 4 years 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.

chrsig3• 4 years 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.

gofreddygo2• 4 years 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.

genmaicha123• 4 years 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• 4 years 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• 4 years 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• 4 years ago

user stories can be technical. Service X needs a more generic API

nivertech• 4 years ago

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.

Raziarazzi• 4 years ago

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.

barefeg• 4 years ago

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”.

dewey• 4 years ago

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.

robertlagrant4• 4 years ago

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!

tragomaskhalos• 4 years ago

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?"

How to present backend demos

Related Stories