After a failure, a leader runs a review that looks for causes in systems and decisions, with no hunt for a culprit, so people report what happened and the fix that follows has real support.
An example
Six hours of downtime on the last business day of the month left four hundred client firms of a payroll software company unable to run payroll. The head of platform engineering expected the chief executive to ask who was responsible; she asked him to run the review instead. He set one rule at the start: the review would find out what happened and why, and no one would be disciplined for anything they reported. Over two days the engineers involved laid out the timeline. A database migration had been approved in a change meeting that never saw the month-end load forecast. The on-call engineer had spotted the problem early but had no authority to roll back without a director's approval, and the director was on a plane. The fix had three parts: month-end change freezes, load forecasts in change reviews, and rollback authority for on-call engineers. The leadership team approved all three that week.
Why it works
When people expect blame, they report as little as they can, and the review finds a culprit while the cause stays put. When they expect to be heard, they say what they saw and did, and the review finds the conditions that made the failure likely: a process gap, a missing piece of information, authority in the wrong place. The fix rests on an accurate account, so it looks better and draws real support. Most failures are not anyone's fault in the sense blame implies. It all depends on the leader keeping the no-blame promise.
The thinking behind it
Amy C. Edmondson Strategies for Learning from Failure (2011) sets out a spectrum of reasons for failure, from blameworthy ones such as deliberate deviance and inattention to praiseworthy ones such as uncertainty and experimentation. Edmondson argues that most failures are not blameworthy, so organizations learn only if people feel safe to report and analyze them. The no-discipline rule is what made the on-call engineer's account possible, and the spectrum is why the rule can still exclude deliberate misconduct.
When it fits
Significant failures whose causes are unclear, where the people involved know things the leader does not, call for it: outages, product failures, missed launches, operational incidents. It requires the authority to promise no discipline for honest reporting, and the willingness to keep that promise when the review points at a decision you or a peer made.
How to use it well
Set the rule before the review starts: the aim is to learn what happened, and no one will be punished for what they report.
- Build the timeline with the people involved, step by step, asking what they knew and why each choice made sense at the time.
- Look for causes in systems, process, information, and authority.
- Write it up plainly, including the decisions made by senior people.
- Turn the findings into specific fixes with owners and dates.
The rule covers honest mistakes. Deliberate misconduct or repeated negligence still has consequences, and saying so at the start tells people where the line is.
What it costs and where it backfires
Some will see a blameless review as soft, especially after a costly failure, and pressure to name someone can come from above. The findings may implicate senior decisions, including yours, and a review that names no one may frustrate the people who were hurt by the failure. A genuine search for causes is the point. Once the review shields someone from accountability for deliberate misconduct, or someone is punished afterward despite the promise, the next review will learn nothing.
When it is used on you
Watching a review after a failure head toward a culprit, ask for the timeline and the conditions first: what each person knew, and what the process allowed. If you were involved, give your account in writing and accurately. If a review is billed as blameless and you suspect it is shielding someone, ask what the rule covers.