The Pre-Mortem, Run Properly: Surfacing the Risks Your Team Already Knows

The retro that came too late

Twelve months from now, you are sitting in the retrospective for the plan you are about to approve. The launch missed, the numbers are bad, and the room is doing the thing rooms do in retros: explaining, fluently and in detail, why it was always going to go wrong. The vendor dependency everyone privately doubted. The hiring assumption nobody believed. The integration risk that one engineer mentioned once, quietly, and never again.

Here is the uncomfortable part: most of that knowledge exists today, in the heads of the people who will sit in that retro. Your team is not failing to see the risks. It is failing to say them — because the plan has a sponsor, the sponsor is in the room, and nobody builds a career on being the person who listed reasons the boss's plan will fail.

The pre-mortem is the ritual built for exactly this. Gary Klein described it in Harvard Business Review in 2007: tell the room the plan has already failed, twelve months out, and ask everyone to write down why. The tense change does real work — research on prospective hindsight finds that imagining an outcome as certain, rather than merely possible, increases the number and specificity of causes people generate. And the framing does social work too: you are no longer criticising the sponsor's plan; you are explaining a fictional past. Everyone is suddenly allowed to know what they know.

Why people already knew

It is worth being precise about what the pre-mortem fixes, because it is not an analysis technique. The failure modes it surfaces were almost always known to someone before the decision. What blocked them is the standard machinery of group deference: dissent is socially expensive, early opinions anchor later ones, and the person with the decisive worry is often the most junior voice on the call. Our pieces on structured disagreement and steelmanning walk that machinery in detail — the pre-mortem is the applied countermeasure.

That is also why running it with the right mechanics matters more than running it with enthusiasm. The two load-bearing properties are independence — everyone writes before anyone sees anyone else's causes — and attachment — every cause stays connected to the plan it threatens, with an author, so it can be questioned, challenged, and mitigated rather than photographed on a whiteboard and forgotten.

Step 1: Frame the plan as a claim

Create the discussion with the plan as its root argument — stated as a committed claim, not a question: "We will ship X to segment Y by Q2." The phrasing matters. A question ("should we ship X?") invites debate about whether; a claim creates a thing that failure causes can attack. One sentence, dated, owned by the plan's sponsor.

Then deliver Klein's framing to the room, verbatim if you like: "It is twelve months from now. This plan failed — badly. Take ten minutes, alone, and write down every reason why."

• ✓Root claim created — the plan as one committed sentence, authored by its sponsor. Checkpoint: it reads as a claim something can attack, not a question.

Step 2: The silent ten minutes

Each participant now adds failure causes as con-arguments under the plan — independently. This is where the tool earns its place over the whiteboard: a cause is only visible to others once submitted, so nobody anchors on the first confident voice, and nobody softens their risk after seeing the sponsor's face. Ask for at least three causes each, written as specific claims ("the SSO integration slips past the pilot date"), not categories ("technical risk").

Optionally, run an AI sweep alongside: have additional failure modes generated from multiple models. They arrive visibly labelled as machine-suggested — provenance is stamped on every argument — so the room can always tell an engineer's lived worry from a model's pattern-match. Keep them separate in your reading, too: the AI widens the space of candidate risks; it does not know your organization.

• ✓Silent generation complete — everyone submitted independently. Checkpoint: ≥3 causes per participant; nobody edited anyone; AI causes (if any) visibly labelled.

Step 3: Interrogate what surfaced

Now the room reads the tree — and instead of an open discussion where the loudest reader wins, the causes get worked through three structured moves, each a four-turn dialogue between a challenger and the cause's author:

One feature is worth calling out, because it changes what the AI sweep is worth: machine-suggested causes answer back. An argument authored by a model auto-responds in its chains — routed to the same model that wrote it — so you can cross-examine a machine-suggested failure mode and get a substantive reply immediately. That is the concrete answer to "why not just ask a chatbot for a risk list": a list cannot be questioned.

Step 4: Rate, and read the spread

Every participant rates every cause — one rating each, a value with a label. Sort by the distribution, and then do the thing most rooms skip: look at the spread, not just the mean. A cause everyone rates 8 is a priority. A cause half the room rates 9 and half rates 2 is something better: a genuine disagreement about how the world works, surfaced and named. Those splits are usually the most valuable finding of the whole session.

• ✓Prioritisation done — causes rated by everyone. Checkpoint: top causes identified; high-variance causes flagged as disagreements, not averaged into the middle.

Step 5: Mitigations as counter-arguments

For each top cause, add mitigations — and here the tree does something a list cannot. A mitigation is added as a con of the cause: an argument attacking the failure mode. And because pro/con is relative to the parent, a con-of-a-con supports the plan — the structure encodes the logic natively. Each mitigation has an author, and the author is the owner.

This is the moment the pre-mortem usually dies in whiteboard form: risks get listed, heads nod, nothing gets an owner. Here the checkpoint is structural — a top cause without a mitigation hanging under it is visibly naked.

• ✓Mitigations attached — every top cause carries at least one counter-argument with a named author. Checkpoint: no top-rated cause left bare.

What you still have in six months

The artifact is the point. Six months from now, when something goes wrong and someone asks "did we consider this?", the answer is one search away: the plan, every objection raised against it, who raised each one, the challenges each survived, and the mitigation that was (or was not) attached. A photographed whiteboard cannot answer that question; this can — it is a working instance of the decision quality chain, built in ninety minutes.

Honest limitations

• ✗Tooling does not create psychological safety. Independent submission removes the anchoring problem; it does not remove a manager who punishes dissent. If people fear the sponsor, fix that first.
• ✗AI-generated risks are prompts for thought, not a risk register. They are labelled for exactly that reason. A cause nobody will own is not a finding.
• ✗Ratings are a single labelled value, not a probability × impact matrix. If you need a formal risk matrix, export and build it elsewhere — do not pretend the rating is one.
• ✗A chain is four turns, then complete. It is a structured exchange, not an endless thread. If a disagreement needs more, it needs a meeting.
• ✗A pre-mortem does not decide anything. It surfaces and prioritises; the decision — and the courage to change the plan — is still yours.

Practical lessons from running these

• ✓Time-box the silence hard. Ten minutes, announced, enforced. The value is in the independence; the moment discussion starts, it stops accumulating.
• ✓Ask for specific sentences, not categories. "Integration risk" prioritises nothing; "the SSO integration slips past the pilot date" can be challenged, rated and mitigated.
• ✓The sponsor writes too. Nothing licenses honesty like the plan's owner contributing three failure modes of their own — first.
• ✓Close the loop in the next planning session. Reopen the tree, check which mitigations happened, and rate the causes again. The second pass takes twenty minutes and is where the ritual compounds.

Back to the retro

Return to that twelve-months-out retrospective. Either version of it can happen. In one, the room fluently explains a failure it quietly predicted, and the record shows nothing. In the other, the retro opens with the pre-mortem tree: here is what we said could go wrong, here is what we did about it, here is the one we missed. The second retro is shorter, kinder, and the only one that makes the next plan better. Ninety minutes, this week, buys it.