The postmortem template is not the point

I have run or reviewed something like two hundred incident postmortems over the last decade, across four different companies. The single most consistent failure mode I've seen has nothing to do with the incident itself -- it's that the postmortem template becomes the deliverable, instead of the shared understanding it was supposed to produce.

Here's what that looks like in practice. An incident happens. Someone is assigned to "write the postmortem." They fill in the template: timeline, root cause, action items. The document gets reviewed, maybe in a meeting nobody enjoys, and filed away. Three months later the same class of failure happens again, and someone discovers the old postmortem, reads it, and realizes the action items were never actually completed -- or worse, they were completed and the failure happened anyway because the "root cause" analysis stopped one layer too shallow.

The template isn't the problem. A good template is useful scaffolding. The problem is treating the act of filling it out as equivalent to the act of actually understanding what happened and fixing it.

A few things I've found that actually move the needle, none of which are template changes:

First, every postmortem should have exactly one owner who is accountable for the action items closing, not just for writing the document. Diffuse ownership is why action items rot -- if everyone is responsible, no one is.

Second, "five whys" style root cause analysis needs a hard stopping rule, because without one it either stops too early (at the first plausible-sounding cause) or never stops at all. My rule: keep asking why until the answer would require changing something about how the organization actually operates, not just a technical fix. That's usually where the real root cause lives.

Third -- and this is the one people resist the most -- re-open old postmortems on a schedule, not just when something breaks again. Once a quarter, pull five old postmortems at random and check: did the action items actually ship? If a pattern of unshipped action items emerges, that's a much more useful signal about your engineering culture than any individual incident is.

None of this is about writing better documents. It's about treating the postmortem as the start of a process, not the end of one.