Pre-Mortems Beat Post-Mortems

Shawn West

Jun 19

8 min read

Updated: Jul 13

The pillar essay on pre-mortems as quality practice. Read the manifesto first.

The Asymmetry

A post-mortem takes a week. Sometimes more. There is an incident on Tuesday, ten people on the response, two days of war-room intensity, then five days of documentation, root-cause analysis, action items, and the political theater of who-could-have-prevented-what. Customers were affected. Trust was lost. The team is tired. The action items go on the list. Most of them get done. Some of them do not. The team's quality bar is, temporarily, raised — until the memory of the incident fades.

A pre-mortem takes ninety minutes. There is a meeting. The team imagines the launch has happened and failed. They write down why. They identify mitigations. They put the mitigations into the project plan. The team goes back to work. Customers are not affected. Trust is not lost. The team is no more tired than they were at the start of the meeting.

The two practices produce overlapping information at radically different cost. The post-mortem produces detailed analysis after the fact. The pre-mortem produces good-enough analysis before the fact. For most decisions, good-enough-before is more valuable than perfect-after, because the action you can take with good-enough-before is "do not have the incident in the first place."

Most teams have a post-mortem culture and no pre-mortem culture. This is the inverse of where the leverage is.

How to Run a Pre-Mortem

The format is simple enough that the simplicity is the trap — teams that skip it because it looks light are missing the part where the lightness is doing the work.

Step one: Set the scene. Tell the team: "It is six months from now. We launched the [thing]. It went badly. Customers complained, leadership is asking what happened, we are in incident review. We are here to figure out why." The framing matters. You are not asking the team to imagine what might go wrong. You are asking them to imagine that it has gone wrong and to explain it. The mode is investigative, not speculative.

Step two: Silent writing, ten minutes. Each person writes, individually, their version of what happened. Specific. Concrete. Failure modes named, not gestured at. "The migration ran in production with a stale cache, so reads returned old data for two hours" rather than "there was a caching issue." The silent phase matters because group brainstorming converges too quickly on the loudest person's first idea.

Step three: Round-robin, fifteen minutes. Each person reads their list out loud. No discussion yet. As people read, the room builds a shared inventory of failure modes. The list will be longer and more diverse than any one person produced. The diversity is the value.

Step four: Clustering and ranking, thirty minutes. The team groups related failure modes. They rank them by combined probability and impact — high probability + high impact at the top, low probability + low impact at the bottom. The top three to five are the focus.

Step five: Mitigations, thirty minutes. For each of the top failure modes, the team identifies one specific mitigation. Not "be careful." Not "monitor closely." A specific change to the project plan: an additional test, a different rollout strategy, a feature flag, a rehearsal, a runbook, a named owner for the failure mode. The mitigation has to be actionable enough that someone can commit to doing it by a date.

Step six: Go/no-go criteria, five minutes. The team agrees that the project does not ship until the mitigations for the top failure modes are in place. This step is the one most often skipped, and it is the step that determines whether the pre-mortem changes outcomes or just produces a document.

That is the entire format. Ninety minutes. The artifact is a one-page document with the failure scenarios, their probability/impact ranking, the mitigations, and the go/no-go criteria. The artifact is also durable — you reference it during the project, especially when something starts to look familiar.

Why Most Teams Don't Run Them

The format is cheap. The technique is well-documented. Most teams could adopt it tomorrow. They do not. The reasons are revealing.

The cultural cost of admitting failure is possible. Pre-mortems require the team to take seriously that the project might fail. In organizations where pessimism is socially expensive — "we don't want to be negative" — pre-mortems are uncomfortable. The team is asked to act, for ninety minutes, as if failure has occurred. This requires permission from the leader to be openly pessimistic in a structured way. Leaders who cannot grant that permission cannot run pre-mortems. The exercise is read as defeatism.

The illusion of control. "We have it under control" is the most expensive sentence in software. Pre-mortems are an admission that control is partial — that the team can imagine, in real detail, the ways the project escapes their control. Teams that need to perform confidence cannot do this. Teams that have permission to be honest about uncertainty can. The cultural prerequisite is leadership that treats honest uncertainty as professional rather than alarming.

The cost of the action items. A pre-mortem that produces no action items is theater. A pre-mortem that produces action items requires those items to be funded. Some teams quietly avoid pre-mortems because they know the output will be a budget conversation they do not want to have. The avoidance is sensible from the team's perspective and disastrous from the organization's perspective. The action items would be cheaper to fund than the incident they prevent, but the funding is visible and the incident is hypothetical. The math is the same one that bedevils most quality investment.

The optics of explicit failure planning. In some organizations, documenting a failure plan in writing is treated as inviting the failure. "If we write it down, it will happen." This is superstition dressed as risk management. It also has, in some legal and regulatory contexts, a real basis — written acknowledgement of a known risk that subsequently materializes can be evidence against the organization in litigation. The mitigation is to write pre-mortems with that risk in mind: focus on mitigations rather than blame, treat the artifact as a planning document rather than a confessional. The legal concern is real but solvable.

When to Run Them

Pre-mortems are too expensive to run for everything and too valuable to run for nothing. The right cadence varies by team. The pattern that works:

Every major launch. Customer-facing product launches, major feature releases, migrations with public commitments. Anything where a failure becomes a story.
Every architectural change that is hard to reverse. Database migrations, data model changes, breaking API changes, switching cloud providers, replacing a critical dependency. The hard-to-reverse criterion is doing real work — these are the changes where the pre-mortem's value is highest because the post-mortem cost is highest.
Every external dependency adoption. Adding a new vendor, a new SaaS, a new service to the critical path. The pre-mortem here is largely about the vendor failing — not the team's own failure modes, but the dependencies the team is about to acquire and the implications of those dependencies failing.
Quarterly, for the system as a whole. Once a quarter, pick the riskiest piece of the system and pre-mortem it. Imagine that piece fails in the next six months. What does the failure look like? What would you wish you had done? The system-wide pre-mortem catches the failure modes that no specific project surfaces, because they live in the gaps between projects.

A team running ten to fifteen pre-mortems a year, calibrated to the projects with the most downside, is doing the work. A team running pre-mortems on everything is doing ceremony. A team running them on nothing is paying the post-mortem cost.

The Blind Spots

Pre-mortems do not catch everything. They have predictable blind spots worth naming.

They underweight unknown unknowns. The team can imagine the failure modes they have language for. They cannot imagine the failure modes for which they have no concept yet. A new technology, a new attack vector, a new regulatory regime — these often produce incidents that no pre-mortem foresaw because no one in the room had the vocabulary.

They underweight slow failures. Pre-mortems tend to imagine acute incidents — the launch breaks, the migration corrupts data, the deployment fails. They are less good at imagining chronic failures — the system slowly accumulates technical debt, the team slowly burns out, the customer trust slowly erodes. These slow failures are often the most consequential and the hardest to surface in a ninety-minute exercise.

They depend on the team being honest. A team performing for the leader will pre-mortem the safe failure modes and skip the embarrassing ones. The leader's job is to make it safe to name the embarrassing failure modes, by demonstrating in the room that they will be received as useful information rather than as criticism.

Pre-mortems do not replace operational rigor, monitoring, defense in depth, or any of the other practices that catch what they miss. They are a planning artifact. The planning is the leverage; the other practices are the safety net.

The Leadership Artifact

A pre-mortem is, finally, a leadership artifact. The team can run them. The leader has to fund them, attend them, take them seriously, act on the output, and reference the document later when its predictions start to come true. The leader who attends one pre-mortem, sees the team produce a sober list of failure modes, and chooses to fund the top three mitigations is sending a strong signal about the kind of organization they are running. The leader who skips the meeting, deletes the calendar invite, or attends and says "let's not be pessimistic" is sending the opposite signal.

The difference, over five years, is the difference between an organization that has occasional incidents that it learns from and an organization that has frequent incidents that it does not learn from. The pre-mortem culture compounds. The post-mortem-only culture does not.

Ninety minutes, every meaningful project. The cheapest insurance the team has access to. The teams that do not run them are not deciding to skip insurance — they are deciding to defer the conversation about whether they want the insurance, which is the same as deciding not to have it.

Frequently Asked Questions

How is a pre-mortem different from a risk assessment?

A risk assessment lists risks abstractly and rates them. A pre-mortem assumes failure has already happened and asks the team to explain why. The framing change is the entire point. Risk assessments produce lists of generic hazards that everyone agrees with and no one acts on. Pre-mortems produce specific failure narratives that people have committed to as plausible, which makes the mitigations easier to fund. The format is psychologically different in ways that show up in the quality of the output.

Should pre-mortems be run for every project?

No. Pre-mortems take time and attention. Running them for routine work dilutes the format and trains the team to treat them as ceremony. Reserve them for changes with meaningful downside: launches with significant customer impact, architectural changes that are hard to reverse, migrations that touch shared infrastructure. The rule of thumb: if the worst-case scenario for a project is 'we wasted a quarter,' a pre-mortem is overkill. If the worst case is 'we have an outage that costs customers' or 'we cannot get back to where we started,' it is worth the ninety minutes.

What do you do with the output?

Three things. First: the highest-risk scenarios get explicit mitigations added to the project plan, with named owners. Second: the team writes the mitigations into the project's go/no-go criteria — the change does not ship until the mitigations are in place. Third: you save the pre-mortem document and refer to it during the project, especially when something starts to go wrong. Often the pre-mortem will have predicted the early signs of the failure, and you can act on the predictions before the failure compounds.

What if leadership won't fund the mitigations the pre-mortem identifies?

Then the pre-mortem has surfaced a real disagreement about risk tolerance, which is more useful than discovering the disagreement during the incident. The conversation moves from 'should we fund the mitigation' to 'we've agreed this failure mode is plausible — are we accepting the risk or paying to avoid it?' Leadership owns the answer. The team's job is to ensure the question is asked explicitly, so the answer is on the record. Accepting a known risk is a defensible decision. Discovering the risk during the incident is not.