Postmortem: Forensics, Not Blame
Find the chain of causes. Investigate each failure like a review board, not a courtroom.
Why blame fails
A rough launch produces pressure to name a culprit quickly. It feels like accountability. It works against you.
Google's site reliability engineers put the reason plainly. Where finger-pointing prevails, people stop bringing issues to light for fear of punishment. Their rule: "You can't 'fix' people, but you can fix systems and processes" (Google, Site Reliability Engineering, ch. 15).
In week one, you need every problem reported the moment it is seen. Blame turns that flow off exactly when you depend on it.
Apollo 13 splashed down on April 17, 1970. NASA established a review board that same day. It did not ask who was at fault. It asked what happened, in what order, and why (NASA, 2020).
Seven weeks and four investigative panels later, the board had the chain of events.
In 1968, the oxygen tank assembly was dropped about two inches during a factory move. It was recorded and judged undamaged.
Weeks before launch, the tank would not drain normally. Engineers boiled the oxygen off using the tank's own heaters on 65-volt ground power.
The thermostat switches in that heater circuit were rated for 28 volts. They failed, and the heater ran far hotter than intended.
The temperature gauge could not read above 85 degrees, so nobody saw it. The heat damaged the insulation on nearby wiring.
In flight, a routine stir of the tank caused a short circuit across that wiring. The tank ruptured.
The board's conclusion was that the accident was not a chance malfunction. It was "an unusual combination of mistakes" joined to a design that left no margin for them (Report of Apollo 13 Review Board, 1970).
No single person caused it. No single fix would have prevented it. The result was a redesigned oxygen system and a three-month delay to the next mission, both aimed at the actual causes.
Why overreaction fails
The other failure is the oversized response. The conclusions arrive before the evidence does.
Reverting to the old system because of a defect that has a workaround.
Replacing people before anyone has established what happened.
Redesigning a process because of one bad transaction.
Adding approvals to every step because one step failed.
Each of these adds new change to a system that needs stability. Our rule in the field: no remedy larger than the evidence supports.
What forensic means
This is how we run it. It is field practice, informed by the two sources above.
Build the timeline first. What happened, when, in what sequence, from the records. Not from memory.
Classify before you conclude. Was it a software defect, a configuration choice, a data problem, an integration failure, a training gap, a process gap, or volume? Each has a different owner and a different fix.
Look for the chain. Serious failures rarely have one cause. Ask what had to be true for this to happen, and keep asking.
Separate three responses. Containment stops the damage today. Correction repairs what went wrong. Prevention keeps it from recurring. Different timelines, often different owners.
Write it down and share it. Findings that stay in a meeting room get relearned the hard way.
Blameless does not mean unaccountable. Owners are still named and dates are still kept. The difference is that accountability attaches to the fix, not to the fault.
References
Uri, John. "50 Years Ago: Apollo 13 Review Board Report." NASA History, June 15, 2020.
NASA. Report of Apollo 13 Review Board. Edgar M. Cortright, Chairman. June 15, 1970.
Lunney, John, and Sue Lueder. "Postmortem Culture: Learning from Failure." Chapter 15 in Site Reliability Engineering, O'Reilly Media.
Gartner. “How to Rightsize ERP Hypercare With Your Implementation Partner.” Research note by Miles McIvor and Matt Monopoli, July 14, 2026.
ERP for Private Equity. “ERP Post-Go-Live: 10 Best Practices for Success.” Blog post, n.d.
