The blameless postmortem that actually finds the cause, not the safest summary

Every engineering org with more than 20 people now runs blameless postmortems. The norm is settled. People show up, the conversation is non-accusatory, the doc gets written up after, the action items are filed.

The doc, in too many cases, says "monitoring gap, alerting threshold needs review, runbook needs update." Three weeks later, a similar incident happens, the postmortem says the same things, and the team has the uncomfortable feeling that they're learning the same lesson on a loop.

Blameless culture is a real prerequisite for good postmortems. People will tell you what actually happened only if they're not worried about being individually blamed for it. That part of the practice is doing its job. But blameless and vague are not the same thing, and the postmortems that go vague aren't safer, they're emptier.

The pattern of a postmortem that finds the actual cause looks different from the pattern of one that doesn't.

The first move is to collect contributions before the postmortem meeting, not in it. Every responder, every engineer who touched the incident, every PM who fielded the customer complaint, writes their account async within 24 hours. Memory degrades fast, especially in the first 72 hours after an incident, and the postmortem meeting that happens a week later is reasoning from already-faded recall. The contemporary record, written down while it's still fresh, is what surfaces the specific Slack message at 2:43am, the specific config diff that wasn't reviewed, the specific assumption about the upstream service. "Monitoring gap" doesn't survive the specificity of three engineers each describing what they actually saw on their console at 2:43am.

The second move is to insist on five-whys against the specific things, not the general ones. Not "why did we have a monitoring gap." "Why did the threshold on the queue-depth alert get set to 10,000 in 2022, and why did we not revisit it when the service handled 5x that traffic in 2024." The vague version produces "we should review alerts." The specific version produces "the platform team needs an annual alert-threshold review tied to traffic growth, owned by the SRE lead, due Q1."

The third is to separate the cause-finding from the action-deciding. The retro that does both at once tends to settle on action items that are easy to write, not action items that match the actual cause. Surface the contributing factors fully, then on a separate pass decide which two or three to invest in fixing. Most postmortems try to do both in the same hour and end up doing neither well.

Blameless culture says "tell me what happened without fear." The discipline of writing contributions async, before the live session, is what makes that possible at scale, because every responder gets to write what they saw without the room watching them say it. The live meeting then synthesises, prioritises, and commits. The doc that comes out of that meeting is the one that doesn't repeat itself three weeks later.

If your team's last postmortem ended with "better monitoring" or "better runbooks," the test is whether anyone has touched either of them in the eight weeks since. If not, the meeting found a placeholder, not a cause.