Why Smart Leaders Skip the Details and Ask for Change

The Call That Changed How I Think About Postmortems

Michael Heap, an engineering leader, was recently pulled into a call with his engineering counterpart and their SVP of engineering. Something had gone wrong—not catastrophic, but serious enough to warrant executive attention. As Heap began to explain the sequence of events, the SVP cut him off with a phrase that initially felt dismissive: "Michael, I don't want the details."

The SVP continued, explaining that if they dove into the details, the reasons would be perfectly reasonable. He'd understand the decisions, empathize with the team, and then—critically—the same thing would happen again. His final question reframed the entire conversation: "I want to know what we're changing."

At first, Heap thought this was a shortcut—a leader avoiding the messy complexity of a real incident. But he soon realized it was the opposite. The SVP was declaring trust: "I already believe you. Now let's talk about what happens next."

The Problem with "Why Did This Happen?"

Most organizations respond to failure by asking a single question: "Why did this happen?" It's a question everyone knows how to answer. Teams write timelines, reconstruct decisions, and map dependencies. They produce a document that explains the specific combination of events that led to the incident.

Everyone nods. They say, "That makes sense." And then they move on with their day. But as Heap points out, understanding an issue is not the same as fixing it. In fact, a good explanation can make things worse. Once everyone agrees the behavior was reasonable, the urgency to change anything evaporates.

When an incident is framed as an unfortunate but understandable sequence of events where no one is at fault, nothing changes. Six months later, the same failure recurs, and everyone wonders how they landed there again.

Shifting the Question

To drive real change, Heap argues, organizations should stop asking "Why did this happen?" and instead ask: "What are we changing so that the same class of failure is less likely next time?"

This reframing has profound implications. Consider these common postmortem explanations:

• "We missed it because Alice was on holiday and Bob thought the Widgets team owned it." The real question: How do we make ownership unambiguous when someone is unavailable?
• "The requirements changed three days before launch." The real question: What happens when requirements change inside the launch window?
• "The alert fired, but the on-call engineer had already dealt with twenty low-value alerts that evening." The real question: How do we improve the signal-to-noise ratio of our alerts?

Each of these shifts moves the focus from individual blame to systemic improvement. As Heap notes, "The people are usually not what needs changing." They're making the best decisions they can with the information, incentives, and constraints around them.

Why Good Explanations Are Not Fixes

Heap is particularly critical of postmortems filled with vague commitments like "we should involve support earlier" or "we need to communicate better." His favorite: "We'll be more careful next time." These are, in his words, "a collection of hopes dressed up as progress."

If a corrective action depends on people remembering a conversation from six months ago, you don't have a corrective action—you have organizational folklore. Heap poses a simple test: If everyone involved in the incident left the company tomorrow, would the fix still work? If the answer is no, then the people may have learned something, but the system is still destined to fail.

The stronger question is: "If the same situation happened tomorrow, what would cause a different outcome?" A process that forces a decision is an improvement. A system that prevents the class of mistake is even stronger.

The Risk of Process for Process' Sake

But Heap warns against overcorrecting. Not every failure deserves a new process. That's how you build environments no one wants to work in. Sometimes the cost of preventing recurrence is higher than the cost of occasionally accepting the failure—and that's okay.

The key is to accept failure with your eyes open. "We are consciously accepting this risk" is fundamentally different from "we said we'd try harder and everyone felt better." The former is a strategic decision; the latter is an emotional pacifier.

Trust as a Leadership Tool

Reflecting on the call, Heap now sees the SVP's impatience as a declaration of trust. The executive didn't need proof that the team was competent or well-intentioned. He was willing to start from that assumption. If the investigation showed otherwise, that could be dealt with separately.

What the SVP didn't want was for empathy to become the mechanism by which the organization absolved itself of having to change. That's a subtle but critical distinction. Empathy is not a substitute for improvement.

As Heap concludes, "Sometimes the most useful thing a leader can say is: 'I believe you. I don't need the details. Tell me what we're changing.'"

Why This Matters for Engineering Teams

This lesson is particularly relevant for engineering teams, where postmortems are a staple of incident response. The traditional format—timeline, root cause, action items—often produces documents that are thorough but ineffective. By shifting the focus from explanation to change, teams can break the cycle of recurring incidents.

It also speaks to a broader leadership principle: trust your team's competence, and hold the system accountable. People are rarely the root cause of systemic failures. The sooner organizations internalize that, the sooner they'll stop repeating the same mistakes.