Templates, Action Items & Follow-Through

## The single test Every quality rule for action items collapses into one question: **could a person who was not in the incident tell, weeks later, whether this item is done?** If the answer is no, the item will quietly rot in the document, and the postmortem will have produced a nice narrative and no change. ## The three shapes that always fail **The open-ended investigation.** "Investigate why the connection pool saturated." Investigation has no definition of done — you can always investigate more — so the item can never be closed honestly, only abandoned. Worse, an unfinished investigation is usually a sign the analysis was cut short and the postmortem was published before it was understood. If you genuinely need more digging, the item should be time-boxed and produce an artifact: "Spend up to two days reproducing the saturation and either file the fix ticket or write up why it is not reproducible, by 6 March." Now it can close. **The exhortation.** "Be more careful when editing production configuration." "Remember to check the dashboard after a deploy." These ask a human to be reliably different next time, under worse conditions than the ones in which they already failed. They are also, in practice, a fault attribution wearing procedural clothes. The systemic version of the same item is what you want: make the dangerous edit impossible, require staged rollout, add a confirmation for the destructive path, or add the check to an automated gate. **The unbounded improvement.** "Improve monitoring of the payments service." There is no signal named, no threshold, no owner of the judgment. Compare: "Alert when replica lag exceeds 30 seconds for 5 minutes, routed to the payments rotation." That one is buildable and checkable. ## The fields a real item carries - **A concrete change**, phrased as an outcome, one item per row. Two changes bundled into one row means half of it silently never happens. - **A single named individual owner.** Not "the platform team", not "SRE". A team alias has no calendar and no accountability; assigning to a team is how items become nobody's. The individual can delegate, but someone answers for it. If no individual will take it, that is real information: the item is not actually going to happen and you should either find an owner or drop it honestly. - **A priority**, on the same scale the team uses for everything else, so it can be compared with feature work rather than living on a separate, ignorable list. - **A due date**, which gives you an aging signal. An item three weeks past its date is a visible fact; an undated item is never late. - **A tracker ID.** The item's canonical home is the team's backlog. The postmortem *links* to it. Action items that live only inside the document never enter sprint planning, and anything that does not enter planning does not get staffed. - **A type.** Google's SRE book template classifies items as prevent, mitigate, detect or process. ```yaml action_items: - title: Stage config pushes region by region type: prevent # prevent | mitigate | detect | process owner: tomas.k # an individual, never a team alias priority: P1 due: 2026-03-06 tracker: REL-482 # lives in the backlog; the doc only links here ``` ## Why the typing matters A set of action items that is entirely *prevent* is a common and expensive mistake. Prevention items are aimed at the failure you just had — but the next incident will be a different one, and the prevention you just built will not apply to it. *Detect* and *mitigate* items generalize: a faster rollback path, a saturation alert, a documented drain procedure all pay out across failure modes you have not seen yet. A healthy set usually has at least one of each, and if you can only afford one item, a mitigation that halves your recovery time is often worth more than a prevention that eliminates one specific cause. *Process* items — updating a runbook, changing an escalation path — are the cheapest and the easiest to fake. A runbook step that has never been executed is not a control, so a process item ideally ends with someone having actually run it. ## Volume discipline Twenty action items is not a thorough postmortem; it is an unstaffed wish list, and shipping none of twenty is the normal outcome. Commit to the handful you will genuinely staff, mark the rest explicitly as "considered and not taken" with a one-line reason, and let that honest record be the thing a future reader finds — rather than a graveyard of open tickets that teaches everyone the items are decorative.