Blameless Postmortem

A postmortem's value is entirely a function of the accuracy and completeness of the information it collects. Anything that reduces disclosure reduces that value directly.

Blame reduces disclosure. Under threat, people omit details, present decisions as more deliberate than they were, and avoid mentioning the shortcut that seemed reasonable at the time — and those omissions are precisely the systemic causes. The reason an engineer skipped a check is the finding: the check was inconvenient, the tool did not surface the state, or the runbook instructed it.

Blamelessness is therefore an information-gathering technique, and treating it as a cultural nicety misunderstands why it works.

Why it matters

The alternative produces a predictable and useless output: the proximate human action is identified as the cause, and the action item is "be more careful." Nothing about the system changes, and the same incident recurs with a different person's name attached.

The productive reframing is a single question: "why did this action seem correct at the time?" People generally act reasonably given their information and incentives, so an action that seemed correct and was harmful indicates a system that misled them — which is a fixable property, unlike human fallibility.

Implementation patterns

• A timeline of what was known at each point, not only what happened. The divergence between the system's state and the responders' understanding is where most of the duration lives, and it is invisible in a purely factual account.
• Contributing factors rather than a root cause. Complex failures have several necessary conditions, and "the root cause" is a narrative convenience that discards most of the learning.
• Separate analysis of why it happened, why detection took as long as it did, and why diagnosis did — three problems with three remedies, and time-to-restore is usually dominated by the latter two.
• Actions with owners and dates in the ordinary backlog, ranked with everything else.
• Few actions. Twenty means none are completed; three completed is a better outcome and requires choosing.
• A "what went well" section, since the mechanisms that limited the damage are the ones worth investing in further and are invisible if only failures are recorded.
• Class-level actions: "what else could fail this way?" is what produces leverage beyond the instance.
• Written by the responders with a facilitator, so the knowledge comes from the people who hold it.
• Actions accepted or explicitly declined in a review forum, since an unaccepted action is a finding that will recur.

Industry example

The practice is most associated with Google's SRE model, where postmortems are blameless by policy and where the published guidance is explicit that the objective is accurate causal understanding rather than accountability assignment. It has been adopted broadly, and the adoption is frequently partial.

The instructive counter-case is the incident whose analysis stops at a human action. Reviews of large public outages — including the 2024 CrowdStrike event and various cloud control-plane incidents — consistently find that the productive findings were structural: absent staged rollout, missing validation against the real consumer, no local rollback, no blast-radius limit. None of those are discoverable by asking who made the change.

Failure scenarios

• Blame present implicitly, through tone, audience or consequence, which suppresses disclosure as effectively as explicit blame.
• "Human error" as a conclusion, which is a description of the last step rather than an explanation.
• A single root cause, discarding contributing factors.
• Actions on a separate security or reliability list reviewed quarterly, and therefore never completed.
• Twenty action items, guaranteeing none are done.
• Postmortems written and never read outside the team — the single largest waste in the practice.
• Completion untracked, when uncompleted postmortem actions are the best available predictor of the next incident.
• The postmortem as a compliance artefact, produced to a template and filed.

Trade-offs

Blamelessness is sometimes read as an absence of accountability, and the tension is real where an incident involves genuine negligence or a deliberate violation. The resolution is that blameless analysis and performance management are separate processes with separate forums — conflating them destroys the analysis, and pretending the second never applies is not credible to leadership.

Thorough postmortems also cost significant time from the people who are most needed elsewhere, immediately after an incident that has already consumed their week. That cost is real, which is why a severity threshold and a short, focused format matter more than comprehensiveness.

The trade is time and a degree of accountability discomfort in exchange for accurate causal information and systemic fixes. For any organisation whose incidents recur, it is the highest-leverage process change available — and the leverage comes entirely from the actions being completed, without which the practice is documentation.

Interview question

"An engineer ran a command that took down production. Tell me how you would run the review, what your first question would be, and what you would do differently if it emerged that they had bypassed a control deliberately."