The weekly demo

If I could install exactly one recurring thing in a company, it would be this: a weekly demo of working software, at a fixed time, that never gets cancelled.

Forty-five minutes, and it does about five jobs at once.

It creates a real deadline every week, which shortens batches without anyone having to argue about batch size. It puts engineers in front of the people they're building for. It surfaces misunderstandings while they're still cheap. It makes invisible work visible.

And it gives the whole company a weekly, unarguable answer to what engineering is doing.

Nothing else on the calendar has that ratio.

Never cancelled is the whole rule

The demo is mandatory and standing.

It happens in the weeks when there's nothing impressive to show. Especially then.

Cancel it once because it's a quiet week and you've converted a rhythm into a performance.

The next quiet week it gets cancelled again. Within two months it only happens when somebody has something to show, which makes it a launch event, and the forcing function is gone.

The weeks with nothing to show are the informative ones anyway.

A team with nothing to demo has been on something big, and you want to know why it's big and whether it can be cut. Or consumed by interrupts nobody had quantified. Or blocked, by what, since when.

All three belong on the table, and the empty slot is what puts them there.

Same day. Same time. Every week.

Whether or not the CEO can make it, whether or not there's a launch, whether or not it's a holiday week with four people around.

Working software only

The demo is the running system.

Not slides. Not a Figma file. Not a screen recording of something that worked yesterday, and not a status update about progress.

That constraint does almost all the work, because it's the only part that can't be faked.

A slide about progress can describe any state of the world. A live system either does the thing or it doesn't.

So the rule needs teeth. If it isn't running, it isn't demoed.

Not shamefully. No penalty. It just doesn't take a slot, and the team says what they'd hoped to show and what's in the way.

Two allowances.

Work in progress is fine, including ugly work in progress behind a flag, because the point is seeing the thing rather than seeing it finished.

And infrastructure counts. Show the pipeline running, the dashboard, the build that now takes four minutes. If something can only be described rather than shown, find the piece of it that can be shown.

Prep should be near zero.

Any demo requiring an hour of preparation has become a performance, and that preparation is a tax on exactly the people whose time is most worth protecting.

Who has to be in the room

The engineer who built the thing does the demo. Not the manager, not the PM. The person whose hands were on it.

This is non-negotiable for a reason that has nothing to do with fairness. When the person who built it presents it, they hear the questions directly, and the questions are the product feedback. Route it through a manager and the feedback gets summarised, softened, and delivered as a task three days later.

On the other side of the room you need at least one person who can say "that's not what I meant." Founder, product lead, someone from support or sales who talks to customers all day. Without that person, the demo is engineering showing engineering, which is pleasant and produces nothing.

Support and sales are underrated attendees. They know what customers are actually complaining about, they're rarely invited to anything, and they'll ask the question everyone else is too polite to ask.

Keep it open to everyone else and don't require them. Optional attendance with a real reason to attend is the healthiest state, and the attendance number is itself a signal: if it's dropping, the demo has become a status meeting and needs fixing.

Keeping it from becoming a status meeting

The failure mode is drift. It starts as software and becomes an update, one week at a time, usually via a team that had nothing to show and described their week instead.

Four rules that hold it in place.

Timebox hard. Forty-five minutes total, five to seven minutes per team, and the timebox is enforced by someone rather than by hope. Overrunning demos are how the meeting becomes hated.

No status. If a sentence starts with "we've been working on," it's out of scope. What was built, shown, in the product.

Questions during, not after. The value is in the interruption. Somebody saying "wait, why does it do that" in minute two is the entire return on the meeting.

And anything that turns into a discussion gets taken out of the room immediately, with a named person and a next step. One demo can generate three of those, and if they're allowed to run in the meeting you'll be there for ninety minutes and half the audience will have stopped coming by month two.

When a team has nothing to show

Handle this well the first time and it stays healthy for years. Handle it badly once and everybody learns to manufacture something for the slot.

The response is a question rather than a reaction, asked plainly: what's in the way. Then listen, in front of everyone, and act on it if it's actionable.

If the answer is that the work is large and indivisible, help them find the seam. It's usually there and it's usually being missed because nobody has needed to look.

If the answer is that they've been firefighting, that's the most useful thing said in the meeting all week, and it belongs in the conversation about load rather than in a private one-to-one three weeks later.

The one response that ruins it: visible disappointment. Everyone reads that instantly, and the next time a team is empty-handed they'll demo a UI mock or narrate their week, and you'll have lost the only honest signal the meeting produces.

Remote, and larger companies

Remote demos work, with two adjustments. Somebody has to actively run it, because the natural interruptions that make it valuable don't happen on a call unless invited. And recording it is worth more than it is in person, since half the value at a distributed company is the people who watch it later.

Past about eighty engineers the single company-wide demo stops fitting, and the usual answer is a demo per group with a monthly cross-cutting one. That works, and the thing to protect through the transition is the presence of someone who can say "that's not what I meant." When demos become intra-group, that person is often the one who drops off, and the meeting becomes engineers showing engineers within a quarter.