Post-Incident Reviews That Actually Change Something

Open a new incident channel. Someone pastes in the link to the postmortem from a similar incident, eighteen months back. You skim the findings, then the action items, and notice that four of the seven are still sitting in whatever status meant “someone will get to it” on the day the document was written. Finding number two, it turns out, is the same root cause you are about to write down again, word for word.

Do this long enough and you get the joke. Reviews rarely fail because they are badly written. Most of them read fine: an honest timeline, and a list of remediations with tidy checkboxes next to them. The checkbox is the problem. It implies someone comes back later and ticks it, and nobody ever put that step on anyone's calendar.

Somewhere along the way, “we did a postmortem” started meaning “we held a meeting and produced a document.” The meeting happened. Everyone used the blameless language correctly and nodded at the right moments. Then the document went into the same folder as the last one, and the organization moved on to whatever was on fire that week, which was, by definition, never the thing the review had already covered.

Try this on your own archive. Pull the last two or three reviews for the same system and compare the action items line by line. If the same fix shows up twice, the issue isn't how carefully you document incidents. The real problem is what happens, or doesn't happen, in the eighteen months after everyone signs off and goes back to their actual jobs.

What makes a fix stick

What separates a review that changes something from one that just narrates the next incident in advance comes down to three concrete things: a specific person's name on each item instead of a team's, a real date instead of “next quarter,” and someone senior enough to notice, and mind, when that date slides.

“Platform team will investigate pool sizing” looks like an action item and functions like a wish wearing the font of one, and a wish owned by an entire team is a wish owned by nobody. Compare it with “Dana adds a hard cap and an alert on pool exhaustion by the fourteenth.” One version has a specific human who feels a small, useful pang of guilt in standup if it slips. The other has six people quietly agreeing it's someone else's sprint.

The date matters for the same reason estimates matter anywhere else: a deadline with no teeth is a suggestion wearing a calendar icon. Track these items on the same board where the rest of the real work lives, with the same visibility and the same nagging, instead of a wiki page nobody reopens until the next incident forces them to. And put someone with genuine authority on the hook for whether the fixes land, not just whether the meeting got scheduled. A review with no senior owner produces excellent prose and zero pressure. A review where a director asks, three weeks later, whether that pool cap shipped, produces one slightly awkward message and a shipped pool cap.

Closing out the month

None of this is complicated, which is exactly why it keeps not happening. Writing a careful document is the easy part. Sitting through the mildly uncomfortable conversation about why last time's fixes never shipped is the hard part, and that discomfort is the whole mechanism everything else depends on.

This wraps up a month of plans, tests, and reviews, and the same fault line runs under all three: paper is cheap, follow-through is not. A plan nobody rehearses is a document. A review nobody closes is the same document, filed under a new date. Skip the follow-through again, and you are not writing a postmortem. You are drafting next year's opening exhibit.