Blog post 'I Don't Want the Details' sparks HN debate over blameless postmortems
An engineer's essay reframing an SVP's dismissal of incident details as a trust signal draws pushback from commenters who call the logic contradictory.
What to know
- The essay reframes an executive cutting off incident details as a sign of trust rather than dismissiveness, urging teams to focus on process fixes over explanations.
- The post reached Hacker News's front page (170+ points, 100+ comments), generating substantial pushback on its central logic.
- A recurring critique: the essay's trust argument is internally inconsistent, since full trust in staff should also eliminate the need to dictate 'what happens next.'
- Other commenters split on whether skipping detailed root-cause explanations helps organizations move faster or risks bandaid fixes that don't address underlying problems.
The dispute Whether an executive skipping incident details signals healthy trust and delegation, or avoids the understanding needed to fix the real problem. · positions read across 45 posts and comments
The essay's trust logic is contradictory: real trust would make even asking about next steps unnecessary, and partial trust requires the details.
-
“If you trust them completely, you don't need to know what happens next either. Just trust them to do the right things, your leadership isn't required.”
FartyMcFarter · Hacker News ↗
Understanding the full 'why' is necessary; skipping details risks bandaid fixes rather than real solutions.
-
“Understanding the complete "why" is a precondition for that. Not bothering to hear a complete explanation because you trust your people to do the right thing is fine, but then why were you on that call in the first place?”
f33d5173 · Hacker News ↗
The SVP's stance reflects organizational maturity: assuming competence and steering the conversation toward systemic fixes rather than blame.
-
“I already believe we reached this point through rational choices. Let's talk about how to change the system so it doesn't happen again.”
cushychicken · Hacker News ↗
Michael Heap Author of the essaySVP of engineering (unnamed) Subject of the essay
How it unfolded 4 developments, newest first · click a bar or a number to jump articlespostscomments
-
4
Critic calls the essay's premise flawed
A commenter rejects the essay outright, arguing that understanding the full 'why' is a precondition for correctly fixing problems and that skipping it risks bandaid solutions.
“Understanding the complete "why" is a precondition for that. Not bothering to hear a complete explanation because you trust your people to do the right thing is fine, but then why were you on that call in the first place?”
— f33d5173 -
"Okay, then I'm going to rewomble the dinglehop, which should un-galvatrate the percapitator." Why is the SVP in the meeting at all? If they don't want the details, they can't contribute to the change, or even evaluate whether the change makes sense at all. The SVP could be completely removed from this situation and the outcome would be exactly…
2 more of the top 3 · 31 posts in this stretch
-
N
I don't want the details: https:// michaelheap.com/i-dont-want-th e-details/ Discussion: http:// news.ycombinator.com/item?id=4 9815466
-
Lots of folks are commenting on the internal dynamics, but the other part that didn't resonate with me was actually the what happens next part. This may be an overreaction on my part, stemming from watching lots of engineers suggest expensive solutions to relatively minor issues. And it's a mistake I've made myself before as well, I started in…
-
-
3
Other commenters defend the SVP's framing as maturity
Several commenters side with the essay's core point, describing the SVP's stance as a sign of organizational maturity that prioritizes fixing systems over assigning blame.
“I already believe we reached this point through rational choices. Let's talk about how to change the system so it doesn't happen again.”
— cushychicken -
A lot of times, people just need a gentle nudge, or an official blessing from an authority figure, to go ahead and make the change that is necessary. You can tell people to manage up, to fully own their work and their process, etc. But a lot of humans don’t want to step on others’ toes or be perceived as acting out of line. A worker on the…
2 more of the top 3 · 7 posts in this stretch
-
> To drive change in your organization, don't ask "why did this happen?".> Instead, ask:> What are we changing so that the same class of failure is less likely next time?Why are these framed as being almost mutually exclusive? I don't get it. "How/why did this happen?" informs how you answer "What are we changing?" Even the following section…
-
The best leaders know what they need to pay attention to. You cannot know everything. You can know any one thing (or perhaps several), but there are more things to know than you will have time to learn in your lifetime. The question is what is important for you to know, and what you leave to somebody else.You will have to trust someone will figure…
-
-
2
Commenters call the trust logic self-contradictory
Readers on Hacker News argue the essay's own reasoning undermines itself: full trust would make even 'what happens next' unnecessary to ask, while partial trust requires knowing the details.
“If you trust them completely, you don't need to know what happens next either. Just trust them to do the right things, your leadership isn't required.”
— FartyMcFarter -
In a large enough organization it is simply impossible for executives to be on the ground floor with everyone else. And not only is it impossible, it is essentially a waste of their time. They could maybe be maximally involved in only a few projects at a time.I think its entirely contextual as to what the size of the org is and the scope of the…
2 more of the top 3 · 7 posts in this stretch
-
H
I Don't Want the Details L: https:// michaelheap.com/i-dont-want-th e-details/ C: https:// news.ycombinator.com/item?id=4 9815466 posted on 2026.09.23 at 09:04:44 (c=0, p=6)
-
You answered your own question.> If you trust them completely, you don't need to know what happens next either. Just trust them to do the right things, your leadership isn't required.> The best leaders I've worked with were paying attention to things from the bottom-up as well as top-down.These two statements are at odds. You first assuming that…
-
-
1
Michael Heap publishes 'I Don't Want the Details' essay
Heap recounts an SVP cutting off his incident explanation and argues the phrase signaled trust in competence rather than dismissiveness, urging teams to ask 'what are we changing' instead of 'why did this happen.'
“I already believe you. Now let's talk about what happens next…”
— Michael Heap (paraphrasing the SVP) -
2 outlets I don't want the details
first by HN Best, 17h ago · also HN Frontpage
-
What people are saying 14 voices from 1 site · best of 45 · verbatim
- Can you meaningfully decide 'what changes' without first understanding 'why it happened'?
- Does refusing details actually build trust, or just push accountability downward without oversight?
- Yesterday
-
This is a very long winded way of saying, "I don't care how it happened, tell me what you are going to do about it."There's something about the way this is drafted that irks me. It reads like AI, but not floridly so. Mostly, it's the optimistic assumptions layered throughout. That management care about reasonableness, that the reasons it actually…
-
> "I don't want the details. I want to know what we're changing."This really feels like the sort of senior manager who would say "oh, this/these team/s screwed up, so here's the plan they came up with", talking about their team/s.Speaking as a C-suite guy, "they" is about as contrary as I can think of what I expect a leader to do: it's "we", and…
-
> "What happens when requirements change inside the launch window?" > "The alert fired but..."In the running example I think it is clear that you could stop at any point and address the problem from that point rather than continuing. Questions such as "Why do we permit last minute changes at all?" are given no space.In a complex system sometimes…
-
A good explanation is not a fix but is a good starting point to a good diagnosis which is the foundation of a good fix.The issue is when the calls and urgency are raised before making some mental space to even verify that there is enough clarity on what happen and these interrupt the clarification and remediation planning process.Saying you…
-
I think that's overthinking it.First of all, he didn't say the executive "trusted them completely". Those are your words.He said "The executive assumed that we were competent, and was saying "I already believe you. Now let's talk about what happens next".".That can be true even if they don't trust them completely. Let's say he trusted them 80% and…
-
Asking what the OP was going to change is not an automatic nod of approval for his approach. I’ve been part of some large interventions spanning multiple quarters, that started from a simple conversation with an exec just like this. There are downstream effects to these decisions that affect many stakeholders and departments - so they cannot be…
-
Strongly disagree with this.In order to figure out a good solution, you have to have mastery over the problem. That takes a bunch of work.> Understanding an issue is not the same as fixing it. A good explanation can make things worse. Once everyone agrees that the behaviour was reasonable, the urgency to change anything disappears.This is a…
-
The post-mortem process can cover all of these things: - what happened - impact - root causes - what will be changed (commitments) You can't really talk about what to change w/o talking about root causes, and you can't talk about that without talking about what happened. You also can't consider the costs of commitments to be made w/o discussing…
-
I sympathise with this, and a lot of teams do operate that way, but I fundamentally disagree with it.Part of the reason Amazon's CoE-driven engineer culture had such operation excellence is that the responsibility was driven the whole way up the management chain. If your manager didn't dig down to the root cause of a sev2, the director was damn…
-
Idiotic article. Nobody collects "why"s so they can not change anything. Not changing anything is never the failure mode. The failure mode is changing the wrong thing. If you are a leader, and something egregious goes wrong, it is your job to ensure that your people don't just put some bandaid fix on it that will keep causing issues indefinitely…
-
There's still some problem with that approach. OK, I will tell what I'm going change to prevent recurrence of the issue. How does that makes sense to the audience? Unless they just want hear that "some" change will be there and don't care about how that change would make any sense.It boils down to what exactly is the ownership or accountability of…
-
One thing that's often left out that tends to grind organizations to a halt is that continuous improvement processes tend to be additive.You always add rules, and alerts, and so on. You need to revisit existing processes to and see what can be removed or replaced.My other nit with these is a term that's abused a lot "Root Cause", most complex…
-
I suspect the author still misunderstands the SVP. If I were the SVP of engineering saying this to someone, especially someone who is in a non-core engineering role like product, I probably recognize that they have a tendency to verbally spew and I want them to focus on the risk mitigation and response plan. I’ve already talked to my engineering…
-
> Then I realised that "I don't want the details" wasn't being dismissive. The executive assumed that we were competent, and was saying "I already believe you. Now let's talk about what happens next".Something about this feels wrong:- If you trust them completely, you don't need to know what happens next either. Just trust them to do the right…