Six months after an outage, the same class of failure recurs and you discover the earlier postmortem's action items were never completed. How do you fix follow-through?

## Diagnose before you prescribe "The action items were never completed" hides at least four different failures, and the interviewer is usually checking whether you distinguish them: 1. **They never left the document.** The items were written in the postmortem and nowhere else, so they never appeared in any planning conversation. This is the most common case and the easiest to fix. 2. **They were tracked but never staffed.** Tickets exist, aged, and lost every prioritization round to work with a nearer deadline. 3. **They were completed but ineffective.** Closed on time, and the failure recurred anyway — which means the analysis was wrong or the items addressed a symptom. 4. **They were the wrong items to begin with** — twenty of them, none funded, so "incomplete" was the predictable outcome of over-committing. Only the first two are follow-through problems. Cases three and four are quality problems that better tracking will not touch. ## Make the backlog the single home Action items must live where work is chosen. The postmortem *links* to tracker rows; it does not store them. Anything held only in a document is invisible during sprint planning, and invisible work is unstaffed work. The corollary is that they carry the same fields as everything else — owner, priority, due date — so they can be compared with feature work rather than sitting on a separate list that is easy to ignore. Tag them so they are recoverable as a set. A saved query for "open, priority P1, source = postmortem, older than 30 days" is the entire mechanism behind everything else in this answer. ## Measure two numbers, not one - **Completion rate** of committed items over a rolling window. - **Age of open high-priority items** — the more diagnostic of the two. A team can show a healthy completion rate while its hardest, most valuable items sit untouched for months, because the easy ones close and flatter the average. Both are only meaningful if you cap what you commit to. If a postmortem produces twenty items and you staff four, the honest record says four were committed and sixteen were considered and declined with a reason — not that you completed 20% of your commitments. ## Reserve the capacity, then defend it The real reason items rot is that they compete with work that has a customer waiting. Three mechanisms help, in increasing order of strength: - **A standing share of each sprint** reserved for reliability work. Cheap to agree, easy to erode. - **A recurring review of overdue items** with the people who can reprioritize in the room. Aging items that are read out loud regularly either get done or get closed honestly; both beat silence. - **An error-budget policy.** This is the strongest lever, because it is a pre-agreed rule rather than a negotiation held while under pressure: when a service has burned its budget, reliability work — including outstanding postmortem items — takes precedence. The value is that the argument was won *before* the moment when nobody wants to have it. ## Close the loop honestly An item that is not going to be done should be closed with a stated reason, not left open. A backlog of permanently open postmortem items teaches everyone that the items are decorative, and that lesson generalizes — the next postmortem's items get written with less care because the authors already know how this ends. ## Use the recurrence itself When the same class of failure returns, the new postmortem should state it explicitly: an earlier postmortem identified this risk, item REL-482 was opened and never staffed, and here is the cost that decision has now produced. This is not blame-hunting — it is the single most persuasive artifact you will ever have for funding reliability work, because it converts a hypothetical into a bill that has already been paid twice. Follow it with the prevention question one level up: what would have made that item survive prioritization? Usually the answer is that it needed protected capacity or a named owner with the authority to schedule it, and that is the fix worth writing down. ## What good looks like A team with healthy follow-through can answer, from a saved query and without preparation: how many action items are open, how old the oldest P1 is, and which ones were consciously declined. If nobody can answer that in a minute, the process is not running regardless of how good the documents look.