Cruxly › Cloud and DevOps › Cloud & DevOps: Incident Response

Blameless Postmortems That Actually Produce Working Action Items

the Etsy/Dekker origin, and why most postmortems don't change anything

Prompt: a team runs blameless postmortems after every significant incident — no-fault language, a structured writeup, a meeting where everyone's encouraged to speak freely. Despite this, the same categories of incident keep recurring. Diagnose why the blameless format alone hasn't produced real change, and fix the actual gap.

30 minutes first. The naive diagnosis is "the postmortems aren't blameless enough." The format was likely fine; the missing piece is almost always what happens (or doesn't) to the action items after the meeting ends.

Why blameless works: the actual philosophical claim, not just etiquette

The blameless postmortem wasn't first codified as an abstract best practice — it has a specific, documented origin. John Allspaw, then Etsy's SVP of Technical Operations (he became CTO later), published "Blameless PostMortems and a Just Culture" in 2012. It built on Sidney Dekker's "Just Culture" work on human factors and safety, and on the idea of seeking the "second story", which comes from Richard Cook and David Woods' resilience-engineering research: the actions someone took made sense to them, given what they knew and the pressures they were under at that moment, and understanding why they made sense is a more useful diagnostic than assigning fault after the fact, with the benefit of hindsight the person in the moment never had.

The specific, non-obvious claim underneath the format: blamelessness makes people more accountable, not less. This is not merely a tone preference — removing the incentive to hide, minimize, or omit details out of fear of personal consequence is what makes someone willing to actually describe what happened, including the parts that don't reflect well on their own judgment in the moment. A postmortem culture where admitting a mistake carries real personal risk systematically produces incomplete accounts, not because people are dishonest, but because self-preservation under any blame-carrying system quietly edits the story before anyone consciously decides to. Google's SRE book later codified the same practice, and the term became standard industry vocabulary — but the mechanism it's built on is older and more specific than "be nice about mistakes."

Why the format alone doesn't produce working action items

A postmortem document full of remediation ideas, with no named owner and no due date on any of them, is functionally a list nobody will revisit — this is the most common failure mode even in teams that have genuinely adopted blameless language and culture correctly. Blamelessness fixes whether people tell you what happened; it does nothing, by itself, to fix whether the ideas that come out of that discussion turn into tracked, owned, completed work.

One practice worth considering: don't try to finalize specific action items in the heat of the postmortem meeting itself. Some teams capture ideas during the discussion, then turn the strongest few into tracked tickets in a separate follow-up step, after participants have had time to digest what was discussed, rather than while everyone is still processing an incident that may have ended only hours earlier.

The discipline that matters: a short list, each item with one named owner and a real due date — not fifteen loosely-described ideas with no accountability structure at all. "Three to five" is a common rule of thumb rather than a researched number; the point is that each item is small enough to own and important enough to finish. A shorter, owned, dated list that's actually tracked to completion produces more real change than a long, thorough, untracked one — the value of a postmortem isn't the length or thoroughness of its writeup, it's whether anything downstream of it measurably changes, and a list with no owner and no deadline has already failed that test before anyone even reads it.

Contributing factors, not a root cause, and measuring what actually improves

Complex-system incidents rarely have a single root cause. An outage usually needs several things to line up at once. For example:

• a config change that wasn't validated;
• a canary too small to catch the problem;
• an alert routed to a team that was asleep;
• a runbook that pointed at a dashboard that no longer exists.

Each one was a contributing factor, and removing any one of them would have made the incident smaller or prevented it. Asking "what was the root cause?" pushes the review to stop at the first plausible answer, usually the most recent human action, and to miss the rest. "5 whys" has the same weakness when it's followed as a single chain. Ask "what made this possible, and what made it worse?" and list every factor.

MTTR is a weak measure of how good incident response is. The VOID report (an analysis of thousands of public incident reports) found that incident durations are heavily skewed. A handful of very long incidents dominate the mean, so MTTR moves randomly from quarter to quarter whether or not anything really improved. DORA's 2023 report changed its own metric to failed deployment recovery time, which covers only recovery from a bad change. More useful signals:

• Time to detect and time to mitigate, looked at per incident, not as an average.
• How many incidents users reported before your alerts did.
• Repeat incidents with the same contributing factors.
• Action-item completion: the share of postmortem items closed by their due date.

Close the loop on action items. Track them in the same system as other engineering work, not in the postmortem document. Review open items in a regular operations review, and expect a reason when one slips. Look for themes across incidents. "Five incidents this quarter where a config change skipped validation" is a much stronger case for investment than any single postmortem can make.

How to say it in the interview

"Adopting blameless LANGUAGE in a postmortem meeting is not the same as producing action items that actually get done - a document full of well-intentioned remediation ideas with no named owner and no due date is functionally a list nobody will revisit, no matter how blame-free the discussion that produced it was. The format fixes whether people tell you what really happened; it doesn't automatically fix what happens to the ideas that come out of that discussion."

Checklist

• Understood blamelessness is claimed to increase accountability, not decrease it, by removing the incentive to hide details
• Sought the 'Second Story' — why an action made sense to the person at the time, given what they knew — rather than assigning fault with hindsight
• Recognized that adopting blameless language doesn't automatically produce action items that get done
• Considered capturing ideas during the postmortem meeting and finalizing specific action items in a separate follow-up step
• Limited action items to a short list, each with a named owner and a real due date
• Listed every contributing factor instead of stopping at a single 'root cause'
• Measured detection, mitigation, repeats and action-item completion rather than relying on MTTR alone

Related lessons

• Running an Incident: Roles, Communication, and Not Making It Worse