The action item graveyard

Every engineering organization maintains a cemetery it never visits. It is the collected action items of every postmortem it has ever run, and if you exhume yours, you will find the same headstones as everyone else's: "add alerting for queue depth," assigned to someone who changed teams. "Document the failover procedure," open for nineteen months. "Add rate limiting to the internal API," which would have prevented the incident you had last Tuesday, filed after the incident you had last spring.

The industry loves postmortems, and it should. Blameless culture was a genuine civilizational advance for engineering organizations. But somewhere along the way we confused holding the ritual with doing the learning, and the graveyard is the proof. Studies of incident follow-up, and the informal audits engineering leaders occasionally inflict on themselves, keep landing in the same range: somewhere between a third and two-thirds of postmortem action items are never completed. Repeat incidents, ones where the organization already possessed the knowledge to prevent the recurrence, make up a painful share of every on-call rotation's load.

It is worth being precise about why, because the failure has a specific anatomy, and the anatomy suggests the fix.

How an action item dies

An action item is born in the postmortem meeting, in the warm glow of resolve. Everyone in the room genuinely intends it to happen. Then it is written into a document, and here it encounters its first mortality risk: postmortem documents are write-only media. They get read in the week after the incident and then never again, by anyone, until an archaeologist like me shows up.

If the item escapes the document into a ticket, it faces the second risk: it enters a backlog, and a backlog is a competition, and "prevent a hypothetical future incident" loses the competition against "ship the feature committed to a customer" every sprint, forever, until the hypothetical future incident stops being hypothetical. This is not a moral failure of prioritization. Nobody's roadmap has a line for the outage that didn't happen.

The third risk is organizational drift. The assignee changes teams, the service gets a new owner, the quarter turns over, and the item now belongs to no one. There is no mechanism by which it re-finds an owner, because nothing is watching.

And the deepest failure is the one that never even reaches the graveyard: the connection that never gets made. The knowledge from March's incident, the config subsystem is fragile under concurrent updates, exists in a document. In November, an engineer three teams away is about to make a concurrent update to that subsystem. Nothing connects them. The organization knows the thing and the person doesn't, which is the same as the organization not knowing it. Institutional memory in most companies is not memory at all. It is a filing system with amnesia about its own contents.

What changes when something is always watching

The teams that have started attacking this did not do it with better postmortem templates. They did it by giving the follow-through to participants that never lose interest, and the resulting division of labor is instructive.

The postmortem itself stays profoundly human. Machines do not decide what an organization should learn; that is judgment, and it belongs in a room full of the people who lived the incident. But the moment the meeting ends, the custody changes. The action items go to an agent whose entire job is to see them through: it files the tickets with the incident context attached, and then it does the thing no human sustainably does, it keeps caring. Two weeks of silence on the rate-limiting item and it nudges the owner in the team channel. Two more weeks and it escalates to the engineering manager, not as nagging but as a decision request: this item from incident 2025-31 is stalling, either prioritize it or explicitly accept the risk and close it. That framing matters. It converts silent decay into a recorded choice, and managers who must record the choice choose differently than managers who can simply let a ticket age.

When the assignee changes teams, the agent notices the orphaned item within days, not quarters, and asks the new service owner to adopt or decline it. The graveyard stops accepting new residents not because the organization got more disciplined but because burial now requires a signature.

The connection problem gets the more interesting treatment. On these teams, an agent sits in the incident channel during new incidents and does what Company B's responders describe as the déjà vu check: it compares the failure signature against every past postmortem and surfaces matches with the relevant history. "This resembles 2024-117; the fix then was X; the action item to prevent recurrence was closed as won't-do in June" is a sentence that changes an incident, and occasionally a sentence that changes a roadmap meeting the following week, because nothing rehabilitates a deprioritized item like documented recurrence. Some teams have pushed it further upstream: the same knowledge gets checked against proposed changes, so the engineer about to make the concurrent config update in November gets pinged with March's scar tissue before the change ships, and the incident that would have justified the déjà vu never occurs.

One engineering director described the cumulative effect in a way that stuck with me:

The graveyard audit

If you run incident response and want one uncomfortable afternoon that will change your roadmap, do the audit. Pull every action item from the last two years of postmortems. Count what fraction was completed. Then take your last ten incidents and count how many were preventable with knowledge your organization had already written down.

Most leaders who do this find that their postmortem process, the ritual they are proudest of, has been producing insight at a rate the organization absorbs at maybe forty percent, and that the missing sixty percent has a body count denominated in on-call nights and customer trust. The insight was never the scarce resource. The follow-through was, and follow-through is precisely the kind of tireless, unglamorous, memory-intensive work that organizations have finally stopped asking humans to be reliable at.

Somewhere in your backlog right now is the ticket that prevents your next major incident. It knows which one it is. Nobody else does. That, more or less, is the whole problem.