I don't want the details
TL;DR
After an incident, asking why it happened tends to produce a reasonable story and no change. Michael Heap retells how an SVP cut off his explanation. He argues the useful question is what the team will change to make the same class of failure less likely.
The article
- When Heap started explaining a failure, his SVP of engineering stopped him. The SVP said the reasons would be perfectly reasonable and everyone would empathise. Then it would happen again, so he wanted to hear what was changing.
- Heap first took this as dismissive. He later read it as trust: the SVP assumed the people involved were competent and wanted to skip straight to what happens next.
- A good explanation can make things worse. Once everyone agrees the behaviour was reasonable, nobody feels urgency to change anything. Then the same incident returns six months later.
- Postmortem actions like "communicate better" or "be more careful" are hopes, not fixes. Heap's test is whether the fix would still work if everyone involved left the company tomorrow.
- Not every failure deserves a new process. Accepting a risk is fine when the team decides it on purpose. That is different from promising to try harder.
Why it matters
It's a four-minute read, and the summary covers nearly all of it. Open the original for the three example excuses, each paired with the system question it should prompt. They work as a checklist for reviewing your own postmortem action items.
The discussion
Most of the thread pushed back hard: a leader can't judge whether a fix is any good without hearing what broke. Many read the SVP as dismissive or as dodging accountability. Defenders said an SVP's job is resourcing and coordination, not the technical replay, and a steady minority dismissed the post as LinkedIn-style or AI-sounding.
You can't evaluate a fix without the problem
The largest camp said the details are what tell you whether a proposed change fits the failure. The article's Alice-and-Bob example is itself the details, one noted, and siloed teams often propose changes that clash across the organization. Defenders replied that the team still does the root-cause work; the SVP just doesn't need to sit through it. Several asked what the SVP was in the meeting for if they wouldn't engage.
I don't like approaches that proxy "I understand the problem" with "I have a solution", and saying I trust someone doesn't cover this; it's firmly in the "trust but verify" category.
The executive is there to help with the big picture, but you can't see the big picture if the canvas is blank.
What trust buys a leader, and what the SVP is for
The top thread opened with a dilemma: with full trust you don't need the plan, and without it you need the details to judge it. Replies pulled "trust" apart: trusting that people acted reasonably differs from trusting them to fix things alone. Others listed reasons a leader wants the plan but not the timeline: reporting upward, freeing budget or headcount, spotting conflicts with other teams. One added that leaders who absorb every detail cap how many teams the organization can run.
Trusting that people are capable and well intentioned does not mean trusting that they will accomplish the same thing without you.
The SVP is inviting a higher level discussion around what resources need to be consumed in order to be sure this doesn't happen again. And they're opening the door to defending that use of resources.
Efficient or dismissive
Even fans of the SVP's point disliked the wording: "I don't want the details" lands as "don't waste my time" and hurts morale. Harsher readings called it a power move, a refusal to hear people out, or a way to push risk downward. In that reading, "we" change something but you own the decision. A few defended bluntness as respect for everyone's time.
But otherwise be very wary of this pattern of communication where "we" might mean "you".
My claim is that it would have taken slightly more words to get that point across without any reputational downside to the SVP.
Why versus what is a false choice
Many said every postmortem they have done already ends in action items, so the article attacks a straw man. To them, the "why" is what tells you what to change. Others went after root-cause analysis itself: complex failures have many contributing factors, and a team forced to find one root cause will produce one. In one CAPA story, a plain typo became a form-design flaw because human error wasn't an acceptable root cause.
"How/why did this happen?" informs how you answer "What are we changing?"
My other nit with these is a term that's abused a lot "Root Cause", most complex issues have many contributing factors, not a single root cause, and if you force the teams to find one, they will.
Changes cost something, and action items rot
Some faulted the SVP's question for leaving out the cost of the change. Fixes compete for time and money. For a minor incident the right answer may be no change, which the article concedes only at the end. Others said improvement processes only add rules and checks until work crawls, and written action items often rot in a backlog.
And then even should changes be part of the outcomes, how expensive are those to implement compared to whatever the issue was, and if they're too expensive compared to the risk, don't put resources into it.
Actionable items go onto the backlog. The backlog grows from the top.
Consensus
Postmortems should end in concrete changes to the system rather than promises to be careful. A leader doesn't need a minute-by-minute replay. The article's line about "organizational folklore" drew praise even from its critics.
Dissent
Most commenters rejected the idea that "why" and "what changes" are separate questions. In their view, a leader who won't hear the problem can't judge the fix. The SVP's framing, intended or not, came across as dismissive or as pushing risk onto subordinates.