Scapegoat, Justice, Inquiry: How Your Culture Deals With Failure

Published August 25, 2026

Part 1 of The Generative Culture Series

Something breaks. A deploy takes a service down, a decision costs the account, a project ships six weeks late. Long before anyone has fully diagnosed what happened, a harder question has already been decided: what does accountability actually mean here?

In a lot of organizations, accountability is just a nicer word for punishment — one throat to choke, someone to point at so everyone else can exhale. I want it to mean something else: our responsibility to the system, our customers, and each other, to close the gap.

Sidney Dekker, whose writing on safety and accountability has shaped a generation of operations thinking, draws the same line in Just Culture. Treat a failure as a crime, he writes, and accountability becomes “backward-looking, retributive.” Treat it instead as “an indication of an organizational, operational, technical, educational or political issue,” and accountability “can become forward-looking” — aimed at the opportunities to make the failure less likely next time. Finding someone to blame for this one stops being the point.

Ron Westrum was a sociologist who studied how organizations process information. In 2004, he laid out three organizational cultures in a paper for Quality and Safety in Health Care. The material came from hospitals, aviation, and cases like NASA. The DevOps research community later picked it up as one of its core culture measures. Here is Westrum's own description of what each culture does when something goes wrong: “pathological climates encourage finding a scapegoat, bureaucratic organisations seek justice, and the generative organisation tries to discover the basic problems with the system.” Scapegoat, justice, inquiry.

Scapegoat

When something breaks in a pathological culture, the work goes to whichever specialist or hero fixes it without asking for help or explaining how. The real energy goes toward the messenger: who should be blamed for this, who caused this. People spend the incident protecting themselves, and the problem waits — here's the part that should bother a leader more than anything else: sometimes it doesn't get fixed at all while the finger-pointing is happening. The outage stays open. The mistake keeps recurring. The fix stops getting tracked; what gets tracked is who takes the fall, who becomes the one throat to choke. There's almost always someone saying “I told you so,” quietly, because saying it out loud is its own way of getting in trouble.

The leaders running cultures like this are optimizing for something other than the fix. What matters is their position and power, and even more, the appearance of having both, confident and in control, right up until someone challenges it. Underneath, there's usually a sacrificial lamb: someone fired, demoted, or publicly humiliated, so the organization can perform having handled it. Everyone else absorbs the lesson without anyone stating it out loud: cover your tracks before you fix anything.

Justice

This is the closest description of most organizations most people have actually worked in. When something breaks, the process kicks in: playbooks, escalation guidelines, policy. Cooperation is real but modest — siloed, mostly reach-outs, rarely people fully working together. You're responsible for the firewall, someone else is responsible for storage. Ownership stays narrow, task by task. If someone crosses a boundary to help, it's tolerated as long as it's temporary: useful in this case, but as soon as we're done, get back to your team.

That tolerance has a shelf life, and the moment it runs out is one of the more telling scenes in a bureaucratic culture. Someone pulls in a colleague from another team, or reaches outside the org chart to someone who actually knows the system, and together they solve the problem. The debrief afterward centers on the reach-out: segregation of duties, someone says, a rule invoked more often than it's understood, applied here in a way that has nothing to do with what it was actually written to prevent. The problem got solved. That part goes unmentioned. What lingers is the verdict that the wrong people worked on it together. The organization needed to see people following the rules it has, so the conversation becomes a referendum on whether they did.

If you've ever said “segregation of duties” about a fix that already worked — or heard yourself think it and stayed quiet — that was you, in the room, choosing the rule over the result.

Bureaucratic failure response spends its time asking who let this happen. Why did the system let this happen stays a question nobody in the room gets around to. It produces a kind of justice — someone gets punished or reprimanded, a policy audit runs. Almost always, the actual output is a new layer of red tape too: another rule, another playbook, a mandatory sign-off. That's genuinely less brutal than the pathological version. It's also not much comfort if you're the one receiving it. Reprimanded is reprimanded.

The bureaucratic leader deserves the most sympathetic read of the three. They focus on the rulebook because the rulebook is what protects them: whether procedures were followed, whether their department survives an audit. Following the defined playbook may not get them the outcome they actually wanted. But nobody gets in trouble for it, most of the time — and that's the whole calculation. It's a rational response to an organization that rewards not-getting-in-trouble over getting-it-right; the incentive works exactly as designed.

Inquiry

In a generative culture, when something breaks, everybody swarms it together. Whoever finds the problem, the messenger, might end up running point on fixing it; people are trained to surface problems and get them in front of someone, fast. Shared risk gets treated as shared: the storage, the firewall, the certificate, whoever notices takes ownership of raising it, and information moves freely — no hoarding it along department lines. The output is a blameless postmortem, or five whys, or some other structured inquiry into what happened and how the system allowed it, followed by real appetite for the fix, including fixes that touch how the organization itself is built.

The generative leader looks almost like a peer. Genuinely part of the team, interested in what's going on, more invested in delegating and handing people ownership of their own situation than in commanding a response from the front. Root cause matters more than blame, and everyone contributing to finding it matters more than any one person being right about it.

Walking into a blameless postmortem for the first time can be uncomfortable; people are a little nervous if they haven't done it before, especially if they came up in a different kind of culture. What follows is usually an hour or two of five whys: why was this able to happen, what allowed the system to let this happen. No finger-pointing. Just the chain, followed as far as it goes. One version of it runs like this:

“This didn't get done on time.” Why? “This wasn't approved.” Why? “It needed a dependency on another group.” Why? “That's what the rules say.” Why? Nobody knows.

That's the moment someone senior in the room, a director or whoever has standing to ask it, can push one step further: why does the rule exist at all. Sometimes nobody can answer because there's no answer left; the rule solved a problem that stopped existing years ago and survived out of habit. Kill that one. Sometimes nobody can answer for a plainer reason: the person who could isn't in the room — compliance, say, or whoever owns the regulatory relationship, or whoever inherited the requirement from a regulator nobody on this call has ever spoken to. In a bank, an insurer, a hospital, the rule the chain just ran into is as likely to be SOX, model-risk governance, or a regulator's requirement as it is dead weight, and killing it because the incident call couldn't defend it on the spot is how a five-whys exercise turns into a market-conduct exam. The instruction survives the distinction: find out which rule you're looking at before you touch it.

A generative inquiry that starts with one missed deadline can end up dismantling a piece of bureaucracy nobody could defend, or routing the right question to the one person who could have answered it in the first place. Scapegoat, justice, and inquiry describe three states the same organization moves through, sometimes inside a single conversation.

The part that actually surprises people is what happens to ownership once blame is off the table. People volunteer more of it than you'd expect: I didn't do this well, I could have done this better, said before anyone asks, because nobody in the room is hunting for someone to pin it on.

None of this means nobody is ever accountable in the way people actually fear. Dekker draws that line himself: honest error is the system's to own — the mistake anyone on that team could plausibly have made, given the training, the tooling, and the time pressure they were handed. Recklessness is not the system's to own, and neither is the same failure showing up a third time from someone who has had real support to close it and hasn't. Dekker's later work is blunter about where that line actually falls: “the critical question is not where to draw the line, but who gets to draw it” — culpability, he writes, is socially constructed, which is a harder thing to sit with than a clean rule, but a more honest one. Inquiry culture asks the system-allowed question first. It doesn't ask it forever, for everyone, regardless of what they do with the answer.

Why this should survive a skeptic's questions

I know how “blameless” sounds to a room of technology leaders who've heard the word before and watched it not stick. That skepticism is earned.

Westrum himself hedges on his own typology: in his paper, he admits “systematic tests of the hypothesis are harder to find” than the case studies suggest, and that some studies looking for a relationship between culture and outcomes “fail to show it.” Google's SRE handbook calls blameless postmortems “a tenet of SRE culture,” but the chapter that says so doesn't offer data to back the claim. It describes how one credible engineering organization runs its own practice. Whether the practice improves reliability anywhere else it's tried is a separate question the chapter doesn't answer.

A 2023 study in Organizational Behavior and Human Decision Processes is the sharpest challenge here: across several work settings, psychological safety's relationship to performance wasn't a straight line. Moderate levels helped; the very highest levels correlated with performance going down. Other researchers have pushed back hard on the finding, and their strongest argument is a definitional one worth taking seriously: what gets measured at those extremes may no longer be psychological safety in Edmondson's sense at all. Feeling safe enough to admit a mistake and feeling safe no matter what you do are different things — the second one is closer to consequence-free comfort, and comfort like that would drag performance down for reasons that have nothing to do with whether people tell the truth about failures. It's a real finding. It applies at the far edge of the scale, in conditions most teams never get near.

Amy Edmondson's 1996 study tracked medication-error rates across nursing units at two hospitals over several months and found that the better-managed units, the ones rated highest on teamwork by their own staff, reported higher error rates than the worst-rated ones. Discussing a mistake had simply stopped being dangerous enough to bury. Westrum cites the same study in his own paper and adds a caveat worth keeping: the exact size of the gap between the best and worst units is, in his words, “suggestive, not definitive.” Treat the direction as solid and the precise number as a detail nobody should build an argument on.

Any one of these, alone, is weak. Widespread adoption by credible engineering organizations just shows a practice is popular. A single study, even a well-designed one, is one study. Add them up, though. Organizations keep choosing this practice. The psychological-safety research explains why people report near-misses honestly, and Edmondson's own study found they do. Google ran its own version of the same question internally: a multi-year effort nicknamed Project Aristotle, looking at what separated its best teams from the rest, found psychological safety mattered more than who was actually on the team. Different kinds of evidence, gathered different ways, land in the same place. That's short of a controlled experiment, but it's a real convergence — a stronger case than any single piece of it makes alone.

What holds, repeatedly, inside teams that actually run this way: the moment the question shifts from who let this happen to why did the system let this happen, people start telling the truth about what happened. The truth has stopped being dangerous to say out loud.

Before you run anything, it's worth a minute of honesty about which of these three you actually work inside. Your last incident is a more honest judge of that than your handbook is. Did the debrief spend more time on who than on why? Did anyone get quietly punished for something the system made nearly inevitable? Did a rule get invoked that nobody in the room could actually explain? Did the person who found the problem end up running point on the fix, or did they end up explaining themselves? Four honest answers usually tell you more than a framework does.

The one thing to do

If you only run one thing with your own team, run the blameless postmortem. It's the practice worth starting with, full stop. The full shift touches how you structure teams, what you measure, how you treat new ideas, and what changes inside you as a leader before any of that sticks; this is the smallest piece of it, and the one you can run this week without asking anyone above you.

The mechanics aren't exotic. After the incident is actually resolved, gather the people who were really involved, not just the people who'll be asked about it later. Reconstruct what happened, as factually as you can get it, before anyone assigns meaning to it. Ask what the system allowed, out loud, in the room, and mean it, especially toward whoever is most nervous about being there. Write it up and share it, including the mistakes, especially the mistakes, because a postmortem nobody else reads teaches nobody else anything. Do this even when, especially when, the instinct in the room is to quietly close the incident and move on.

None of this requires you to run the whole organization, just the next incident conversation, differently than the org around you would otherwise expect. How you handle a failure you own, and whether you actually learn from it, is one of the more honest signals available about your leadership.

The accountability reframe I opened with is really a question about what you owe the people around you when something goes wrong. Dekker's own thinking moved further on this over time, toward what he calls restorative justice, built on who was hurt and what they need, and whose job it is to make sure they get it. None of that has room for a scapegoat, and none of it lets a reckless or repeated failure hide behind “the system did it.” It just asks you to find out which one you're looking at, and answer for it either way. The rest of how you lead through failure follows from that.

Back to Field Notes