Blameless culture, taken seriously — and its one hard line

TL;DR

When something breaks, support the person who broke it; don’t blame them. Almost every failure is a systemic one wearing an individual’s name — the person acted reasonably given what they knew and what the system let them do. Run post-mortems with real ceremony — they are a serious ritual, not a form to fill in — and don’t just fix the thing: learn. Learn at every level, not only the software: what about the organization, the culture, the process, and the engineering practices made this likely? This holds even if you’re a team of one.

There is exactly one hard line. Blamelessness protects honest mistakes; it does not protect dishonesty. Someone who evades or blames others gets coached — firmly — because that behaviour breaks the culture. Someone who hides, alters, or destroys evidence is an immediate termination offense, no exceptions. The whole system runs on people telling the truth about what happened; protect that absolutely.

Context

Blame feels like accountability, but it’s the opposite: it teaches people that the safe move when something goes wrong is to go quiet, minimise, and protect themselves. The instant blame is on the table, the truth goes underground — and the truth is the only thing a post-mortem has to work with. You trade a real understanding of how your system fails for the satisfaction of having someone to point at, and you get neither safer nor wiser. This is the same psychological safety that lets people raise concerns before the incident: people only tell you the whole truth if telling it is safe.

The reframe that makes this work — the blameless post-mortemJohn Allspaw — Blameless PostMortems and a Just CultureJohn Allspaw's case that effective post-mortems treat engineers as having acted reasonably given what they knew at the time, and focus on the systemic conditions that made an error likely rather than on punishing the individual — because blame drives the truth underground and you lose the chance to learn. A just culture balances learning with accountability.etsy.com ↗ and the just culture behind it — is to assume the engineer acted sensibly given the information, tools, pressures, and incentives in front of them at the time, and then ask what made the mistake likely. The person is almost never the root cause; they’re the last and most visible link in a chain of systemic conditions. Fix the chain and you prevent a class of incident; blame the link and you just make everyone better at hiding.

But “blameless” is widely misunderstood as “no accountability,” and that’s wrong too. A just culture draws a bright line between honest error — which you protect, learn from, and never punish — and dishonesty — evasion, blame-shifting, and above all concealment — which you cannot tolerate, precisely because the no-blame deal depends on everyone being honest.

Recommendation

Support people, run serious post-mortems, learn broadly — and hold the one hard line absolutely.

• Support the person who broke it. The first move when someone causes an incident is to back them, publicly. They almost certainly feel terrible; pile-on teaches everyone watching to hide next time. “You found a way our system lets a reasonable person cause an outage — thank you, let’s go fix that.”
• Give post-mortems ceremony. Treat the post-mortem as a serious, expected ritual with weight — a written narrative, a real meeting, a blameless facilitator, tracked follow-ups, and visibility. The ceremony signals that learning from failure is important work, not paperwork to close a ticket.
• Don’t just fix the thing — learn. The bug fix is the least of it. The valuable output is what the incident taught you, and the follow-ups that change the conditions, not just the symptom.
• Learn at every level, not only the software. Ask what made this likely about the organization (ownership, staffing, on-call load), the culture (were people afraid to push back? did pressure cause the shortcut?), the process (review, testing, rollout, change management), and the engineering practices — not just “what line was wrong.” The richest lessons are almost always above the code.
• Do it even as a team of one. Solo, there’s no one to blame and no audience — which is exactly why it’s tempting to skip. Don’t. Write the post-mortem to yourself, and interrogate your own process, habits, and decisions the same way. The discipline compounds.

The one hard line — accountability for dishonesty, not for error:

• Coach anyone who evades or blames. Deflecting responsibility or pointing at a colleague poisons the no-blame culture for everyone. Address it directly and firmly — it’s a behaviour to correct, and a repeated pattern is a serious problem.
• Hiding, altering, or destroying evidence is an immediate termination offense. This is the one place there is no leniency. Concealment doesn’t just cause one bad outcome — it destroys the trust the entire blameless system is built on, and makes every future incident un-learnable. Make this line explicit and known, so the protection of blamelessness is understood to be conditional on honesty.

Consequences

Easier:

• People tell you the truth about failures, so you actually learn how your system breaks and fix the conditions, not just the symptoms.
• Engineers take on risk and report problems early instead of hiding them until they explode.
• Incidents become the team’s best learning engine — across software, org, culture, and process — rather than a source of fear.

Harder:

• Blamelessness is constantly misread as “no consequences”; you have to actively teach the honest-error vs. dishonesty distinction, repeatedly.
• Real ceremony costs time and discipline — writing, meeting, facilitating, following up — and it’s tempting to let it decay into a checkbox.
• Holding the hard line means actually acting on evasion and concealment, including the hardest version (terminating someone who hid evidence), which takes resolve precisely when there’s pressure to let it slide.
• Learning above the code surfaces uncomfortable organizational and cultural truths that someone then has to own and act on.

References

• blameless post-mortemsJohn Allspaw — Blameless PostMortems and a Just CultureJohn Allspaw's case that effective post-mortems treat engineers as having acted reasonably given what they knew at the time, and focus on the systemic conditions that made an error likely rather than on punishing the individual — because blame drives the truth underground and you lose the chance to learn. A just culture balances learning with accountability.etsy.com ↗ — John Allspaw on blameless post-mortems and a just culture; the source reframe.
• ZFN-8 — the same psychological safety: people tell the whole truth only when it’s safe to.
• ZFN-4 — incidents are inevitable; this is how you learn from them instead of fearing them.
• Sidney Dekker, Just Culture; the Google SRE chapter on postmortem culture, as fuller treatments.

Changelog

• 2026-06-12: First published as a Field Note.