A run of show is a table: what happens, who leads it, and how long it takes. It earns its keep during the event, when it tells you where you are and how much time is left. And afterwards, when actual minutes sit next to the plan and you can see where the plan parted ways with reality.
Example: a mock-interview meetup, planned vs actual
On 18 September 2026 the community “Nemnogo Product” held an online meetup: three mock interviews of one product manager candidate — with HR, with the hiring manager and with the CEO. Each interview was followed by audience questions. The author of this guide moderated, and the timing ran on the Po minutam prototype, so every stage has both a plan and an actual time.
| Stage | Plan, min | Actual, min | Deviation |
|---|---|---|---|
| Opening | 5 | 3.5 | −1.5 |
| HR interview | 15 | 17.6 | +2.6 |
| Questions after HR | 5 | 6.5 | +1.5 |
| Hiring manager interview | 35 | 35.9 | +0.9 |
| Questions after the hiring manager | 5 | 7.1 | +2.1 |
| CEO interview | 25 | 33.1 | +8.1 |
| Questions after the CEO | 5 | 3.7 | −1.3 |
| General questions | 5 | 14.3 | +9.3 |
| Closing | 5 | 0 | −5 |
| Total | 105 | 121.7 | +16.7 |
The meetup started at 19:02 and ended at 21:04 — 17 minutes later than planned. The closing was marked done right after general questions: the goodbyes happened inside them.
What the numbers show:
- Questions overran, not the interviews. The four Q&A blocks had 20 minutes in the plan and took almost 32. General questions ran three times over: the audience asked what it had not managed to ask along the way.
- The longest block stayed on time. The hiring manager interview ran for 35 minutes and ended less than a minute off. Near the end the moderator left the interviewer a note on the board — “wrap up” — a signal that does not interrupt the conversation on air.
- There was no separate buffer. The script allowed stretching from 100 to 105 minutes, but those five minutes were already in the plan as “General questions”. When the overrun built up, there was nothing to absorb it, so it landed at the end.
How to build a run of show
Plan backwards from the end. Start from the time the stream or the room must be free and work back. That way the buffer is in the plan from the start instead of “if we have time”. Planning forwards is almost always optimistic: people underestimate how long their own tasks take, and that is a proven effect, not pessimism [1].
Make the buffer one separate stage. If everything runs to plan, it becomes extra minutes for questions or networking. If not, the last speaker does not have to squeeze their talk in half.
Give Q&A room. The example above is typical: Q&A blocks stretch more often than talks. Give them more time than seems necessary, or decide in advance which one gets cut first.
Add a break if the event runs over an hour and a half. Without breaks, stress builds up from one meeting to the next; with breaks, it does not [3]. The 105-minute meetup in the example had no break — for the next event of this format it is worth planning one.
Make arrival a stage too. At an in-person event, put guest arrival at the start so late-comers do not eat into the first talk: a late start lowers both how people rate a meeting and what it produces [2].
What else goes into the run of show
- one person responsible for each stage, not “the team”;
- what happens if a speaker does not show up: which stage moves and who announces it;
- technical checks before doors open: sound, slides, stream.
How to keep to the plan during the event itself is covered in the guide on keeping a meetup on schedule.
How to do it in Po minutam
Paste the script as free text and the AI assistant will break it into stages with minutes and hosts — or build the stages by hand. During the meetup the host marks stages, the board shows how far behind the plan you are, and afterwards you get a report with planned, actual and deviation for every stage — like the table above.