# Your Demo Slot Is a Leadership Opportunity

> Every two months, I stand in front of stakeholders and present what my team shipped.  For years, I...

- Auteur : Balthazar de Moncuit
- Publié : 2026-01-20
- Langue : en
- Tags : leadership, craft
- Source : https://moncuit.ch/ecrits/your-demo-slot-leadership/
- Licence : CC BY-NC 4.0, citez la source

---

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."
> "We improved the callback API."

Checkbox. Checkbox. Next slide.

It's efficient. It's safe. And it's forgettable.

More importantly, it quietly trains the organization to think in outputs, not situations. A demo becomes proof that work happened — not a place where shared understanding is built.

But a demo slot is stage time.
And stage time is influence — whether you intend to use it or not.

---

## Trying Something Different

Last Friday, I had a PI demo. 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.
And it would have evaporated instantly.

Instead, I tried something else.

I told a story — and I gave the user a name.

> "Meet Bob.
> Bob is a developer integrating our authentication component into his research platform.
>
> 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:
> 'Your test user lacks permission XYZ. Send this email to support. Response time is usually two days.'
>
> Bob sends the email.
> Two days later, it works. He's not stuck anymore.
>
> 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.
Same code.
Same sprint.

Different framing.

One is a deliverable.
The other is a worldview.

---

## Why This Matters

Demos quietly teach people what kind of work matters.

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 show up later — in how problems are framed, in what's considered "done," in which gaps feel uncomfortable.

They show up when someone says "Bob" — and everyone knows what that means.

A named character is a compression mechanism.
It turns an abstract "integrator" into a reference point the organization can think with.

In environments where "safe" means status reports and checklists, this models something else: that alignment comes from empathy, not precision slides.

---

## The Signal I'm Looking For

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."
> "Bob's journey breaks here."
> "Bob needs one last thing to close the loop."

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.

---

## What Actually Happened

Nobody asked questions. No follow-up messages. No visible reaction.

It was a Friday afternoon PI demo on Teams. We wrapped. People went into the weekend.

The experiment is running. No results yet.

---

## Try It Once

Nobody asked me to do this. Nobody rewarded it. The slot was mine. So I used it differently.

This connects to something I wrote recently: [you often have more agency than you think](https://dev.to/dexluce/most-micromanagement-is-invited-330k) — but only if you take it.

I came up with the story ten minutes before the demo. It showed. And I didn't even name the character — "Bob" arrived while writing this.

But I did it once. Imperfectly.

Next demo, pick one feature. Don't describe what it does. Describe who uses it. Give them a name.

Then watch what comes back.

---

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