The problem
The postmortems were good. The action items were sensible. Months later, a lot of them were still open, and sometimes the same incident happened again for a reason an open action item would have fixed.
How I measured it
# open postmortem action items by age (tracked as issues with a label)
gh issue list --label postmortem-action --state open --limit 200 \
--json number,title,createdAt,assignees \
| jq -r '.[] | [(now - (.createdAt|fromdate))/86400|floor, .number, (.assignees|length), .title] | @tsv' \
| sort -rn | head -20
# items with no assignee
gh issue list --label postmortem-action --state open --json number,assignees \
| jq '[.[] | select(.assignees|length==0)] | length'
Plenty of old items, and some with nobody assigned at all.
Why it kept happening
Action items lived in the postmortem document and nowhere else. They weren't in anyone's backlog, so they competed with nothing and lost to everything.
The process change
- Tickets, not bullets: every action item becomes a ticket in the owning team's backlog, labelled, linked to the postmortem.
- Owner and date: a team and a due date before the postmortem is marked done.
- Priority by type: items that would prevent a repeat of a high-severity incident get done first.
- Monthly review: overdue items come up in the operating review. Each one gets done, re-dated with a reason, or explicitly dropped.
Dropping an item was allowed. Leaving it open and forgotten wasn't.
What I learnt
Most action items didn't need more urgency. They needed to be somewhere a team plans its work. Moving them into the backlog did most of it.
What I do now
- Turn action items into tickets in the owning team's backlog.
- Review overdue ones monthly.
- Allow "won't do" as a decision, and write down why.
if your postmortems keep finding the same cause → page me