The Analog Incident Puppet Stage: Using Paper Characters to Rehearse Your Worst On‑Call Conversations

If you’ve ever ended a night on call thinking, “We got lucky—next time this could go very wrong,” you’re not alone. Most teams have war stories about dropped handoffs, missing context, or confused incident command during a crisis.

But you don’t have to wait for a real outage to stress‑test how your team talks, coordinates, and hands off responsibility. You can rehearse it—cheaply, safely, and even a little playfully.

Enter: the analog incident puppet stage.

Using paper characters (or literal puppets) in a tabletop exercise gives your team a low‑stakes way to practice their worst on‑call conversations before they happen in real life.

What Is a Tabletop Exercise (and Why Should On‑Call Folks Care)?

A tabletop exercise is a low‑cost, low‑stakes simulation where teams sit together and talk through how they’d respond to an emergency or incident scenario. There’s no real system at risk, no actual alarms—just a scenario, some prompts, and people walking through what they would do.

Unlike full‑blown technical game days or chaos experiments, tabletop work focuses on:

Decision‑making: Who decides what? When do we escalate? What’s considered “good enough” to ship or roll back?
Communication: Who talks to customers? Who talks in Slack? Who writes the incident timeline?
Cross‑department coordination: How do engineering, support, product, and leadership stay aligned when time is tight?

It’s a rehearsal space. You’re not testing CPUs and failover; you’re testing how humans coordinate under pressure.

For on‑call teams, this is gold. Most of what goes wrong during incidents isn’t a missing script or a broken dashboard—it’s missed messages, unclear roles, or assumptions that never got spoken out loud.

Why Practice On‑Call Conversations at All?

On‑call is fundamentally a communication job wrapped around a technical one. Even brilliant engineers can struggle in moments like:

A shift handoff at 2:00 a.m. where the outgoing engineer forgets to mention the “temporary hack” holding a critical service together.
An incident bridge where three people assume someone else is talking to customer support.
A major outage where leadership wants answers and the on‑call is juggling paging, debugging, and messaging at the same time.

Practicing these conversations in advance:

Reduces the risk of dropped context during real handoffs.
Improves role clarity: who owns what, who speaks when.
Builds muscle memory for tough moments—like admitting uncertainty or pushing back on unrealistic demands.
Makes it safer to experiment with new communication protocols and see how they feel.

You don’t need a lab or a custom simulator to do this. You just need a table, some paper, and a willingness to play.

The Puppet Stage: Why Low‑Fi Tools Work So Well

It might sound silly to use paper characters, index cards, or a cardboard “stage” to represent people in an incident. That’s exactly why it works.

Low‑fidelity tools like paper puppets:

Lower the emotional stakes. It’s much easier to experiment with hard conversations when you’re moving a paper “CTO” around instead of staring down your actual CTO.
Make roles visible. Each character can have a name, role, and responsibilities written on it. You can literally see when “Incident Commander” disappears from the table.
Encourage participation. It feels like a game, which can help quieter team members speak up and engage.
Center communication over tooling. There’s no fancy incident platform to hide behind—only what people say, decide, and hand off.

This is deliberately analog. The messiness is a feature, not a bug.

Setting Up Your Analog Incident Puppet Stage

You can start small. Here’s one way to design a paper‑based tabletop exercise focused on on‑call and handoffs.

1. Define a Scenario

Pick a plausible but uncomfortable incident, for example:

“Critical API latency spikes 10 minutes before a major customer webinar.”
“Payments service starts double‑charging a small percentage of customers.”
“Data pipeline silently stops running over a long weekend.”

Outline just enough detail to set the scene. You’ll reveal more information as the exercise progresses.

2. Create Your Paper Characters

On index cards or sticky notes, create characters such as:

On‑call engineer
Secondary on‑call
Incident commander
Support lead
SRE / platform engineer
Product manager
Customer communications / marketing
Duty manager / leadership

For each, write:

Name (real or fictional)
Role
Key responsibilities during an incident

Put them on the table like a little cast list.

3. Map Your Communication Channels

On separate cards or areas of the table, represent channels like:

Incident Slack room
On‑call paging system
Status page / public updates
Internal email / leadership updates

This helps you visualize where information should go, and who can see it.

4. Walk Through the Incident in Rounds

Run the exercise as a series of time‑boxed “rounds,” each representing, say, 10–20 minutes of incident time.

For each round:

The facilitator reveals a new piece of information (e.g., “Error rate doubles,” “Customer support starts getting angry tickets”).
The team decides: Who acts? Who communicates? What do they say? Where do they say it?
Move the paper characters to the channels they’re using—e.g., place the “On‑call engineer” card into “Incident Slack room.”
Narrate the conversations: act out what gets said between roles.

You can rotate who “drives” different characters to ensure participation.

5. Simulate Handoffs and Shift Changes

To focus on on‑call practices, introduce constraints like:

“It’s now 5 minutes before the on‑call shift changes.”
“Incident spans a weekend; Friday on‑call is handing off to weekend on‑call.”

Have the outgoing and incoming on‑call characters:

Review current status.
Clarify what’s still unknown.
Confirm who owns what next.

Then force a handoff: the outgoing character leaves the table. Whatever context wasn’t clearly handed off is now gone.

This is where gaps become painfully obvious—and that’s the point.

What These Exercises Reveal (That Dashboards Don’t)

Running even a single analog tabletop can surface uncomfortable truths about your incident process, such as:

Unclear ownership: Multiple people assume they’re not the incident commander, so no one is.
Broken information flow: Support learns about the incident from Twitter instead of an internal channel.
Missing handoff structure: Outgoing on‑call says, “Yeah, it’s been quiet,” but doesn’t mention they disabled an alert.
Role confusion: Product manager starts giving technical direction because the engineers aren’t communicating clearly.

Because this is a low‑stakes simulation, discovering these issues feels like a win, not a failure. You caught the crack in the bridge before people started driving over it.

Designing Better On‑Call Handoffs from What You Learn

A key benefit of tabletop work is turning insights into structured on‑call handoff processes. Robust handoffs typically include:

Documentation
- A shared, lightweight handoff doc or runbook updated during the shift.
- Links to active incidents, partial fixes, and risky areas.
Overlap windows
- A few minutes where outgoing and incoming on‑call are both present.
- Time explicitly reserved for questions, not just “it’s all good.”
Clear communication protocols
- Standard questions: “What’s broken, what’s brittle, what’s noisy?”
- Agreed‑upon channels for alerts, escalations, and leadership updates.
Verification steps
- Incoming on‑call confirms they can receive pages.
- Quick review of current active alerts or degraded services.

You can test and refine all of these in your puppet‑stage exercises.

For example, try two versions of a handoff:

Totally unstructured: “How was your shift?”
Structured checklist: “Walk me through: open incidents, mitigations, disabled alerts, known flaky services.”

Play both out on the table and watch how much context persists across the handoff. The difference is often dramatic.

Tips for Running Effective Analog Incident Sessions

To get the most from your paper‑based tabletop:

Keep it short and focused. Aim for 60–90 minutes, one scenario, one main learning goal (e.g., shift handoffs).
Invite cross‑functional roles. On‑call isn’t just engineering; bring support, product, and comms when you can.
Normalize imperfection. Make it clear that the goal is to find gaps, not for people to “perform” expertise.
Capture insights in real time. Keep a visible list: “Things that confused us” and “Things that helped us.”
End with concrete actions. Turn findings into updates to runbooks, handoff scripts, or role definitions.

The point is not to create theater for its own sake; the play is there to make the problems undeniable—and fixable.

Conclusion: Practice the Hard Stuff Before It Hurts

Incidents will always be stressful. They don’t have to be chaotic.

By using an analog incident puppet stage—a handful of paper characters, a simple scenario, and a table—you can:

Rehearse your worst on‑call conversations before they’re real.
Expose gaps in your incident communication and handoffs safely.
Strengthen structured processes for documentation, overlap, and verification.
Build confidence and clarity across teams who rarely get to practice together.

You don’t need approval for new tooling or budget for a grand program. You can run your first session next week with office supplies.

Start small. Pick one uncomfortable scenario, one on‑call handoff, and put it on the puppet stage. The insights you gain in that low‑stakes rehearsal might be the difference between “we got lucky” and “we were ready” when the real incident arrives.