I don't want the details
An essay about an engineering SVP who says “I don’t want the details, I want to know what we’re changing” after an outage has prompted debate over how leaders should handle incident reviews. Many see value in focusing executives on systemic fixes, resource tradeoffs, and team empowerment rather than technical minutiae, while others argue that refusing to hear details can be dismissive, undermine accountability, and lead to poorly informed decisions. The exchange highlights broader tensions around trust, organizational maturity, post‑mortem practices, and the role of senior leaders in technical organizations.
Role of Executives and Level of Detail
- Many argue it is reasonable for senior leaders to focus on “what changes now?” rather than technical timelines and minutiae, especially in large orgs where deep involvement in every incident is infeasible.
- Others see “I don’t want the details” as a red flag: without understanding the problem, leaders can’t judge whether proposed changes are appropriate, proportional, or aligned with broader goals.
- Several note that execs still need high‑level detail for prioritization, budgeting, cross‑team coordination, and to report upwards or externally.
Trust, Accountability, and Autonomy
- Supporters frame the SVP’s stance as trust: assume reasonable behavior and competence; push teams to own analysis and solutions.
- Critics view it as performative accountability or power play: distancing from the failure while demanding fixes, potentially shifting all risk downward.
- There is agreement that trust is always bounded: leaders may trust competence but still must set direction, manage trade‑offs, and “trust but verify.”
Incident Postmortems: Cause vs Change
- Many participants say their standard postmortems already combine: what happened, impact, root causes, and action items with owners.
- Debate centers on emphasis: some warn that dwelling on explanations can reduce urgency to change; others insist you cannot design good, non‑theatrical fixes without a solid understanding of causes and contributing factors.
- Several reference “5 whys” / root‑cause thinking, but emphasize that complex incidents usually have multiple contributing factors, not a single “root.”
Organizational Scale and Culture
- Some see this as normal “context management” in big companies; execs should avoid becoming technical bottlenecks.
- Others argue orgs that are too large for leaders to understand ground‑level work are inherently problematic.
- Comments highlight fear, blame cultures, and overwork as frequent hidden causes that require leadership‑level changes (staffing, process, incentives).
Critiques of the Article and Tone
- Multiple commenters say the piece reads like LinkedIn/AI “thought leadership,” over-dramatizing a fairly obvious point.
- Enthusiasts like the focus on preventing recurrence and the line about “organizational folklore.”
- Skeptics call it naïve or apologetic toward a possibly dismissive SVP, and note that better phrasing could convey trust without sounding like “don’t waste my time.”