The post-mortem that actually changes behaviour

Post-mortems are one of the highest-leverage operational rituals available to a team — and one of the most consistently mis-run. Most produce a document nobody reads and a list of action items nobody owns. The format that produces genuine behaviour change is different in three specific ways.

Why most post-mortems fail before they start.

The standard post-mortem ritual goes like this: something goes wrong, a meeting is called, people sit in a room and describe what happened in chronological order, someone writes down a list of things to do differently, the list is added to a Confluence page, and life resumes. Six weeks later, another version of the same problem occurs. The Confluence page has twelve views, two of which were the person who wrote it checking that it uploaded correctly.

This is not a document problem. It is a design problem. The ritual is structured to produce a record, not a change. The output — the document, the action list — is treated as the goal. It is not. The goal is that the team behaves differently in a specific situation in the future. Everything else is overhead.

The post-mortems that produce measurable operational improvement share three structural differences. They are not about format or template — they are about the purpose of each part of the meeting and the conditions under which the meeting is held.

Difference one: The unit of analysis is the system, not the individual.

The single most destructive element in a post-mortem is the implicit question: who did this? Even when a room of well-intentioned people agrees beforehand to be "blameless," the structure of a chronological retelling naturally surfaces moments where a person made a choice that turned out to be wrong. The instinct — even among supportive teammates — is to categorise that choice as a failure of judgment. That categorisation is almost always incorrect, and it is always unhelpful.

When a person makes a decision that contributes to a bad outcome, the honest question is: given the information they had, the tools available to them, the pressure they were under, and the organisational norms they had absorbed, was their decision reasonable? In the vast majority of incidents, the answer is yes. A reasonable person, in the same conditions, would have made the same call. Which means the problem is the conditions, not the person.

The practical way to enforce this shift is to ban the passive voice and the absent actor in post-mortem documents. "The wrong configuration was deployed" is not useful — it obscures the conditions that made the deployment happen. "Deployment happened without a review step because the review checklist only applies to production, and this was a staging environment that serves enterprise clients" is useful. That sentence tells you exactly where the system failed and what to fix.

The rule is: every action has an actor, and every actor had reasons. Write those reasons down. Do not summarise them away. The reasons are where the systemic failure lives.

Difference two: The facilitator is structurally separated from the outcome.

The most common facilitation mistake is having the person with the most authority in the room also lead the post-mortem. This is nearly always the founder or the engineering lead. The problem is that their authority changes what people say. In a room where the person asking the questions also holds career consequences, people describe their decisions in the most defensible light available. This is not dishonesty — it is a rational response to social risk. The result is a sanitised narrative that omits the uncomfortable moments of genuine uncertainty and covers over the decisions that felt wrong even as they were being made.

A post-mortem facilitator should have no stake in the outcome and no authority over anyone in the room. At early-stage companies, this often means rotating the facilitation role to someone from a different function who was not involved in the incident. A product manager facilitating an engineering post-mortem will ask different questions than the engineering lead would — not better questions necessarily, but questions that are not shaped by the implicit need to protect the team's narrative.

The facilitator's job is not to drive toward conclusions. It is to slow the group down at moments of apparent consensus and ask: is that actually what happened, or is that the story that feels safest to tell? The best post-mortem question in the arsenal is: "What did you believe at that moment that turned out not to be true?" That question surfaces the assumptions that were wrong — and assumptions are where the structural failures hide.

Difference three: Action items have one owner, a due date, and a review mechanism.

The action item graveyard is universal. Every team above twenty people has a backlog of post-mortem action items that are technically open and practically dead. The items were reasonable at the time. The team meant to do them. But they were added to a backlog that already had sixty other things in it, and the social pressure to close them was lower than the pressure to ship the next feature.

The format that produces closure has three components that are rarely all present at once. First, one named owner — not a team, not a role, one person whose name is attached to the item. Second, a due date that is the date by which the item will be complete, not the date by which someone will "look into it." Third, a review mechanism — a standing agenda item in a recurring meeting where open post-mortem items are surfaced and the owner is asked whether it is done.

The review mechanism is the piece that is almost always missing. It is also the piece that does the most work. The social cost of having to explain in your weekly team meeting why an item you committed to close is still open is far more effective than any project management tool. Visibility creates accountability. The document that no one reads creates none.

The five-question format.

A post-mortem format that works consistently runs to five questions, answered in sequence, with a facilitator who has permission to slow the group down when the answers get too tidy.

One: What happened, in specific and observable terms? Not "the system went down" but "at 14:23, customer-facing API response times crossed 3000ms, remained elevated for forty-two minutes, and affected all customers in the APAC region." Specific, observable, not yet analysed.

Two: What were the decision points? List every moment at which someone chose to do something or not do something that is now visible as having affected the outcome. Do not evaluate these decisions yet — just list them.

Three: For each decision point, what did the decision-maker believe at the time, and why was that belief reasonable given what they knew? This is the question that separates blameless from accountability-free. You are establishing that the decision was rational, which sets up the next question.

Four: What about the system — the information available, the tools, the processes, the incentive structures — made those beliefs available and those decisions seem correct? This is where the root causes live. Not in the person, but in the conditions.

Five: What specific changes to the system would make the better decision the path of least resistance next time? These are your action items. Each one maps to a systemic failure identified in question four. Each one has one owner, a due date, and will be reviewed.

• 01
  Run it within 72 hours. Memory degrades quickly and, more importantly, it rationalises. The post-mortem held three days after an incident captures the confusion and uncertainty people actually felt. The one held two weeks later captures the clean story they have since constructed. You want the raw version — the one where people say "I wasn't sure" rather than "I decided to."
• 02
  Separate facilitation from authority. The highest-authority person in the room should not be the facilitator. Their presence as questioner changes what people say. If you are the founder or the lead, your job in a post-mortem is to listen, to ask one or two questions, and to close the meeting with a clear statement of the systemic changes you are committing to make. It is not to run the session.
• 03
  Trace every action back to conditions, not character. When you find a decision that contributed to the incident, do not stop at the decision — trace it back to the conditions that made it seem correct. What information was missing? What process failed to surface the risk? What norm made it acceptable? The conditions are the system. Character is not the unit of change.
• 04
  Limit action items to what can close in thirty days. A post-mortem that produces eight action items of which three require architectural changes and two require vendor negotiations is a post-mortem that will close nothing. Separate the long-horizon changes (which belong on a roadmap) from the short-horizon changes (which should close within a month). Only the short-horizon items go on the post-mortem action list.
• 05
  Publish the document to the whole company. Transparency about what went wrong and what you are doing about it is one of the fastest ways to build operational trust. Teams that publish post-mortems openly — not just to the team involved but to everyone — create a norm that failure is analysed, not hidden. That norm produces faster reporting, which is the input to faster recovery.

Frequently asked questions.