CodeNSM
The Standup · Part 10

The premortem that fits in a standup

2026-07-02· 7 min read· by Think North

Here's a strange, well-documented fact about how human prediction works: you get measurably better at figuring out why something might go wrong when you're told to imagine it has already gone wrong, rather than being asked to predict whether it will. Not slightly better. In the original 1989 study by Deborah Mitchell, J. Edward Russo and Nancy Pennington, shifting people into this "prospective hindsight" frame — imagining a future outcome as if it had already happened, then explaining why — increased the number of correct reasons people generated for that outcome by around 30%, compared to being asked to reason about the future directly.

The mechanism is almost embarrassingly simple once you see it: forecasting forward, you're weighing probabilities, hedging, staying diplomatically vague, because you don't want to be the person who talked the room into worrying about nothing. Reasoning backward from an outcome you're told to treat as already real, you're just explaining what happened — a completely different, much less socially fraught cognitive task, and one people turn out to be considerably better at.

Klein's version, and why it's the right shape for a standup

Gary Klein turned this into a practical technique in a 2007 Harvard Business Review piece: the premortem. Before a project starts, gather the team and say: it's some time in the future, and this project has failed — badly. Take a few minutes and write down every reason you can think of for why. Klein's core insight about why this works organizationally, not just cognitively, is worth quoting almost directly: it makes it safe to raise a doubt. Someone who might never say "I'm worried this will break checkout" as a standalone objection — because objecting out loud to a plan already in motion carries social risk — will happily write "the checkout refactor broke prod" as one contribution to a group brainstorm where the failure is already assumed to have happened. The premortem doesn't just improve the forecasting. It changes who's willing to speak.

Why a full premortem never survives contact with a real sprint calendar

Here's the honest problem: Klein's premortem, run properly, is a twenty-minute-to-an-hour workshop, done once, at the start of a project. Almost no team runs it for anything smaller than a genuinely large initiative, and by the time something's clearly "genuinely large," a great deal of the risk has often already been baked into decisions made weeks earlier. The technique is real and it works — and it's also structurally mismatched to the size and cadence of the decisions an ordinary sprint actually makes, one refactor and one deploy at a time, every week, forever.

So the premortem mostly doesn't happen at the size where it would matter most: the small, unglamorous, weekly decision — "we're refactoring this, it should be safe" — that's exactly the size of claim a standup makes constantly and a formal premortem workshop is never going to be convened for.

Compressing the whole technique into one sentence

Here's the move: you don't need the workshop to get the workshop's actual mechanism. The mechanism was never the meeting room, the sticky notes, or the hour on the calendar — it was the prospective-hindsight frame itself, the single cognitive trick of assuming failure and explaining backward from it instead of forecasting forward. That fits in one sentence, asked about one specific piece of work, inside the fifteen minutes you already have:

"If this breaks checkout, why would it have?"

Notice everything this single sentence inherits from the full technique. It assumes failure rather than asking someone to predict it, which per Mitchell, Russo and Pennington's finding gets a meaningfully more honest and more complete answer than "do you think this is risky?" ever would. It makes the doubt safe to raise, per Klein, because nobody's contradicting the plan — they're just explaining a hypothetical that's been stipulated as true. And it costs exactly one sentence, which is the only budget a standup actually has to spend on any single risk.

You don't need the workshop. You need the trick the workshop was built to deliver — and the trick fits in one sentence, asked about one specific piece of work, before it ships instead of after it breaks.

Turning the answer into a claim instead of a vibe

Here's where this whole arc closes the loop it opened ten parts ago. The premortem sentence, asked out loud, produces an answer: "it would break because the retry logic doesn't handle the new timeout path" — or three different answers, from three different people, which is its own valuable finding. Left as spoken words, that's exactly the kind of unfalsifiable dread this entire series has been arguing against: a worry, delivered fluently, that everyone nods at and nobody checks. Treated correctly, it's something else entirely — a risk claim, with a named subject (the retry logic), asked about a specific change, resolvable later against exactly one thing: did the fault rate on that subject actually rise after the change shipped, or didn't it.

That's the whole arc of "Before the Room," landing on its last step. A brief that exists before anyone has to remember to make it. Questions that don't waste the room asking what a dashboard already knows. A test for whether fluent confidence is actually understanding. An honest reference class instead of a hopeful Thursday. A structure that goes looking for the thing only one person knows. A bus factor with a number instead of a laugh line. The one question only a human can answer, asked instead of skipped. Context that comes with a date on it. An agenda that follows the code instead of the seating chart. And now, last: a risk stated out loud, in the form of a claim with a subject and a horizon, instead of a feeling everyone quietly agrees to carry alone.

None of these ten habits require new tooling to start tomorrow morning. What they require is treating the fifteen minutes in the room as the output of everything that happened before it — which was always the actual argument, ten parts ago, and is the whole reason this arc is called what it's called.

References

  1. Klein, G. (2007). Performing a Project Premortem. Harvard Business Review.
  2. Mitchell, D.J., Russo, J.E. & Pennington, N. (1989). Back to the Future: Temporal Perspective in the Explanation of Events. Journal of Behavioral Decision Making, 2(1), 25–38.

See your own codebase as an office.

One pip install and every function reports for duty — archetype, live state, debt tier, and a single Code-Health North-Star. Free plan, no card.

Read next