Postmortems are very good at making a failure make sense, and a failure that makes sense feels handled. Now that a model can write a flawless root-cause section in ninety seconds, explanations are free and change is as expensive as ever. The only part of the document that matters is the part nobody reads.
An outage happens. The team does the work, writes the document, books the room, and walks in ready to explain. Then a senior vice president says the thing that Michael Heap wrote up this week and that went to the top of Hacker News by lunchtime: I know that if we get into the details, the reasons will be perfectly reasonable. You’ll explain what happened, I’ll understand why everyone made the decisions they made, and I’ll empathise with you. Then it’ll happen again. So I don’t want the details. I want to know what we’re changing.
The reaction on the thread split cleanly. Half the readers recognised the best manager they ever had. The other half recognised the worst: the executive who cannot be bothered with how the system works and wants a slide. One commenter put the objection precisely. If you trust the team, you do not need to hear the plan either, and if you do not trust them, you cannot judge the plan without the details.
Both halves are right about something, and the disagreement hides a mechanism that is worth getting straight, because this year it got a great deal worse.
Here is the mechanism in one paragraph. A failure produces discomfort in everyone who has to answer for it. A good explanation removes that discomfort. It turns a frightening event into a sequence of reasonable decisions under reasonable constraints, and once every step makes sense, the organisation experiences the incident as understood, and understood feels exactly like handled. The discomfort was the only force pushing towards change, and the explanation spent it. The better the root-cause section, the more completely it discharges the pressure that would have paid for the fix.
That is why the vice president’s instinct is sound even if the delivery is blunt. The trouble lives in the satisfying narrative, because it is the cheapest way to close the loop, and the loop only needed closing once.
Anyone who has written a few postmortems has felt this from the inside. The writing is the satisfying part. You reconstruct the timeline, find the moment the alert fired and nobody looked, and there is a small craftsman’s pleasure when the five whys land on something clean. By the time the action-item table comes round it is late on a Thursday, the table has seven rows, two of them say “improve monitoring”, and every owner is a person rather than a role.
One commenter pointed out, fairly, that every postmortem they have written had action items. Ours too. The question is what happens to row four six months later, when its owner has changed teams and the Jira ticket has been re-triaged to “backlog, low” by someone who never read the document.
Two things changed this year, and both push in the same direction.
First, explanations became free. A model will take the incident channel, the deploy log and the alert history and produce a root-cause analysis in about ninety seconds that is better written than most of the ones humans produced in 2023. It will be balanced, blameless, correctly formatted and entirely convincing. It is also exactly the artefact that discharges the discomfort. The cost of the satisfying part fell to zero. The cost of the structural change (a new ownership rule, a launch-window policy, an alert that is actually removed) did not move at all, because it is paid in somebody’s authority and somebody’s calendar, and a model has neither.
Several readers of the Heap piece said the essay itself read as machine-assisted. Whether or not that is so, it is the right suspicion to have about every postmortem you will read from now on: the prose quality tells you nothing about whether anything changed.
Second, more of the failures now have explanations that are genuinely delightful. Take a story that was on the same front page this week. A developer found that a popular coding agent’s support for project instruction files sat behind a remote feature flag, so with telemetry switched off the file was silently never read. He proved it by hiding the word “periwinkle” in the file and asking the agent what it said. The vendor fixed it quickly. It is a wonderful piece of detective work, and it illustrates the trap perfectly. Everyone who reads that story understands it, enjoys it, and then does nothing about the class of failure it belongs to, which is configuration your system depends on can be silently ignored, and nothing tells you. Most teams have instruction files, feature flags or environment variables that would fail the periwinkle test today, and almost nobody went and checked.
Or take Samsung, which confirmed this week, as reported by Android Authority, that a work-in-progress update meant for testing reached customer refrigerators in Korea over the Chuseok holiday. The explanation will be perfectly reasonable. It always is. There was a system error in the testing process. The question the vice president would ask is which gate now stands between a test build and a family’s kitchen, and whether that gate works if the person who built it leaves.
Heap’s piece contains the best one-line test we have seen for this, and it is worth lifting out on its own:
If everyone involved in the incident left the company tomorrow, would the fix still work? If not, you have organisational folklore, not an improvement.
Run the last five action-item tables you own through it. The results are usually uncomfortable. “Bob will double-check replica ownership before maintenance” fails. “Alice now knows to look at the queue-depth dashboard” fails. “We had a retro and everyone is more aware” fails, and it is the most common action item in the industry. What passes is boring: a rule written where the next person will trip over it, a check that runs without anyone remembering it, an alert that was deleted, a deploy that now cannot happen during a launch window because the pipeline refuses.
The sharpest criticism on the thread deserves a straight answer. A leader who refuses the details cannot tell a good fix from a bad one. That is true, and it does not argue for skipping the details. It argues for changing what the details are for.
In a review that works, the details are evidence for a proposed change, and they are presented in that order. The team opens with what is changing and how anyone would know it had worked. Then the details arrive as the argument for that change, and the leader interrogates them as hard as they like, because now every question has a purpose: does this detail support the fix, or does it reveal a second failure the fix does not cover? The timeline stops being a story and becomes an exhibit.
In a review that fails, the details come first, and they arrive as a narrative. By the time the narrative is over, everyone in the room has empathised with everyone else, and the proposed changes are received in the warm afterglow of mutual understanding, which is the worst possible condition for scrutinising them.
So the order is the whole trick. The vice president who says “I don’t want the details” is compressing a better instruction, which is I want the change first, and I will ask for exactly the details I need to believe it.
It is worth saying where this goes too far. Some incidents are genuinely novel, and for those the understanding is the product. The first time a team sees a failure mode in a new kind of system (an agent acting with more permission than anyone realised, say) the careful narrative is how the organisation learns what the system even is. Skipping it would be a mistake. And some structural fixes are worse than the disease: a rule written in anger after one bad night can tax every deploy for years. A good review rejects changes too.
But those are the exceptions, and most organisations do not suffer from too little explanation. They suffer from explanation being the only output that reliably ships.
Four things, in the order that pays back fastest.
Reorder the template. Move “What we are changing” to the top of the postmortem document, above the timeline, with a column for “how we will know it worked” and a column for “survives departure: yes/no”. If a row says no, it is not finished.
Assign rows to roles, not names. “The owner of the payments service” outlives Tomasz. When the role does not exist, that is the finding.
Let the model write the narrative, and never let it write the change. Use the tools for what they are now excellent at: assembling the timeline, drafting the summary, finding the alert that fired at 02:14. Then have a person who holds the authority to change something write the top section, by hand, in fewer than two hundred words. If nobody in the room has that authority, the review is a reading group.
Audit the old tables. Pick the last twelve months of postmortems and count how many action items closed with a structural change, and how many incidents recurred with the same root cause. That pair of numbers says more about the reliability of your organisation than any uptime figure, and in our experience the second number is rarely zero.
This is the same argument we make about agents in production. A system that is allowed to act needs a gate, and a gate is only real when it is owned by a role, written where the next person will find it, and still works after the person who built it has gone. Incident reviews are the gate on your organisation’s own behaviour. Most of them are currently a very well-written sign on an open door.
The explanation is the easy part now. It was always going to be, eventually. What is still scarce is somebody deciding what will be different next time, and writing it down where it cannot be forgotten.
Support automation, AI phone agents, n8n back-office work, and the engineering loop itself — always behind a gate you control.