What Speedrun Marathon Commentary Teaches About Live Demos

An engineer I coach had eleven minutes to demo a new feature to a room of buyers. At minute four the staging server threw an error, and he went silent for what he later guessed was thirty seconds. The audience told me afterwards it felt like two minutes. The demo itself recovered fine. The silence was what they remembered.

I now send people like him to watch a few hours of a speedrun charity marathon before they ever demo anything live. Runners at events like Games Done Quick play some of the hardest sequences in gaming, in front of hundreds of thousands of viewers, while talking the whole time. Things go wrong on almost every run. The good runners never lose the room. That is a live demo with the stakes turned up, and they have solved most of the problems my clients struggle with.

Why live demos go quiet at the worst moment

When something breaks on stage, two jobs land on your brain at once: fixing the problem and narrating what is happening. Most people can only do one, and fixing feels more urgent, so the narration stops. The audience then has nothing to hold except your face, which is usually showing panic.

The usual advice is to rehearse until nothing can go wrong. Rehearse, yes. But the "nothing can go wrong" part is the problem. If your whole plan depends on a perfect run, any failure leaves you with no script at all. Speedrunners assume failure is part of the show and plan the talking around it.

What runners do that presenters rarely do

They announce the risky part before it happens

Watch a runner approach a difficult trick and you will hear something like: "This next jump is frame perfect, I hit it maybe two times in three. If I miss, I lose about forty seconds and I'll take the safe route." Then they attempt it.

That sentence does three jobs. It tells the audience something hard is coming, so success feels earned. It sets the odds honestly, so a miss is not a shock. And it shows there is a backup, so a miss does not look like a disaster. The presenter equivalent is simple: "I'm going to run this on live data, which is the real test. If the connection drops, I have the same flow recorded and I'll switch to that." Say it before you click.

They keep talking while they fix

Runners narrate recovery: "Okay, I died there, that costs me a life, I'm going to grab the extra one in the next room." It is not elegant. It is continuous. The audience stays with them because they always know what is happening.

Speakers can practise this on purpose. During rehearsal, ask a colleague to break something without warning, close a tab, kill the wifi, and practise saying out loud what you are doing to fix it. The words do not need to be clever. "I've lost the connection, I'm reconnecting, while that happens let me tell you what you would have seen" is enough.

They share the talking

Marathon runs usually have commentators on a couch beside the runner. When a hard section demands the runner's full concentration, the couch takes over, explaining the route or telling a story about the game. Nobody expects the runner to talk through the hardest ten seconds.

For a demo, bring a couch. One colleague who knows the product, sitting at the side with a microphone or ready to stand, can fill a sentence or two while you troubleshoot. Agree beforehand on a signal, even just a glance, for "take over for a moment."

The estimate on screen is a promise you keep in public

Every marathon run has a published time estimate in the schedule, and a timer runs on screen. The audience knows how long they are committing to, and when a run goes over, the host and runner talk about it openly.

Presenters rarely show their agenda this clearly. Telling a room "this demo has three parts, it takes about eight minutes, and I'll take questions after part two" gives the same comfort as a timer. It also gives you a structure to fall back on when something breaks. Instead of wondering where you are, you can say "we're in part two of three" and keep moving.

For more on building talks around a single clear thread instead of everything you could show, see building a talk around one idea. Demos fail most often when they try to show ten features in eleven minutes.

A failure the whole industry still remembers

In April 1998, Bill Gates was on stage at the COMDEX trade show while an assistant plugged a scanner into a Windows 98 machine to demonstrate plug and play. The machine crashed to a blue screen in front of the audience and the cameras. Gates joked that this must be why they were not shipping Windows 98 yet, the room laughed, and the clip has been replayed for decades.

What saved that moment was a line, said quickly, that named the failure instead of hiding it. That is exactly what a runner does after a missed trick. You do not need to be funny. You need to acknowledge what happened within a few seconds, so the audience stops wondering whether you noticed.

A rehearsal routine borrowed from runners

Runners practise individual hard sections hundreds of times in isolation, not only full runs. Presenters tend to rehearse the whole talk end to end and hope the hard parts improve. Here is a routine I have used with about fifteen technical presenters in the last two years:

1. List the three moments in your demo most likely to break, such as logging in, loading live data, or switching windows.
2. Write one sentence for each that announces it before you try it and names your backup.
3. Rehearse only those three moments ten times each, with a colleague breaking them at random.
4. Record a clean video of the full demo and keep it open in a background tab as your safe route.
5. Agree on a couch partner and a signal for handing over the talking.
6. Run the full demo end to end twice, no more, the day before.

The full schedule I recommend for the week before a talk is in the rehearsal schedule that calms nerves. For explaining complex systems to non-specialists while you demo, the approach in explaining technical things so people understand pairs well with this.

A streamer holding an audience over hours relies on many of the same habits, and the comparison is worth reading in how a streamer holds an audience for three hours.

Watch one run before your next demo

This week, find a recorded marathon run of any game you know a little about, between thirty and sixty minutes long, and watch it with a notepad. Write down every moment the runner announces a risk, every recovery they narrate, and every time the couch takes over. Then write your own versions of those three sentences for your next demo. You will notice the silence in your own rehearsals immediately afterwards.