🚨 Postmortem Anti-Pattern: Action Items That Never Ship

Overview

An action item that never ships is the most common way a postmortem fails silently. The incident is analyzed, the document is thorough, the review meeting goes well — and then the follow-up work stalls in a backlog no one grooms. Six months later the same failure recurs, and the postmortem for the second incident quietly repeats the action items from the first.

This anti-pattern is corrosive because it is invisible in the moment. Nothing breaks when an action item is written; the failure only surfaces later, as a recurrence or as a slow erosion of trust in the postmortem process itself. Once engineers learn that follow-ups do not get done, they stop investing in writing good ones, and the whole ritual decays into paperwork. Treating action-item completion as a first-class, tracked outcome — not a byproduct of the meeting — is what separates a learning organization from one that merely documents its incidents.

Symptoms

• Recurring incidents with near-identical root causes, where the earlier postmortem already named the fix.
• Action items with no owner, or owned by a team rather than a named person, so no one is accountable.
• No due dates, or due dates that silently pass without any status change.
• Items living only in the postmortem document, never mirrored into the team’s real issue tracker or sprint board.
• A backlog of “reliability” tickets that is never pulled into a sprint because feature work always wins prioritization.
• Vague action items like “improve monitoring” or “add more tests” that cannot be marked done because “done” was never defined.
• Review meetings that close the incident but never revisit whether the last incident’s items shipped.

Common Root Causes

• No ownership model. Items are assigned to a team, a rotation, or “we should,” so accountability diffuses to zero.
• No tracking outside the doc. The action item lives in a Google Doc or wiki page and is never created as a ticket in the system where work actually flows.
• Unmeasurable “done.” The item restates the problem (“make the database more reliable”) instead of specifying a testable deliverable, so it can never be closed.
• Prioritization loss. Reliability work competes with feature work in the same backlog and consistently loses because it has no protected capacity.
• No closeout loop. Nothing revisits open items from prior postmortems; there is no recurring review of completion.
• Too many items. The postmortem produces fifteen action items, none prioritized, so the team does the two easy ones and abandons the rest.
• The author leaves the room. The person motivated to fix it moves teams, and the item has no institutional owner to carry it.

Diagnostic Workflow

Start by measuring completion, not intent. Pull the action items from your last quarter of postmortems and check how many actually shipped:

For each postmortem in the last 90 days:
  - list its action items
  - for each item: does it have (a) a named owner, (b) a due date,
    (c) a ticket in the real tracker, (d) a testable definition of done?
  - is the ticket Open / In progress / Done / Abandoned?

Then quantify the completion rate:

completion rate = (action items marked Done) / (total action items)

A rate below roughly 60% means the process is producing documents, not change. Next, check for recurrence — the clearest proof that items are not shipping:

Group incidents by root-cause theme.
Any theme appearing 2+ times where an earlier postmortem
already had a matching action item = a never-shipped item that bit you.

Finally, audit item quality at the source. Sample ten recent action items and score each: is it owned by a person, dated, tracked, and testable? Items failing any of these four checks are structurally unshippable regardless of anyone’s good intentions.

Example Root Cause Analysis

Incident: A payment service went down for 40 minutes when a database connection pool exhausted under load — the second such outage in five months.

Shallow reading: “The team didn’t prioritize the fix.” This blames the team and prescribes nothing actionable.

Structured RCA of the process failure:

1. The first outage’s postmortem listed the action item “Add connection pool monitoring and tune pool size.”
2. That item had no named owner — it was assigned to the platform team broadly.
3. It was written only in the postmortem doc; no ticket was ever created in Jira.
4. “Tune pool size” had no definition of done, so even if someone picked it up, completion was ambiguous.
5. With no owner, no ticket, and no closeout review, the item was never surfaced in any sprint planning.
6. Five months later the identical failure recurred, unmitigated.

Contributing factors (systemic, not personal): reliability items shared a backlog with feature work and had no protected capacity; there was no recurring review of open postmortem items; the team’s postmortem template had an “action items” field but no required owner/tracker/DoD columns.

The fix isn’t “try harder.” It is a structural change: every action item must have a named owner, a ticket in the tracker, and a testable definition of done before the postmortem is considered closed, plus a monthly review of open items across all recent postmortems.

Prevention Best Practices

• Require four fields per action item: a named human owner, a due date, a link to a ticket in the real tracker, and a testable definition of done. Reject the postmortem as incomplete if any are missing.
• Mirror items into the tracker immediately, during the review meeting, not “later.” An action item that only exists in the document does not exist.
• Make “done” testable. Rewrite “improve monitoring” into “add an alert that fires when pool utilization exceeds 80% for 2 minutes, verified in staging.”
• Protect reliability capacity. Reserve a fixed slice of each sprint for postmortem follow-ups so they never lose to feature work by default.
• Cap the count. Prefer three action items that ship over fifteen that don’t; prioritize ruthlessly by recurrence risk and impact.
• Run a recurring closeout review. Monthly, walk every open action item from recent postmortems and update status. Aging items get escalated, not forgotten.
• Track completion rate as a metric and review the trend. If it drops, the process — not the people — needs fixing.

Quick Reference

# A shippable action item has all four:
[ ] Named human owner (not a team)
[ ] Due date
[ ] Ticket in the real tracker (not just the doc)
[ ] Testable definition of done

# Health checks
completion rate  = Done items / total items      (target > 60%, ideally > 80%)
recurrence check = incidents whose fix was already an unshipped action item
closeout cadence = monthly review of all open postmortem action items

# Red flags
- owner is a team or "we"          -> assign a person
- "improve X" / "add more Y"        -> define testable done
- item only in the postmortem doc   -> create the ticket now
- 10+ action items, none ranked     -> cut to top 3 by recurrence risk

Conclusion

Action items that never ship turn postmortems into theater: the analysis is real, but nothing changes, and the same incidents return. The failure is structural, not a matter of effort — items without a named owner, a tracker entry, a due date, and a testable definition of done are unshippable by construction, and reliability work that shares a backlog with features will always lose. Fix the structure: require the four fields, mirror items into the tracker on the spot, protect a sliver of capacity for follow-ups, and run a monthly closeout review. Measure the completion rate and watch recurrence drop. A postmortem is only worth writing if the work it prescribes actually gets done.