TL;DR: Action items repeat because nothing verifies them and nothing classifies causes, so the same systemic hole gets patched with aspirational tickets. The fix is unglamorous: every item needs an owner, a date and a test that fails before recurrence, and a standing metric for cause-class recurrence.
How to approach it
Treat this as a systems question, not an etiquette one. Name the two loops that must exist (verification of fixes, classification of causes), then say how you would instrument both. Avoid the word culture until you have described machinery that would change behaviour even in a mediocre culture.
A strong answer
Identical action items can mean the fix was not implemented, was ineffective or was described too vaguely to distinguish different causes. That is a pipeline failure, and it has identifiable stages.
Items are written as wishes. "Improve alerting", "add more tests", "be more careful with config changes". None has an owner, a deadline, or a definition of done, so none can be completed or failed. Compare "alert on p99 over 500ms for 10 minutes, owned by the payments team, live by 30 November" against the wish version; only one can be reviewed at the next incident.
Nothing checks completion against recurrence. A ticket queue loses its value when closing an action item requires only believing it worked, and nobody re-opens an incident review to ask. The mechanism I would add costs little: before any post-mortem meeting, read the previous incident's items aloud and mark each done, overdue, or abandoned, with names attached. Abandoned twice becomes an escalation. Reviewing the list exposes overdue work; completion still needs capacity and verification.
Causes are never classified, so patterns stay invisible. Three incidents with three write-ups but no taxonomy produce no signal. Tag every contributing factor into a small fixed set: missing timeout, untested rollback, config drift, capacity assumption, permission gap. When "untested rollback" appears for the third time, that is not three incidents, it is one programme (rehearsed rollbacks) hiding inside three tickets.
Blame survived the blameless framing. "The operator forgot to run the migration" reads blameless and is not: it ends the inquiry at a person. The systemic restatement is "the deploy tool allowed serving traffic against an unmigrated schema", which yields a guardrail rather than a training reminder. Reviewers should describe what people knew and why their actions made sense at the time, then identify the system conditions that made the failure possible.
Reviews optimise for closure, not learning. Forty-five minutes, a timeline nobody audits, actions assigned in the last five minutes. The timeline deserves the scrutiny: what did we believe at 02:10, what made mitigation slow, which dashboard lied? Those answers generate the items that actually prevent recurrence.
The metric that proves the process works is blunt: recurrence rate of the same cause class within six months. It is also worth computing, because the first reading usually settles the argument about whether this is a real problem.
Take 12 incidents over six months, each tagged with one cause class. Suppose 7 are the first of their class and 5 repeat a class already seen: recurrence is 5 / 12 ≈ 42 percent, meaning nearly half your incidents are ones you had already diagnosed and written up. That is a different claim from "post-mortems feel unproductive", and it is the one that gets remediation funded.
The class breakdown then points at the work. If 4 of those 5 repeats carry the same tag, you do not have four incidents needing four fixes; you have one programme, and the recurrence number tells you what it is worth. Interpret the trend with incident volume and classification changes; inspect the repeated mechanisms behind it.
Turn a repeated item into an acceptance test
Suppose three reviews say “improve rollback.” Ask what failed in each incident. One release lacked a retained artifact, another changed a database schema incompatibly, and a third had no operator permission to execute the rollback. Those share a label but require different work. Preserve that detail in the taxonomy.
For the missing-artifact case, define a test: deploy a disposable service revision, expire the normal build workspace, and restore the previous approved digest using the documented release path. The owner records the result and the artifact retention policy. Closing the ticket requires that evidence, not just a new runbook paragraph.
Review recurrence alongside exposure and severity. Five repeat incidents out of twelve is useful descriptive arithmetic, but a changing incident-reporting threshold can move the percentage without changing reliability. Check whether the underlying failure mechanism recurred after its specific corrective action shipped. Keep an explicitly accepted risk visible when remediation remains unfunded.
What interviewers probe next
"How do you keep blamelessness from becoming accountability-free?" Blameless applies to people, not outcomes: owners are named, dates are real, abandonment escalates. The protection is that questions target systems ("what allowed this") and never persons ("who did this").
"What about action items nobody wants to fund?" Rank them by expected incident cost avoided and take the top three to planning with the post-mortem attached. An unfunded item is a decision, so record it as one rather than letting it rot quietly.
"Should every incident get this treatment?" Full review above a severity line; lightweight reviews below it, but always with classified causes, because the taxonomy is where cross-incident signal lives.
Common mistakes
Answering with values ("just make people care") and no mechanism. Interviewers hear a candidate who has attended post-mortems but never fixed one.
Adding a new approval gate after every incident. Gates slow every future change to prevent one past failure, and teams route around them within a quarter.
Confusing the document with the outcome. A beautifully formatted report whose items vanish is worse than a rough note whose items ship, because it manufactures the feeling of closure.
References