An engineering leader’s request to “skip the details” can sound like dismissal. In Michael Heap’s account, however, the executive’s point was narrower: the people involved were presumed competent, so reconstructing every reasonable decision was not the main task. The priority was deciding what the organization would change after a failure.
The opening paragraph recounts Heap’s account of an executive asking to skip details while focusing on organizational change.
Heap argues that postmortems often answer “Why did this happen?” with a coherent timeline, only to discover that every action made sense under the information, incentives, and constraints available at the time. That understanding matters, but it does not itself reduce recurrence. A story can explain why an alert was missed, ownership was ambiguous, or late requirements entered a launch window while leaving the conditions that created those problems intact.
The useful follow-up is: “Given that reasonable people produced this outcome, what needs to change?” That question turns examples into design requirements. If coverage depends on one person, ownership needs an explicit backup. If launch changes create predictable disruption, the process needs a rule for decisions made inside the launch window. If responders ignore alerts after repeated false positives, the alerting system—not individual patience—needs attention.
This does not mean leaders should avoid technical or operational details. Heap’s position is not that explanation is useless or that executives can assess every remedy without context. The distinction is between details used to understand accountability and details used to choose an intervention. A leader still needs enough evidence to test whether a proposed change addresses the relevant failure class, does not create a larger risk, and is proportionate to the cost of prevention.
Heap also warns against corrective actions that depend on memory: “communicate better,” “be more careful,” or “involve support earlier” may express good intentions without changing what happens tomorrow. A stronger action creates a constraint, route, gate, or decision point that remains effective when the original participants are absent. The practical test is counterfactual: if the same situation occurred again, what would cause a different outcome?
The opposite mistake is adding process after every incident. Heap explicitly says that not every failure deserves another rule; sometimes prevention costs more than occasional recurrence. The important shift is from accidental tolerance to explicit risk acceptance. An organization can reasonably leave a weakness in place, but it should know the expected cost, assign responsibility for that decision, and revisit it when conditions change.
The supplied material does not independently establish that this approach reduces incident rates. The primary article supports Heap’s claim about his conversation and presents his operating philosophy; the supporting GitHub page identifies Heap as a developer, writer, and product leader but does not validate the management method. The article therefore treats “ask what changes” as a decision framework, not a proven universal law. Its value is practical: it keeps a review connected to a future action while preserving the details needed to judge that action.