The Pre-Mortem Meeting That Prevents Incidents

Imagine the launch failed. Why? The 30-minute meeting that surfaces risks before they become incidents.

How to run it

The flow is question, silent write, then share. Independent thinking before group discussion prevents anchoring; cluster the themes; pick the top three risks for mitigation. Forty-five minutes covers it; longer dilutes focus.

• Frame the question. “It is six weeks after launch. The launch failed. What happened?” The prompt that makes hindsight available before launch.
• 5-minute silent write. Independent-thinking phase. No anchoring on the loudest voice in the room.
• Round-robin share. Each person reads their list; cluster themes; pick top three. Drives focused mitigation.
• Named facilitator. Responsible runner per meeting. Catches the “everyone-and-no-one” anchor risk that destroys these sessions.

Output

The output is a risk list with named owners and pre-launch mitigation deadlines. Risks that cannot be mitigated get documented as “we know about this”; post-launch comparison calibrates the team’s risk-spotting over time.

• Risk list with owners. Per top risk the mitigation owner and deadline before launch. Specific commitments, not vague intentions.
• Awareness over denial. Unmitigated risks documented as known. Launch with eyes open beats launch with hopes.
• Post-launch comparison. Pre-mortem versus actual review per launch. Calibrates the team’s risk-spotting accuracy over time.
• Published artefact. Captured doc per meeting. Future launches reference prior pre-mortems.

When to run

Pre-mortems are for high-stakes changes, not routine deploys. Customer-impact threshold; multi-service architectural changes; anything with a recovery cost worth the meeting time.

• Customer impact above threshold. Policy-defined dollar bar per launch. Above the threshold, run the pre-mortem.
• Multi-service architectural changes. Two-or-more-service-touch trigger. Cross-cutting changes have non-obvious failure modes.
• Not for routine deploys. Cost-of-pre-mortem rule. Reserve the meeting for high-stakes changes; routine deploys have other safety mechanisms.
• Explicit decision record. “Did we run a pre-mortem?” logged per launch. Supports postmortem clarity if something does go wrong.