Your Demo Slot Is a Leadership Opportunity

Published: (January 20, 2026 at 02:45 AM EST)
3 min read
Source: Dev.to

Source: Dev.to

The Problem with Traditional Demos

Every two months I stand in front of stakeholders and present what my team shipped.
For years I did what everyone does: walked through features.

“We added an error page to the docs.”
Checkbox. Checkbox. Next slide.

Nobody remembers those demos. Most demos follow the same script:

  • “In this sprint we implemented feature X. It’s efficient.”

A demo becomes proof that work happened — not a place where shared understanding is built. Nobody explicitly asks for this framing; you just absorb it. This is what a “professional” demo looks like.

A Different Approach

Last Friday I had a PI demo for new features in our component library. The old version of me would have said:

“We added a comprehensive error documentation page listing all error codes and explanations.”

That’s accurate, but instead I tried something else. I told a story and gave the user a name.

The Story

Meet Bob.

Without us, Bob is staring at weeks of work: identity‑provider quirks, permission matrices, undocumented edge cases. With the component, he copies the quick‑start example. Five minutes later it runs, then it crashes. He binds the error callback — like the docs suggest — and gets this message. Bob sends the email. Later he discovers our error reference page and realizes something important: every failure mode is documented. He’s no longer guessing. He can build.

Same features, different framing. One is a deliverable; the other is a story.

Why Storytelling Works

A feature list teaches:

“Progress is shipping things.”

A story teaches:

“Progress is changing someone’s situation.”

Those lessons don’t show up as questions in the meeting. They appear when someone says “Bob” — and everyone knows what that means. A named character is a compression mechanism. In environments where “safe” means status reports and checklists, this models something else: alignment comes from empathy, not precision slides.

I’m not expecting applause. The signal I care about is delayed — and indirect. Weeks or months from now I’ll listen for:

  • “Bob is stuck at this step.”

If “Bob” ever reappears in a ticket, a meeting, or a backlog item, I’ll know the framing landed. If Bob never comes back — that’s data too.

Takeaways

  • The experiment is running; no results yet.
  • Nobody asked me to do this; the slot was mine, so I used it differently.
  • I came up with the story ten minutes before the demo. It showed clumsy phrasing, rough pacing, and I didn’t even name the character until later.
  • Doing it once, imperfectly, is already more than “thinking about doing it differently,” which is where most ideas quietly die.

This connects to something I wrote about recently: you often have more agency than you think — but only if you actually take it.

Next Steps

  • In the next demo, pick one feature.
  • Don’t describe what it does.
  • Give it a name.
  • Then watch what comes back.

Views and experiments described here are my own and don’t represent my employer.

Back to Blog

Related posts

Read more »

Agile | Scrum & Kanban Framework

What is Agile? In earlier modules, the term agile described a key aspect of DevOps culture: the ability to respond quickly to customer needs and feedback. Agil...

🚀 Common Agile Frameworks

Scrum What it is Scrum is the most popular Agile framework. Work is delivered in short, fixed‑length iterations called Sprints usually 2 weeks. Roles - Product...