Conduct a blameless incident post-mortem

Blameless Post-Mortems: The System, Not the Person

The quality of your post-mortems determines whether the team runs toward signals or hides from them. Atlassian's incident management writing and Google re:Work's psychological safety research both make the same argument: blameful post-mortems train engineers to under-report near-misses, which erodes the data you need to prevent the next incident. The framing discipline — "the system, not the person" — is the load-bearing norm.

How the Conduct a blameless incident post-mortem Prompt Works

The prompt reconstructs the timeline first (MTTD/MTTA/MTTR metrics that are measurable), lists contributing factors across five categories rather than searching for a single root cause, and enforces blameless rewriting so the doc cannot name individuals. The "action we'd have had to take 6 months ago" output surfaces latent technical debt that normally escapes post-mortem action items.

When to Use It

• A production incident just happened.
• Post-mortem culture has decayed into blame.
• MTTR is rising and nobody knows why.
• A new engineering leader wants to reset incident hygiene.
• Customers are asking for a post-mortem you can share publicly.

Common Pitfalls

• Single root cause. Incidents almost never have one root cause. Listing contributing factors across categories produces better prevention.
• Blameless in theory, blaming in tone. Re-read the doc and strip any language a reasonable reader would infer as personal blame.
• Action items without owners or dates. Unowned action items are documentation theater. Name the person and the date.

Sources

• Agile Metrics — Atlassian
• Google re:Work — Google
• The Pragmatic Engineer — Gergely Orosz
• Begin with Trust — Harvard Business Review