Inversion and the Pre-mortem

Instead of asking how to succeed, ask what would guarantee failure — then avoid it.

Imagining the failure first turns hidden risks into mitigations you can act on today.

To an executive

Teams are often better at spotting what would sink a project than what would make it shine. Asking early how it could fail cuts surprises and wasted spend.

To an engineer

Run a pre-mortem before building. Assume the project failed, list independently why, and turn the most likely causes into design changes, tests or monitoring now.

The idea

The mathematician Carl Jacobi is credited with the advice "invert, always invert", later popularised by Charlie Munger. Many problems are easier to solve backwards: it is often clearer what would make a system fail than what would make it great.

Gary Klein's pre-mortem, described in Harvard Business Review in 2007, applies this to projects. Imagine it is some time in the future and the project has failed. Each participant writes down, independently, why it failed. The team then works back from those reasons to changes it can make now.

Why it works

Failure is easier to picture than success. Asking "what could go wrong?" invites vague worries. Stating that the project has failed and asking "why?" produces specific, concrete causes.

It makes dissent safe. Klein's point was that people often keep their doubts to themselves during planning. A pre-mortem turns finding problems into the task, so raising them is no longer disloyal.

It counters optimism. Plans are written by people who believe in them. Inversion deliberately takes the opposing view before reality does.

Where it applies

Major migrations and platform bets, before the commitment is made.
Threat modelling, by asking "how would I break this?"
Resilience design, by asking "what would take us down?" rather than "how available are we?"
Incident follow-up, to find the next failure before it happens.

How to apply

Set the scene. State the plan, then announce: "It is a year from now, and this has failed badly."
Collect reasons independently. Give everyone a few minutes to write down causes before anyone speaks, so the loudest voice does not set the list.
Share and group the reasons, then rank them by likelihood and impact.
Turn the top reasons into actions: a mitigation, an early test, a decision point or a change of plan, each with an owner.

Example scenario

A bank was about to re-platform its core ledger, with a parallel run planned before cutover. In a pre-mortem, several people wrote some version of the same reason for failure: "we could not reconcile balances between the old and new systems during the parallel run, so we could not prove the new one was right."

Reconciliation had been planned as a manual task near the end. The team moved it into the first phase and built an automated reconciliation service that ran daily from the start of the parallel run. Differences were found and fixed months before cutover, rather than discovered on the night.

Questions to ask

Imagine this has failed a year from now. What is the most likely reason?
What would an attacker, or plain bad luck, do to this design?
What must we never do here, and what in the plan makes it likely?

When not to use it

Small, reversible changes, where trying it and watching is cheaper than a workshop.
Teams already gripped by fear, where a list of ways to fail can stall a decision that needs to be made; there, pair it with a clear plan for acting on the results.

How it misleads you

Inversion can turn an architect into the person who only ever explains why things will fail. The output of a pre-mortem should be mitigations and early tests, not a veto. If every pre-mortem ends with "do not proceed", the exercise has become a way to avoid risk rather than to manage it.