The retro action items nobody did.

The most consistent finding I have across engagements is also the one I have the hardest time naming politely. Most postmortem action items don't get done.

The pattern is uniform enough that I now ask for the data in the first week of every engagement. "Pull the last twenty postmortems. For each action item, tell me what the status is." The answer is, with very high reliability:

• 15–30% shipped.
• 20–30% partially done, but never closed out.
• 40–60% never started.
• A small remainder discovered to be duplicates of action items from earlier postmortems that also weren't done.

The last category is the one that should sting. The same root cause has been identified two or three times. Each time, the team agreed on the fix. Each time, the fix didn't get done. Each time, the next incident was the same incident.

Why the action items don't ship

The instinct is to say it's a discipline problem. It isn't. When I talk to the teams I audit, they want to do the work. The reasons the items don't ship are structural, and they repeat:

1. No named owner, or an owner with no authority. The action item says "platform team to investigate the retry configuration." Platform team has no specific person assigned, no specific time allocated. The item lives in the platform team's collective inbox forever.
2. No deadline, or a deadline that competed with sprint work and lost. The action item exists in the postmortem doc, not in the team's planning system. When sprint planning happens on Monday, the action items don't compete because they aren't visible.
3. The action item is too big to ship. "Migrate the service to the new platform." That's not an action item; that's a quarter of work. It sits in the postmortem because the pressure of the incident made it feel doable. By Tuesday, the scope is obvious and nobody starts.
4. The retro happens, the action items get written, and nobody re-reads the document. No follow-up review is scheduled. The document is the artefact; the action items inside it are the implicit promise. The promise has no enforcement.

All four of these are addressable. None of them require a culture change. They require process discipline of a kind most teams have never been asked for.

What "good" looks like

The teams whose action items ship at a healthy rate share three practices. None are exotic.

• Action items are written into the same backlog as sprint work. Not into the postmortem doc only. Into Jira, Linear, GitHub, whatever the team uses to plan. With a label that lets you filter for them.
• Every action item has a single named person and a single date. Not "team X." Not "this quarter." A name and a sprint. If you can't name a person, the item isn't ready to enter the backlog yet — it needs a precursor item that says "decide who owns this."
• A monthly retro-of-retros reviews stuck items. One hour. The director or engineering manager attends. Stuck items are explained: blocked, deprioritised, abandoned. Each gets a decision. The list is shorter at the end of the meeting than the beginning.

The retro-of-retros is the part most teams skip. It's the part that makes the rest work. Without it, the items don't get visibility, and without visibility, they decay.

Sizing items so they actually ship

The other practice that distinguishes high-closure teams is how they write the items in the first place. The bad versions look like this:

"Improve observability of the orders pipeline."

That isn't an action item. It's a wish. Nobody can ship it, because nobody knows what "shipped" means. The good version of the same intent might be three items:

• "Add a per-tenant latency SLI to the orders endpoint by end of sprint, owned by Maya."
• "Wire that SLI to a burn-rate alert by sprint+1, owned by Daniel."
• "Update the orders runbook to link to the new dashboard by sprint+1, owned by Maya."

Three items, three owners, three deadlines, all small enough to fit in a sprint. The original wish becomes deliverable. The retro facilitator's job is to refuse vague items and break them down before the meeting ends.

The metric to publish

The metric that changes behaviour is action-item closure rate. Pick a window — usually the trailing quarter — and compute the percentage of action items in that window that have been closed. Publish it. Show it on the engineering dashboard. Show it in the monthly leadership review. The number is uncomfortable at first. Within a quarter or two, it goes up, because what gets measured against in public gets prioritised.

The line worth holding

Postmortems that don't produce shipped fixes are storytelling, not learning. The team has agreed on what's wrong. The team has not agreed to do the work. The action item is the bridge between the two, and the bridge needs ownership, deadlines, and a public closure rate to actually carry weight. Without those, you'll keep writing the same postmortem, and the next incident is the same incident.