Lessons from the Stage Manager's Cue Sheet

Last weekend, I found myself in a darkened theater, watching a friend run the lighting console for a small production. My eye wasn't on the stage, but on the glowing laptop beside them, displaying what they called the 'bible': the stage manager's cue sheet. It was a meticulous, linear document, a sequence of numbered commands instructing lights, sound, and curtain. Watching it in action, I realized I wasn't looking at show notes; I was looking at the most elegant runbook I'd ever seen. The principles that make a live show run (or fail) have direct, powerful parallels to running our small, boringly reliable services.

The Single, Unbroken Timeline

In theater, there is no 'undo,' no 'rollback to last known good state.' The show proceeds from 'lights up' to 'curtain call' in one irreversible flow. This forces a radical clarity. Every action is a numbered 'cue' with a precise trigger—'GO at Actor's line' or 'GO on Sound Fade Complete.' There is no ambiguity about when to act. In our systems, we often have alerts and logs, but our 'runbooks' are paragraphs of prose describing a diagnosis. What if we treated a service outage like Act II, Scene 3? The alert is the trigger line. The response is a sequence of numbered, imperative commands: '1. Confirm database connection pool is exhausted. 2. Execute graceful restart of sidecar. 3. Verify metric X returns below threshold Y.' The timeline is the narrative, and we are its stage managers.

More importantly, the cue sheet acknowledges fallibility. Next to every command is a pencil note: the 'standby.' This is the warning given thirty seconds before the cue—'Standby for Lights 47.' It's a readiness check, a final systems verification before the irreversible action. In our world, how often do we blast a 'restart production database' command without a 'standby'? The principle translates: before any major, state-altering ops procedure, we should have a defined 'standby' step—a final confirmation that backups are verified, that traffic is diverted, that the team is ready. It’s the human and system check before the 'GO.'

The final, humbling lesson is in the post-mortem, or in theater terms, the 'notes session.' After every show, the stage manager gathers the crew. They don't debate what *should* have happened; they work from the shared, indisputable record of what *did*. The cue sheet is annotated with what went wrong: 'Sound Q32 late by 2 seconds. Light Q47 dragged.' This isn't blame; it's calibration. Our logs and metrics are our performance record. The lesson is to review them not to assign fault, but to adjust timing, clarify triggers, and smooth the execution for the next 'show'—the next incident, the next deployment, the next nightly batch job.

Our systems are live performances. They have a script (the code), a crew (us), and an audience (our users). Borrowing the stage manager's discipline—the immutable cue sequence, the sacred 'standby,' and the blame-free notes—doesn't make the technology less boring. It makes our operation of it more reliable, one clear, deliberate cue at a time.

Notes & further reading

A few pages I came back to while writing this: