Why Organizations Keep Repeating the Same Outage: Punishment Is a Tax on Information
It is three in the morning, an alert fires, and the payments API has been returning errors for thirty minutes straight. The on-call engineer rolls back, the service recovers, everyone goes back to sleep. The next morning, a manager asks one question, and that single question decides what kind of organization this is. Teams that open with “who deployed this” end up with a very different incident history six months later than teams that open with “why didn’t our pipeline stop this deploy.” This piece is about why that fork in the road exists, and which side actually prevents the same outage from happening twice.
The short version is this. Organizations that repeat incidents are not staffed by careless people. They repeat incidents because punishment cuts off the flow of information that would have prevented the repeat. Blameless culture is not a matter of being nice, and it is not a values statement you hang on a wall. It is an information system design problem: can this organization extract the truth from its own failures, or not. Once you accept that framing, every practical question, how to run the meeting, how to write the document, how to manage the follow-up work, resolves into a single principle. Design the system so that honest disclosure never costs the person disclosing it.
A visual metaphor for the article’s key idea.
Punishment Is a Tax on Information
When an incident happens, the single most valuable resource in the room is not headcount or budget. It is information: what actually happened, which signal got missed, and why a particular decision made sense at the particular moment it was made. Most of that information exists in exactly one place, the head of the person who was there. Logs and dashboards can tell you what the system did. They almost never tell you why a human decided to do what they did. The only channel for that second kind of information is a person choosing, voluntarily, to say it out loud.
Punishment closes that channel. If an engineer knows that a detailed, honest account of their own mistake leads to a bad outcome, whether that is a formal writeup, a promotion ding, or public embarrassment in front of peers, the rational move is to minimize the report, shade the facts favorably, or leave the inconvenient part out entirely. This is not a character flaw. It is a reasonable response to a bad incentive, and very few people fail to run that calculation.
That is why postmortem documents from punishment-heavy organizations tend to share a recognizable shape. The root cause analysis stops at a strangely shallow layer. The document says the engineer skipped a verification step, and stops there, without asking why that verification step depended on one person’s memory in the first place. Asking that second question would surface a system design failure, and system design is usually a team-level or leadership-level decision. Naming one individual is simply the most comfortable place for the investigation to end.
This is sometimes described as an information asymmetry problem: the person closest to the incident knows most of the real cause, but fear of consequences keeps them from disclosing all of it. The investigator has to draw a conclusion from half the picture, and that conclusion inevitably lands on a surface-level cause. A postmortem that never reaches the actual root cause leaves behind exactly the conditions for the same failure to recur in a slightly different shape.
Infographic generated by NotebookLM from the sources.
Why Silence Compounds
The damage from punishment does not stop at the incident where it happened. An engineer who was punished, or publicly criticized, once will hesitate the next time they notice something odd. There is an automatic calculation running in the background: this might be nothing, and if I raise it and I am wrong, does the last time happen again. That hesitation does not stay contained to one person, either. Colleagues who watched it happen learn the same lesson by observation. The organization’s early-warning sensitivity degrades quietly, but it degrades in every direction at once.
The dangerous part is that this degradation is invisible in the short term. Visible incidents do not necessarily go up right away, and things often look quieter than before. That quiet is frequently not evidence of health, it is evidence that small signals are no longer reported and are simply piling up unseen: recurring timeouts that never get filed, latency creep that gets shrugged off, failures that retry logic silently absorbs without anyone noticing the retry rate climbing.
What makes this compounding effect genuinely dangerous is that, over time, the organization knows less and less about the actual state of its own system. A gap opens up between what the dashboard shows and what the engineers on the ground actually feel in their gut. Eventually that gap crosses a threshold and shows up as one large, sudden incident. In the postmortem for that incident, someone inevitably says “we saw that signal before.” What gets forgotten is that the culture never gave anyone a safe way to say it out loud at the time.
Breaking this cycle is conceptually simple: lower the cost of honest disclosure. The next two sections argue that the lever for doing this is not a values poster or a culture campaign. It is the concrete mechanics of how the meeting opens and how the document gets written.
Separating Fact From Judgment: The Timeline as an Information Pipeline
Teams writing their first postmortem tend to fall into one of two failure modes. The first is too short: “the server crashed, we restarted it, done.” That sentence provides zero help the next time something similar happens. The second is too long: the entire log dump pasted in, several pages of background context nobody asked for, and nobody reads it past the second paragraph. A good postmortem sits in the middle. A reader should be able to understand what happened in five minutes, and dig deeper only if they choose to.
The backbone of that middle ground is the timeline, and the core discipline of a good timeline is keeping fact and judgment strictly separated. “At 14:02, the deploy pipeline pushed a new version to production” is a fact. “At 14:02, the engineer carelessly deployed” is a judgment. The moment those two get mixed together, a reader is no longer reading a timeline, they are being handed a conclusion, and they either accept it uncritically or read the rest of the document defensively. Neither outcome supports learning.
Why a purely factual timeline matters becomes obvious once you ask who the document is actually for. A postmortem is not written for the people who were in the room. It is written for the future teammate who was not. A timeline loaded with judgment forces that future reader to inherit the original author’s framing. A timeline that sticks to facts leaves room for the reader to form their own conclusion, and in practice that room is frequently where a genuinely different, more useful insight comes from.
Recording attempts that did not work is part of the same discipline. “The team tried a hotfix before a rollback, it did not resolve the issue, and the team switched to rollback ten minutes later” preserves the possibility that the hotfix attempt, even though it turned out wrong in hindsight, was a reasonable call given the information available at that moment. Without that line, the next engineer either repeats the same failed attempt from scratch or quietly concludes that whoever made the earlier call was incompetent. Neither outcome helps the organization.
At bottom, timeline discipline is not a writing-style preference. It is a pipeline design problem: how do you move information from one person’s head to the next person’s head without introducing noise along the way. The instant fact and judgment get mixed, noise enters that pipeline, and noisy information degrades every decision built on top of it later.
Culture Is Not a Policy, It Is the First Three Minutes of the Meeting
Writing “we are a blameless team” on an internal wiki page does not create that culture. Culture is the accumulation of repeated behavior, not a declaration, and the single strongest signal in that accumulation happens in the first three minutes of a postmortem meeting. Whoever holds the most senior title in the room usually decides what those three minutes look like.
If a leader opens with arms crossed and “so, who deployed this,” every blameless principle written in the runbook is now irrelevant. That one sentence puts everyone in the room into defensive posture, and every statement made from that point forward is self-protection, not honest reporting. An effective leader opens differently: “thank you to everyone who responded, and to be clear, the point of this meeting is to understand what let this through our system, not to point at anyone.” It sounds obvious written down. Very few leaders actually say it, out loud, every single time.
The repetition matters because hearing a principle once does not internalize it across a team. New hires and people who came from organizations with a genuine blame culture need to hear it repeated at the start of every meeting, not once in an onboarding doc. For them, silence is the safe default, and breaking that default requires the leader to resend the safety signal fresh, every time, because trust built in one meeting does not automatically transfer to the next.
A leader modeling their own vulnerability first is an equally strong signal. “I caused an outage from a very similar mistake a few years ago, and here is what I learned” makes it noticeably easier for the rest of the team to admit their own mistakes. In an organization where the leader has never once admitted a mistake, admitting one becomes an act of exposing weakness rather than an act of contributing information. The leader’s own behavior sets the actual safety baseline the whole team learns from, regardless of what the wiki page says.
Why Good Intentions Die in the Backlog
Even a postmortem meeting that runs in exactly the right tone and correctly identifies the root cause is a waste of time if the action items it produces never get done. Worse than a waste of time, actually. The next time an incident happens and someone says “didn’t we say we’d fix this last time,” the postmortem process itself loses credibility. People stop showing up with real energy, and a quiet cynicism sets in that honest disclosure changes nothing anyway.
A few patterns recur behind action items that never ship. The most common is an item written too abstractly: “improve the deploy process” tells the owner nothing about where to start, so it gets pushed behind whatever is on fire that week, indefinitely. The second is an unclear owner. “The team will review this” assigns responsibility to everyone, which in practice means no one treats it as their job. The third is the absence of any priority. Ten action items dumped into the backlog at equal priority means the infrastructure-shaped ones, the ones that never produce a visible feature for a user, quietly lose to regular roadmap work every single sprint.
The table below shows how the same underlying concern gets written down differently in a document whose action items actually close versus one whose action items quietly die.
| Attribute | Action Item That Never Ships | Action Item That Ships |
|---|---|---|
| Owner | Assigned to a team, or unassigned | One named person, explicitly the final accountable owner |
| Done criteria | Vague description, not measurable | Verifiable, e.g. “CI blocks any deploy that bypasses this gate” |
| Priority | Same priority as everything else, sits in the backlog | Ranked by severity, with a deadline attached |
What that table really says is one thing. Good intentions evaporate unless they are wrapped in concrete structure. An action item needs to be written in a form that can execute itself weeks later, at the point when nobody in the room remembers the emotional weight of the original meeting anymore.
Designing the Organization as an Information System
The four ideas covered so far, the mechanics of information asymmetry, how silence compounds, the discipline of separating fact from judgment in a timeline, and the structure of a shippable action item, are not four separate stories. They are one story viewed from four angles. An organization’s ability to learn from its own failures is not a question of moral maturity. It is a question of whether a system exists that makes honest disclosure cost the discloser nothing.
That framing has a concrete implication for anyone rolling out a postmortem process. Do not start with a culture campaign. Start by checking three structural things: what sentence the meeting facilitator actually opens with, every single time; whether the document template structurally forces facts and judgments apart instead of leaving that to the author’s discretion; and whether action items are required by default to have an owner, a measurable done condition, and a priority. Get those three things right and honest disclosure increases on its own, without the word “blameless” ever needing to be said out loud. Declare blameless culture without those three things in place, and the declaration is a thin promise that collapses the moment the next person gets punished for telling the truth.
In the end, the difference between an organization that turns its incidents into an asset and one that keeps repeating them is not a difference in character. It is a difference in design. Punishment kills information, and an organization that loses information knows less and less about its own system over time. A system where honest disclosure is safe gets measurably sturdier with every incident it survives. The organizations that build that design first are the ones that, eventually, fall less often, and fall more gently when they do.
Infographic generated by NotebookLM from the sources.
References
- The starting point of this piece: a blame culture suppresses honest reporting, and what you fix is the system, not the person. Google SRE Book, “Postmortem Culture: Learning from Failure”. https://sre.google/sre-book/postmortem-culture/
- Evidence that action items need an explicit owner and a verifiable end state, and that vague verbs like “improve” never ship. Google SRE Workbook, “Postmortem Culture”. https://sre.google/workbook/postmortem-culture/
- A worked example of a timeline that records only times and events, with causal interpretation kept in a separate section. Google SRE Book, “Example Postmortem”. https://sre.google/sre-book/example-postmortem/