Skipping the Minutiae: A Lesson in Systemic Change

A few months back, I found myself on a call with my engineering counterpart and their manager—the SVP of Engineering. While the situation wasn't a total disaster, it was significant enough to warrant executive attention.

As I began to walk through the sequence of events, I was abruptly interrupted:

"Michael, I don't want the details."

The SVP elaborated: they knew that if we dove into the specifics, the justifications would be perfectly logical. I would explain the context, they would understand the reasoning behind the decisions, and they would feel empathy for us.

Initially, I felt this was dismissive. I wondered: How can a leader make an informed choice without the full context? However, I soon realized that "I don't want the details" wasn't a brush-off; it was an expression of trust. The executive assumed we were competent and was essentially saying, "I already believe you."

The Trap of the "Why"

In most corporate cultures, the immediate reaction to a failure is to ask: "Why did this happen?"

This typically results in a detailed report outlining a specific chain of events. The outcome usually looks like this:

1. The team presents the sequence of events.
2. Everyone agrees the behavior was "reasonable" given the circumstances.
3. Everyone nods and moves on.

The urgency to fix the root cause vanishes. When an incident is framed as an "understandable sequence of events" where no one is truly at fault, nothing actually changes. Consequently, the same failure recurs six months later, leaving the team baffled as to why they are back in the same position.

Shifting the Inquiry

To actually drive organizational evolution, stop asking why it happened. Instead, ask:

"What are we changing so that the same class of failure is less likely next time?"

The "Reasonable People" Paradox

The SVP wasn't interested in the "who" or the "how." They didn't need to be convinced that the staff acted reasonably. Their core concern was: "Given that reasonable people produced this outcome, what needs to change?"

Consider these scenarios:

• Scenario A: "We missed the deadline because Alice was on vacation and Bob assumed the Widgets team was handling it."
  • The Systemic Question: How do we ensure ownership is crystal clear even when key personnel are absent?
• Scenario B: "The alert triggered, but the engineer had already ignored twenty low-priority notifications that night."
  • The Systemic Question: How do we reduce noise so that critical alerts are actually noticed?

The "Hopes" vs. "Fixes" Distinction

Many postmortems are filled with "hopes" disguised as progress. If your corrective actions look like the following code block, you haven't actually fixed anything:

{
  "corrective_actions": [
    "We should involve support earlier",
    "We need to communicate better",
    "We will be more careful next time"
  ],
  "status": "Hoping for the best"
}

If your solution relies on someone remembering a meeting from half a year ago, it isn't a solution. To test the validity of a fix, apply the Bus Test:

If every person involved in the incident left the company tomorrow, would the fix still be effective?

If the answer is no, then the individuals may have learned a lesson, but the system is still broken.

Engineering the Right Balance

To ensure a postmortem drives lasting change, ask: "If this exact situation happened tomorrow, what would cause a different outcome?"

• Improvement: A process that mandates a decision at a specific juncture.
• Strength: A system that makes this class of mistake impossible.

However, be careful not to over-engineer. If you try to prevent every single possible failure, you create a bureaucratic nightmare that no one wants to work in. Sometimes, the cost of prevention exceeds the cost of occasional failure.

The difference lies in the intent:

• Bad: "We'll try harder next time" (Emotional platitude).
• Good: "We are consciously accepting this risk" (Calculated decision).

Summary Checklist for Incident Review

• Avoid the "Empathy Trap" (don't let understanding excuse inaction).
• Identify the class of failure, not just the specific event.
• Verify the fix survives the "Bus Test."
• Balance systemic prevention against operational friction.

Final Thoughts

The SVP didn't need proof of our competence or good intentions. They wanted to prevent empathy from becoming the tool the organization used to avoid the hard work of changing.

Most people make the best decisions possible given their current information, incentives, and constraints. In those moments, the most powerful thing a leader can say is: "I believe you."

---

Visualizing the Logic Flow

The Risk Equation

We can think of the organizational risk as a function of probability and impact:

$Risk = P(\text{failure}) \times \text{Impact}$

When we say "we'll be more careful," we are pretending to lower $P(\text{failure})$ without actually changing the variables. A systemic fix actually modifies the equation.