Blameless postmortems were meant to remove fear so that facts could surface. In a lot of organisations they have instead removed the facts.

Specific about actions, curious about systems

"A configuration change was applied" hides the useful detail. "An engineer applied a config change from a runbook that had been correct for the previous cluster version" is specific, blames nobody, and points straight at the actual defect: the runbook had no version and no owner.

The question is never why the person did it. It is why it was reasonable at the time, given what they could see.

Making them worth the hour

• Assign every action item an owner and a date, and review the list monthly. Unowned items are notes, not commitments.
• Record what made detection slow, separately from what caused the fault. They usually have different fixes.
• Publish them internally. A postmortem read by one team is a fifth of the value.