Think about the last serious incident on your team. As the engineering manager, you can probably recall the root cause, the timeline and the postmortem meeting. Can you name one thing that works differently today because of it, and who made sure it happened?

Source: Michael Heap, “I don’t want the details” (michaelheap.com, Sep 23, 2026).

Michael Heap describes a call he was pulled into after an incident. It was no catastrophe, yet important enough to bring in his counterpart's boss, a senior vice president. Heap began explaining the cause and was stopped. The executive did not want the details.

The reasoning, as Heap tells it, is simple. The explanation would be sensible. The executive would follow it and feel sympathy. After that, the problem would return. So the useful conversation was about what would change.

At first Heap heard the remark as dismissive. On reflection he read it as the opposite. The executive already assumed his team was competent, so there was nothing to prove, and the conversation could move on.

From there Heap makes a wider point. After an incident, most organizations ask why it happened, and we are well practiced at answering. We build timelines, reconstruct decisions and map dependencies. Everyone agrees it makes sense. Heap argues that this agreement can quietly slow progress, because once the behavior looks reasonable, the pressure to change anything fades. He asks leaders to assume that sensible people produced the result and to examine the system around them. His replacement for "why?" asks which change would make incidents of this kind less likely.

He gives three short examples: a task that fell through while one person was away, requirements that moved shortly before a launch, and an on-call engineer worn down by noisy alerts. Each one turns a story about people into a design question about ownership, late changes or alert quality.

Heap is direct about corrective actions that lean on people. Promises to communicate better or to be more careful are hopes. A fix that depends on people remembering an old talk is closer to folklore than to a safeguard. His test is whether the fix would survive if everyone involved had left. Making the team face a choice when it counts helps. Designing the mistake out helps more.

He adds two cautions. A new process is not the answer to every incident, and sometimes accepting a risk is the right call, as long as it is a deliberate choice. And he reads the executive's stance as trust: start from good faith, and do not let sympathy become a reason to leave things unchanged.

Heap's story is a good provocation, but I would not copy the executive's sentence literally. Details are how you find the right fix. If you never hear how an incident unfolded, you will pick a change that sounds good and misses the cause.

What I take from it is a different job for the details. In most reviews the narrative is the product. The timeline gets the care, and the actions are added at the end, when the energy has gone. Flip that. The narrative exists to support the changes, and it should be judged by whether it points to one.

In my experience there is a quiet incentive behind this pattern, and engineering managers set it. The person writing the review is rewarded for clarity and for protecting colleagues. A thorough, fair account delivers both. Few people are rewarded for writing "we will rebuild how we deploy," because that costs weeks of someone's time, and only the EM can promise those weeks. If you do not, the review drifts toward whatever is easy to finish.

A blameless culture is a valuable thing, and it can still drift into a changeless one. Blameless should mean we do not punish people for sensible decisions. It should never mean we stop asking what the system should do differently.

One mechanism helps more than most. Put the proposed changes on the first page of the review, and give the timeline a fixed share of the meeting. If the room spends the whole hour on the story, the review has spent its time on the past and not on the next step.

Not every corrective action is equal. I sort them on a rough ladder, strongest first: remove the hazard, automate the check, force a choice at the right time, remind people, and hope. Heap's hopes sit at the bottom. Reminders are only slightly better, because they fade with turnover and busy weeks.

Here is an example, and it is hypothetical. Picture a team where a configuration change went live with a typo and disrupted a service for customers. The first action list says: "Double-check configuration changes." That is a hope. A stronger list adds a validation step in the pipeline that rejects malformed configuration, plus a staged rollout so a new change reaches only a few users first. The first item costs attention forever. The others cost work once.

Alert noise is another common case. Picture an on-call rotation where many pages are low-value, which makes the important one hard to spot. "Respond faster" is a hope. Merging or removing the low-value alerts, and adopting a rule that every page must point to a clear action, changes what the next night looks like.

Heap's test, whether the fix survives if everyone involved leaves, is a good filter. I use it as a starting point, not a verdict. Some fixes rightly depend on people. Judgment, training and a careful on-call handover cannot be fully automated. The better question is whether something catches the miss when the person is tired, new or absent. A human step is fine if there is a backstop behind it.

Also be honest about cost. Strong fixes are usually expensive. Removing a hazard might mean a migration, while the weak fix is a note in a wiki. When the price is high, say so out loud, and choose between paying it and accepting the risk on purpose.

Most corrective actions stall, not because they are weak, but because nobody has time. Follow-up items sit in a separate document, away from the planning that decides what gets built, so they compete with feature requests and often come second. This is where the engineering manager earns their title. Your team cannot win that trade-off on its own; you have to make it with your product partner.

Treat them as real work. Put them in the same backlog as product work, each with a named owner, a due date and a size, and bring them to planning yourself. Keep the list short. In my experience, a review that leaves one or two meaningful changes does more than a review that leaves ten items nobody finishes. A long list usually means you are recording activity, not choosing.

Then defend them. When a reliability fix competes with a feature, make the cost of the next repeat incident visible: customer impact, on-call load, and the hours the team will spend writing the same report again. Many teams protect a fixed share of each sprint or cycle for this work, so the argument is not re-fought every week. If a fix still loses, record that as an accepted risk, with your name on it.

Then look across incidents, not only at one. Heap talks about a class of incident, and a single review rarely reveals a class. Picture a team that reads its last several reviews together and notices that several different outages began with a change nobody could test before release. No single review would have proposed a realistic test environment. The pattern does.

A month after a fix ships, go back and check it. Did the alert quiet down, did the new rule get used, did anyone work around it? A fix that was never verified is only a belief.

Accepted risk deserves the same discipline. Write down what the risk is, who accepted it and when it will be looked at again. Without a review date, an accepted risk can quietly become a forgotten one.

And know where the idea runs out. Heap is right that the people are rarely the thing to fix. Rarely is not never. If the same gap keeps appearing around one person or one role, that is a coaching, staffing or fit question for you as their manager. It deserves a separate, private one-on-one, not a system change used as cover, and never a name in the postmortem. Good faith is the place to start, not a guarantee.

The part of Heap's story that stays with me is not the sentence. It is the posture behind it. A leader who starts from good faith makes it safe to talk about the system, because nobody feels judged.

That posture has to be earned and shown. If people have seen past incidents end with someone singled out, "I trust you" may sound like the opening line of the same story. Trust is built by what happens in the second week, when the owner of a fix asks for time and actually gets it.

If you are the engineering manager who owns the incident, use the same idea from the other side. Lead with the fix before anyone has to ask: what you have already changed, what you propose to change and what you need, whether that is time, headcount or a roadmap trade-off. A short, clear opening makes the hearing smaller and moves the conversation to the work.

Picture a manager who joins an escalation call and says: here is what happened, here are the two changes we are making, and here is what we need from you. The senior leader has less to probe, and the team comes across as owners of the fix.

Senior leaders should be careful too. Your short questions carry weight. A leader who cuts people off every time may teach a team to share fewer details. Skip the story only when the team already knows you will read the review, and tell them so.

As an engineering manager, which fix from a past incident has lasted, and what made it stick: a tool, a default, an owner, protected capacity or something else? Hit reply and tell me. I read every answer.

Keep going, one small spark at a time.

Erwin