"I don't want the details": the postmortem question that actually drives change

In an essay published on 23 September, engineer Michael Heap described a call he was pulled into with his engineering counterpart and their boss, an SVP of engineering. Something had gone wrong — nothing catastrophic, but serious enough to reach an SVP. Heap started explaining how it had happened and was cut off: "Michael, I don't want the details." The reasoning: if we get into the details, every explanation will be perfectly reasonable, every decision will make sense, and I will empathise with you — "Then it'll happen again. So I don't want the details. I want to know what we're changing."

The wrong question

After something goes wrong, most organisations ask "why did this happen?" Teams write timelines, reconstruct decisions and hand over a document describing exactly what happened. Everyone nods, agrees that it makes sense, and moves on. Heap's objection is simple: understanding an issue is not the same as fixing it. A good explanation can make things worse — once everyone agrees the behaviour was reasonable, the urgency to change disappears, and the same failure returns six months later.

Reasonable people, systems that need changing

Heap suggests a different question instead: "What are we changing so that the same class of failure is less likely next time?" The executive was not interested in who did what, or in being told that everyone had behaved reasonably — that is a baseline expectation. Three examples from the essay: a failure was missed because Alice was on holiday and Bob assumed the Widgets team owned it — so how do we make ownership unambiguous when someone is unavailable? The requirements changed three days before launch — so what happens when requirements change inside the launch window? An alert fired, but the on-call engineer had already dealt with twenty low-value alerts that evening — so how do we improve the signal-to-noise ratio of our alerts? In each case the fix is systemic; the people are usually not what needs changing.

Hopes dressed up as progress

Heap is blunt about postmortems full of "we should involve support earlier", "we need to communicate better" or "we'll be more careful next time": those are hopes dressed up as progress. If a corrective action depends on people remembering a conversation from six months ago, it is organisational folklore. His test: if everyone involved in the incident left the company tomorrow, would the fix still work? A process that forces a decision here is an improvement; a system that prevents the whole class of mistake is stronger still — though not every failure deserves a new process.

A declaration of trust

"I don't want the details" sounded dismissive to Heap at first. He came to read it differently: what sounded like impatience was a declaration of trust. The executive assumed the people involved were competent and well intentioned, and did not want empathy to become the organisation's excuse for not changing. Heap's closing formulation for leaders: "I believe you. I don't need the details. Tell me what we're changing."