In a blameless postmortem, what does "blameless" actually mean, and how does a team still hold anyone accountable?

## The claim blamelessness actually makes Blameless postmortems are usually sold as a cultural nicety. They are better understood as an information-gathering strategy with a measurable payoff. In any outage, the person who ran the command, approved the change, or misread the dashboard holds facts that exist nowhere else: what the terminal actually printed, what the runbook actually said, what they expected the system to do, and what else was on fire at that moment. If sharing those facts can cost them their reputation or their job, the rational move is to share as little as possible — and the organisation permanently loses the only copy of the data it needs to prevent a recurrence. Blame trades a durable loss of information for the momentary satisfaction of having someone to point at. ## Human error is where an investigation stopped The second claim is a systems claim: in a well-run engineering organisation, people are not usually careless. They act in a context — the tooling they were given, the alert that fired, the documentation that was two releases stale, the fact that it was 03:00 and the pager had already gone off twice. "Human error" describes the last event in a chain, not its explanation. The useful question is what made a wrong action *reachable*, *plausible* and *undetected*: a destructive command with no confirmation, a production shell that looks identical to staging, a runbook step everyone skips because it is slow. ## The substitution test The practical tool for holding the line is the substitution test, drawn from human-factors safety work: put a different engineer of comparable competence into exactly the same situation, with the same information, tools and pressures, and ask whether they would plausibly have done the same thing. If the answer is yes — and it usually is — the finding is about the system, and any remediation aimed at the individual is wasted. If the answer is genuinely no, you have learned something specific about a gap in tooling, training or expectations, which is still a system finding. Hindsight makes this harder than it sounds. After the fact you know which signal mattered; the responder was looking at fifteen signals and did not. Judging the decision by the outcome you now know is exactly the bias blamelessness is designed to suppress. ## Where accountability actually lives Blamelessness removes punishment, not responsibility. Three obligations remain: 1. **The duty to explain.** Everyone involved is expected to describe honestly and promptly what they saw, believed and did. Withholding that is a genuine failure of accountability. 2. **Ownership of the fix.** The corrective work is assigned to named owners and tracked. "No blame" never means "no owner." 3. **Management's separate responsibility for behaviour.** Just-culture models distinguish honest error (console the person, fix the system), at-risk behaviour where someone drifted into a shortcut without recognising the risk (coach, and remove the incentive to drift), and reckless behaviour where someone knowingly disregarded a substantial risk (a disciplinary matter). Only the first two are postmortem material. The crucial refinement is that the category is decided by the *behaviour*, not the *outcome*. The same shortcut that caused nothing on Tuesday and a customer-visible outage on Wednesday is the same behaviour; punishing it only when it happens to be expensive teaches the team that reporting is a lottery. ## What it looks like in the room - The review is facilitated by someone who was not involved in the incident. - The person who took the action often writes the postmortem themselves — a strong signal, and one that only works if it costs them nothing. - Counterfactual phrasing ("should have noticed", "failed to check") gets struck in review, because it describes a world that did not happen and quietly assigns fault. - Remediation targets hazards and guardrails, not the individual. "Retrain the engineer" is the weakest control available and usually means the analysis stopped early. ## Common failure modes to name in an interview - **Blameless read as "no consequences ever."** Leadership abandons the practice the first time an outage is expensive. Pre-agreeing where the line sits — recklessness and malice go to management — protects the practice. - **Blameless theatre.** No names in the document, followed by a quiet conversation with the person's manager. Everyone learns the real rule within one incident. - **Blameless confused with vague.** A blameless postmortem is *more* specific about what happened, not less; it just describes actions and conditions instead of character. - **Protecting the individual instead of the information.** The goal is not to spare feelings; it is to get the whole story so the next team does not repeat it. An interviewer asking this question is checking one thing: whether you can hold both halves at once — a system-first analysis and real organisational accountability — rather than reciting a slogan.