Run an incident tabletop that lets people think

The group has found two reasonable next steps. One person wants to compare worker versions; another wants to inspect storage. As facilitator, you know what each path could reveal. The tempting move is to steer everyone toward the question you wrote first.

Let them choose instead. A good tabletop gives people room to reason, then supplies evidence they can use. In this fictional Dispatch exercise, a shared document is enough to follow how a team seeks help, chooses actions and checks whether waiting customers finally receive their exports. Agree on scope, invite the participants and keep every action simulated.

Decide what you want to observe

Before adding twists, name the capabilities the exercise should reveal. Here, the team needs to distinguish customer impact from component health, find authority for a mitigation and check old queued exports as well as new ones after a repair. Those decisions give the scenario a purpose beyond keeping the room busy.

Assign an incident lead, service investigator, dependency representative, communications owner and observer. A small group can combine jobs openly. The facilitator supplies evidence and advances the scenario’s clock; the participants make the difficult decisions. You are arranging a useful problem, not auditioning people for the answer in your notes.

Give different good questions somewhere to lead

Start with delayed exports and healthy API checks. The component looks available, yet customers lack their reports. If participants investigate the deployment, offer a failed export from the old version. If they inspect storage first, let them find timeouts. Either route can move the investigation forward; nobody should have to say your preferred phrase to unlock the next fact.

When the group proposes the risky storage repair, make the primary approver unavailable. After a simulated repair, offer successful new exports alongside old ones still queued. For every piece of evidence, write down what it establishes and what remains unknown.

Give reasonable actions reasonable consequences. If every mitigation fails because of a hidden complication, participants end up studying the facilitator’s tricks rather than the service. There can be uncertainty without a trap behind every sensible choice.

Before revealing a result, ask what the proposed action is expected to change. In this scenario, a submission cap lowers arrivals while older exports remain stuck. Hearing the expectation first lets the group compare relieving incoming demand with restoring the processing of work already accepted.

“We restart storage” changes the document, not the service

Participants should identify who would authorize each action and record the simulated approval. Leading an incident does not supply all production permissions. Make equally clear that saying “we restart storage” during this exercise runs no real command.

If a real incident begins, pause the tabletop and follow the organization’s response process. The people customers need should not have to keep one eye on the live service and the other on its fictional counterpart.

Notice what was needed at the difficult moment

The observer follows each decision: available evidence, choice, responsible person and unresolved question. Record when an undocumented fact or facilitator hint became necessary. A smooth answer can still depend on information a real responder would not have.

For a concrete observation, ask whether the group can obtain storage-repair approval when the primary approver is away. Where did participants look? What did they supply? Did a hint get them past the gap? These details offer much more to improve than “the team communicated well.”

When participants propose closing the incident, ask what they intend to check before revealing the old backlog. Their answer shows whether recovery already includes customers who were waiting before the repair, or only the successful new exports arriving afterward.

At the debrief, let the participant explain a pause before prescribing a fix. A missing contact, unclear authority and unavailable compatibility evidence can all look like hesitation from across the room. One needs a reachable person, another a clearer decision boundary, and the third the information required to choose safely. The visible pause alone does not tell you which.

Repair one moment, then replay it

Choose one or two changes the group can test again. If the approval route was missing, repair it and reintroduce the unavailable approver. Watch whether the next decision becomes possible. That second attempt connects an edit to what someone can now do with it.

Keep the objective, roles, evidence sequence, observations and follow-up test together so another facilitator can run the exercise. Before participants work through it, this is a prepared scenario, not a completed rehearsal. Afterward, their actual choices and difficulties give the next version its material. The most useful surprise may be neither a dramatic failure nor a perfect response, but the small missing detail that finally becomes visible when someone else tries to proceed.

Sources

Google’s incident-response chapter provides process context. This illustrative facilitator design needs adaptation to the participating organization’s procedures.