Every team says their postmortems are blameless. Almost none of them are, not really, not when it counts. The policy holds fine for the garden-variety outage — a bad config push, a forgotten feature flag, a dependency that timed out under load. Nobody gets singled out because nobody important is watching closely enough to want a name. The test comes with the incident that actually costs money or makes the news. That's when "blameless" quietly becomes "blame-adjacent," and the team that wrote the careful, neutral timeline in April finds itself fielding pointed questions about who approved the deploy in October.
I don't think this happens because engineering leaders are hypocrites. I think it happens because blameless culture was never actually tested by the incidents people built it for. Most postmortem templates were designed around the routine failure, not the catastrophic one, and the two require fundamentally different levels of organizational discipline to stay honest.
The Policy Is Easy When the Stakes Are Low
A blameless postmortem is a low-cost commitment during a quiet quarter. The outage affected a handful of customers, the fix took twenty minutes, and the writeup gets filed and forgotten. Nobody above the engineering director reads it. In that environment, "focus on the system, not the person" is free advice that costs nothing to follow, because there's no pressure pushing in the other direction.
The pressure test is a different animal. A major outage brings in people who didn't build the system and don't speak its language — a VP, a board member, sometimes a customer who's threatening to leave. They want a name attached to the failure because names are legible in a way that "the deployment pipeline lacked a canary stage" is not. And once that pressure exists, it travels downward fast. The engineering manager who swore by blameless culture in the retro template starts asking, in a private Slack thread, who actually clicked deploy. The postmortem document stays neutral. The conversation around it doesn't.
Blameless Is an Organizational Property, Not a Document Format
The mistake teams make is treating blamelessness as a writing convention — passive voice, "the system allowed X" instead of "Alice did X" — rather than as a property of how the organization behaves under stress. A template can enforce careful language. It cannot enforce restraint from a frightened executive three levels up who wants an answer by end of day.
This is why I'm skeptical of postmortem culture that gets evaluated only by reading the document. The real test is what happens in the room before the document gets written, when someone first proposes a theory of what went wrong and somebody else has to decide whether to attach a name to it. If your organization can only stay blameless when the incident is small enough that nobody senior cares, you don't have a blameless culture. You have an unstressed one.
The honest version of this policy requires leadership to have already decided, before the big incident happens, that they will not ask "who" in the aftermath of a costly one — and to have practiced saying so out loud when the instinct to ask hits them hardest. That's a harder commitment than a template header, and it's the one that actually gets tested.
What a Real Commitment Looks Like
The teams that hold the line tend to share one habit: they separate the incident review from any conversation about individual performance, on a different calendar, with different attendees, explicitly decoupled in advance. Not because the two conversations shouldn't happen — sometimes a pattern of mistakes is a real signal about fit or training — but because running them in the same breath guarantees the postmortem becomes a trial with better manners.
The other tell is who's in the room when the big one happens. If the senior leader present during the hottest incident has already internalized that their job is to ask about the system and not the person, the blameless policy survives contact with pressure. If that leader is improvising their posture in real time, the policy was always decorative.
Worth watching: the next time your organization has a genuinely expensive incident — not the routine blip but the one that reaches a board deck — pay attention to whether the retro conversation and the performance conversation stay separate. That's the actual audit of whether blameless culture exists, and it's a test most teams don't realize they're taking until they've already failed it.