Blame is a mechanism, not a moral position. Asking who is responsible before you know what happened destroys the only material an organisation has to understand its own failure, because the people holding that material immediately start protecting themselves instead of describing what they saw. A serious failure never has a single cause: it has a chain of decisions, each defensible on its own, that nobody cut. The chain is the only object a leader can actually act on, and it becomes unreadable the moment a name is on the table.
Aviation separated investigation from judgment on purpose, and wrote it down
Air accident investigation is built on a rule that reads as generosity and is in fact a piece of engineering. The international framework governing these investigations sets a single objective for a safety investigation: prevention. It states that apportioning blame or liability is not the purpose of that activity. The French safety board says the same thing in its own words, describing its investigations as aimed solely at improving aviation safety, distinct from and without prejudice to any proceedings intended to establish faults or liabilities.
Two processes, two purposes, two sets of files. A court looks for someone responsible, which is a legitimate social need. An investigation looks for a cause, which is an operational need. They coexist, and they are kept apart.
The separation is not there to protect crews from consequences. It is there because the two objectives are technically incompatible in the same room at the same time. An investigator needs a pilot, a mechanic, a controller and a dispatcher to describe what they thought was happening, including the part where their reasoning was wrong. Nobody describes their own faulty reasoning to someone who can end their career with it. So the investigation is given a protected space, and the judicial process is given its own evidence to gather.
Companies do not have this luxury. In a company, the investigator and the judge are the same person, in the same office, often within the same hour. That is not a flaw to be fixed. It is the constraint to be managed, and almost nobody manages it explicitly.
An accident is a trajectory, not a decision
James Reason gave this shape a name in the British Medical Journal in 2000. His paper contrasts what he calls the person approach, which focuses on the unsafe acts of people at the sharp end and whose natural countermeasures are naming, blaming and shaming, with the system approach, which starts from the premise that humans are fallible and errors are to be expected even in the best organisations.
The image most people remember from his work is the layered one. An organisation is a series of defences. Each defence has holes. The holes are not fixed: they open and close with workload, staffing, deadlines, software versions, who happens to be on shift. An accident happens when the holes in every layer line up long enough for a trajectory to pass through all of them.
What matters in that model is not the picture. It is the consequence for anyone trying to learn from a failure.
If a failure requires alignment across several layers, then every single layer, taken alone, was working within its own definition of correct. That is why interviews after a serious incident produce the same sentence over and over: I did what I was asked to do. The sentence is not a defence. It is usually accurate. And it is exactly the sentence a blame-oriented process cannot process, so it gets treated as evasion.
Blame is expensive because it changes what people are willing to say
The cost of a blame reflex is never booked anywhere. It appears as an absence, and absences do not show up on dashboards.
Once responsibility has been assigned publicly one time, an organisation learns. What follows is not disengagement, which would at least be visible. It is defensive hygiene. People copy more colleagues on email. They ask for written confirmation of things that used to be settled standing up in a corridor. They timestamp. They write for the future reader who might be a lawyer rather than for the colleague who needs to act.
Each of those behaviours is individually rational. Together they add latency to every decision and remove the informal channel through which weak signals used to travel. The organisation becomes slower and blinder at the same time, and it experiences this as a process problem rather than as a consequence of how it handled one incident eighteen months earlier.
There is a second-order cost that is harder to talk about and easier to observe. The people who leave first, in an organisation that has learned to assign blame, are not the weakest ones. They are the ones with the clearest read on where the next incident is going to come from, because they are the ones for whom staying quiet is the most expensive thing psychologically. What remains is a team that is technically competent and structurally silent, and a leadership team that has no idea it is now flying on instruments that report only good news.
Sidney Dekker has spent a career on this trade-off. The argument in Just Culture: Balancing Safety and Accountability is not that nobody should ever be held to account. It is that accountability and learning pull in different directions, that the pull is real, and that most organisations resolve it implicitly, by reflex, without ever noticing they made a choice. In The Field Guide to Understanding Human Error, the same point is turned toward practice: human error is not an explanation, it is the thing that still needs explaining.
A data migration that lost fourteen months of history, reconstructed as a chain
Here is a failure I have seen in enough variations to treat it as a type rather than an anecdote. The details below are reconstructed and anonymised. No organisation is identifiable, and the point is the structure, not the story.
A company consolidates two customer databases after an internal reorganisation. The two systems came from two business units that used to operate separately. The consolidation is not a technical vanity project: a regulatory reporting obligation requires a single view of the customer base by a specific date, and that date is not negotiable.
Decision one. The executive committee approves the consolidation and fixes the go-live to land before the reporting date, with a small buffer. That is the correct call. The date is externally imposed. A leadership team that lets an internal migration slip past a regulatory deadline has failed at its actual job.
Decision two. During schema work, an engineer finds that roughly two per cent of records from the older system carry a legacy identifier format that the new schema cannot represent. These are the oldest customers, the ones with the longest history. He does exactly what he should: he documents it, quantifies it, and proposes a mapping table with an estimate of three weeks.
Decision three. The programme manager holds the deadline. Three weeks eats the buffer. She asks a reasonable question: can those records be migrated in a second pass, after go-live? The answer is yes, technically nothing prevents it. She decides on a second pass and records the decision. Given her mandate and the information she has, this is not a compromise. It is good programme management. The regulatory report does not depend on the two per cent.
Decision four. The second pass is entered in the project tracker as a follow-up task with an owner. Two months later, that owner moves to another role in a reorganisation that has nothing to do with this project. The task was in the tracker, not in anyone’s objectives, not in a service catalogue, not in a risk register. The project closes on time. Its tracker is archived, which is standard practice for a closed project and which any auditor would approve of.
Decision five. Post-go-live validation compares record counts between the old and the new system. The counts match. They match because the two per cent were written to a quarantine table during migration, and the reconciliation query counts every row present in the target environment. Nobody wrote that query in bad faith. It was written before the quarantine table existed as a concept, and counting everything that arrived is the intuitive definition of a successful migration.
Fourteen months later, a commercial dispute with one of those long-standing customers requires the transaction history that predates the reorganisation. It is not there. The quarantine table was dropped during a storage clean-up, executed under a documented retention rule, by someone who had no reason to grant it an exemption because nothing anywhere described it as holding production data.
Five decision points. Not one of them was wrong when it was taken. Five people could have cut the chain, and each of them was doing the thing their role rewards.
Now watch what the blame reflex produces here. It produces the engineer. He is the only person in the sequence who saw the problem, named it, and then let it go. That reading is satisfying, and it is the single most expensive conclusion available, because it teaches every engineer in the company that flagging a two per cent anomaly attaches your name to whatever happens next. The next anomaly will not be flagged. It will be worked around quietly, and the workaround will be undocumented, because documenting a workaround is documenting that you knew.
The chain reading produces something different. It produces five cut points, each with an answer that outlives the people involved. A deferred migration item does not survive in a project tracker, so deferred work with a data consequence needs a home that is not a tracker. A validation query that counts rows in the target environment answers the wrong question, so reconciliation has to compare against a business definition of the record, not against a row count. A retention rule applied to a table nobody classified will delete production data eventually, so classification is a precondition of retention, not a nice-to-have. A follow-up task with an owner and no objective is a task with no owner. And a project cannot close while it still holds an open data commitment, which is a governance rule, not an engineering one.
None of that is discoverable from a name. All of it is discoverable from a sequence.
High reliability organisations treat failure as data, not as misconduct
Karl Weick and Kathleen Sutcliffe studied organisations that operate in conditions where failure is catastrophic and yet failure is rare. In Managing the Unexpected: Sustained Performance in a Complex World, the pattern they describe is not heroic vigilance. It is a set of habits, and two of them are directly relevant to any company.
The first is preoccupation with failure, meaning that small anomalies are treated as information about the system rather than as noise to be filtered. The second is reluctance to simplify, meaning that convenient single-factor explanations are actively distrusted, because a simple explanation of a complex event is almost always a truncated one.
A single named culprit is the most convenient simplification available. It is also the one that ends inquiry fastest, which is precisely why it feels like resolution.
The software reliability world arrived at the same place from a different direction and gave it a name. The postmortem chapter in Google’s Site Reliability Engineering describes a blameless postmortem as one that identifies contributing causes without indicting any individual or team, and it states the working assumption plainly: everyone involved had good intentions and did the right thing with the information they had. The operational logic in that chapter is worth quoting in substance rather than in form, because it is the whole argument compressed: you cannot fix people, but you can fix the systems and processes that support people in making the right choices.
A blameless post-mortem is a discipline, not a mood
The most common failure mode of this idea is to treat it as a tone of voice. A meeting where everyone is polite and nobody says anything useful is not a blameless post-mortem. It is a blame-avoidant meeting, which is the same information loss with better manners.
The discipline has a few hard edges.
It starts with an assumption stated out loud before anything else: every person in this sequence acted correctly given what they knew at that moment. That assumption is not up for debate during the session. It is the axiom that makes the rest possible. What remains to be examined is far more interesting anyway: why did the available information lead to that decision.
It produces a dated sequence, not a narrative. Times, decisions, who knew what, what was written down and where. The output is a chain, with the cut points marked.
It separates the question of consequence in time. A leader who needs to sanction someone retains that right. Doing it during the reconstruction destroys the reconstruction. Doing it after means the decision is made by someone who now understands what happened, which tends to change the decision.
It also has a guest list, and the guest list is where most attempts die. A reconstruction attended by the person who signs the budget of everyone in the room is not a reconstruction. It does not matter how sincere that person is about wanting the truth: the people in the room are doing arithmetic about their own exposure, and they are right to. Either the sponsor stays out and receives the written sequence afterwards, or the sponsor comes in and accepts that what they will hear is the version that survives being heard by them. Both are workable. Pretending the choice does not exist is not.
And it is governed. A post-mortem practice that depends on the goodwill of whoever runs the meeting lasts exactly as long as that person. It needs a trigger threshold, a named owner of the practice rather than of the incident, a standard output format, and a rule about who reads it. Without those four things it will be applied to the incident that is politically safe and skipped on the one that matters.
What changes when a leader stops asking who
The habit is in the phrasing, and the phrasing is contagious. A leader who opens with who validated this has already told the room which process is running. A leader who opens with walk me through the sequence has told them something else, and the room adjusts within minutes. That is not a soft-skills observation. It is the highest-leverage change available, and it costs nothing.
What comes back is different in kind. Not a defence, a chain. And a chain has an uncomfortable property: it always passes through governance. The deferred item with no home, the validation that answered the wrong question, the ownership that evaporated in a reorganisation, the closed project with an open commitment. None of those belong to the engineer. They belong to whoever designed the system in which those things are normal.
Which is the real reason the question who is so attractive. It ends outside the leader. The chain does not.
A failure that produces a name teaches an organisation to hide. A failure that produces a sequence teaches it something it can use. Both are choices, and one of them is made every time by default, in the first twenty minutes, by whoever speaks first.
Sources
- James Reason, Human error: models and management, BMJ, 2000, 320:768-770. https://www.bmj.com/content/320/7237/768
- SKYbrary, Introduction to Accident Investigation (citing the sole objective of a safety investigation under ICAO Annex 13). https://skybrary.aero/articles/introduction-accident-investigation
- Sidney Dekker, Just Culture: Balancing Safety and Accountability, 2nd edition, CRC Press, 2016. https://www.taylorfrancis.com/books/mono/10.4324/9781315251271/culture-sidney-dekker
- Sidney Dekker, The Field Guide to Understanding Human Error, CRC Press, 2017. https://www.taylorfrancis.com/books/mono/10.1201/9781315239675/field-guide-understanding-human-error-sidney-dekker
- Karl E. Weick and Kathleen M. Sutcliffe, Managing the Unexpected: Sustained Performance in a Complex World, 3rd edition, Wiley, 2015. https://pure.johnshopkins.edu/en/publications/managing-the-unexpected-sustained-performance-in-a-complex-world-/
- John Lunney and Sue Lueder, Postmortem Culture: Learning from Failure, chapter 15 of Site Reliability Engineering, O’Reilly. https://sre.google/sre-book/postmortem-culture/
- BEA (Bureau d’Enquêtes et d’Analyses), Our mission. https://bea.aero/en/the-bea/our-mission/
FAQ
Why does aviation separate accident investigation from legal liability?
Because the two objectives are technically incompatible in the same room at the same time. An investigator needs a pilot, mechanic, or controller to honestly describe their own faulty reasoning, which nobody will do in front of someone who can end their career with that admission. International rules explicitly state that the sole objective of a safety investigation is prevention, not apportioning blame, and keep it as a separate process with separate files from any judicial proceeding.
What is a blameless post-mortem, and how is it different from just being polite about a failure?
A blameless post-mortem starts from a stated axiom — everyone in the sequence acted correctly given what they knew at the time — and produces a dated, factual sequence of decisions rather than a narrative or a defense. It is a discipline with hard edges: it needs a strict guest list (a sponsor who can sanction someone changes what people are willing to say), a separation in time between reconstruction and consequence, and a governed process with a named owner — not just a meeting where everyone is careful with their words, which is blame-avoidance wearing the same disguise.
