Michael Heap was pulled onto a call about something that had gone wrong. Nothing catastrophic, but serious enough to include the SVP of engineering. He started explaining how it happened and was cut off: “Michael, I don’t want the details.” The reason, as the SVP gave it, was that the explanation would be perfectly reasonable, he would understand and empathise — and then it would happen again. The 125-comment thread on Hacker News spends most of its length arguing with that.

The argument

  • The reflex question after an incident is “why did this happen?” Answering it produces timelines, reconstructed decisions, dependencies — a document everyone nods at. Heap’s claim is blunt: understanding an issue is not the same as fixing it, and a good explanation can make things worse, because once everyone agrees the behaviour was reasonable, the urgency to change anything disappears.
  • The question he prefers: what are we changing so that the same class of failure is less likely next time? Or, given that reasonable people produced this outcome, what needs to change?
  • His worked examples run the same shape. “We missed it because Alice was on holiday and Bob thought the Widgets team owned it” → how do we make ownership unambiguous when someone is unavailable? “Requirements changed three days before launch” → what happens when they change inside the launch window? “The alert fired, but on-call had already dealt with twenty low-value alerts that evening” → how do we improve the signal-to-noise ratio?
  • The test he applies to any corrective action: if everyone involved left the company tomorrow, would the fix still work? If not, it is organizational folklore rather than a fix. Sentences like “we’ll be more careful next time” are “hopes dressed up as progress”.
  • The concession at the end is that not every failure deserves a new process — sometimes accepting the risk is cheaper than preventing it. But accept it with your eyes open: “We are consciously accepting this risk” is a different statement from saying we will try harder.

What the thread adds

  • kevin_nisbet — the missing step between incident and change. For something described as non-catastrophic, there “shouldn’t be a presumption of changes”: assess the risk of recurrence, what the cost would have been had it not been a near miss, then weigh the fix against that cost before spending resources.
  • juancn — two concrete practice problems. Continuous-improvement processes are additive (rules and alerts accumulate and nothing is ever removed), and “root cause” is the wrong frame for complex failures with many contributing factors. Their proposed rename: RCA to “Contributing Factor Analysis”.
  • insanetake and mooreds — the exchange that reframes the essay’s premise. Their postmortems always carried timelines, impact, five whys and action items (“I’ve never seen a post-mortem without actionable items”). The submitter’s reply is the sharper question — “Do the actionable items usually get implemented?” — and 4lx87 answers it: “The important part is the action items are assigned an owner and executed… Most organizations pay lip service to reliability.”
  • miiiiiike — the same instinct without the brush-off: “This is the kind of mistake that we get to make once. How do we prevent it from happening again.” They usually want the details as well.
  • locknitpicker — the audience argument. Root-cause analysis, trade-offs and plans are all still required, “but not everyone needs to do root cause analysis and evaluate tradeoffs and review plans.” Different stakeholders need different messages, which is close to what the SVP was actually doing.
  • Lerc — the counterexample to “fix the system, not the people”: someone has to work out what the system change is, “and to do that they need the details.” Their candidate for the role is a manager, whose job is to see how the parts fit together.

Where the thread pushes back

  • The top-ranked comment rejects the essay’s central reading. FartyMcFarter: if you trust the team completely you do not need to know what happens next either, and if you do not trust them, “how can you know if ‘what happens next’ is appropriate without knowing the details?” Their worry is that this “is just reinforcing the idea that leadership doesn’t need to have their feet on the ground.” dspillett and 0manrho answer that even a trusting manager needs the what-next and the timescales — for resourcing, scheduling and conflicts elsewhere.
  • scsh and calyhre argue the essay sets up a false choice: the why is precisely what informs the what-next, and it should be documented as institutional knowledge either way. feoren goes further, reading the SVP out of the meeting entirely — “The SVP could be completely removed from this situation and the outcome would be exactly the same” — and pointing out that the Alice-and-Bob story is the detail you need before deciding ownership is the thing to fix.
  • zkmon, kube-system and markus_zhang read the SVP’s accountability rather than their empathy: someone responsible for recurrence does need the details, and at that level the question is organisational change rather than technical change.
  • dsr_ — same verdict, unsparing: “The executive did not display empathy. People need to tell their stories.”
  • Some read the genre rather than the argument. groundzeros2015: “This article may be more appropriate for LinkedIn”, with stephbook agreeing and guessing at AI authorship (“Give AI vibes”). That is an impression, not a finding — the author’s account of the call is firsthand.

On reading comments as evidence: HN handles are pseudonymous and the site publishes no per-comment scores, so the ordering above is HN’s own ranking, not a vote. The claims about how postmortems are usually run and what leadership does with them are commenter claims, quoted as claims. This is a slice of a 125-comment thread, not a consensus.