Modern QA2026Blameless Post-Mortems — tiles
Log inJoin
20 / 51 · 24 Technical Writing for QA · Root Cause Analysis← prev⊞ allnext →☰ Read as one page

3.4Blameless Post-Mortems

Language That Focuses on Systems, Not People

The single most important principle of blameless post-mortems is this: people do not cause incidents; systems allow incidents to happen. When someone makes a mistake, the question is not "why did they do that?" but "why did the system make it easy to make that mistake and hard to catch it?"

Blaming Language Blameless Language
"Alice forgot to add the index" "The migration that should have added the index failed silently"
"Bob deployed without testing" "The deployment process did not include a mandatory test verification step"
"The developer wrote a bad query" "The query was not tested against production-scale data volumes"
"QA missed this bug" "Our test coverage did not include this scenario"
"The on-call engineer was slow to respond" "The alert routing did not reach the on-call engineer's phone"

How to Facilitate a Blameless Post-Mortem

  1. Set the tone at the start. "This meeting is about learning and improving, not assigning blame. We assume everyone involved made the best decisions they could with the information they had."
  2. Focus on the timeline. Walk through what happened chronologically. Facts first, analysis second.
  3. Ask "what" and "how," not "who." "What made it possible for this to happen?" not "Who caused this?"
  4. Celebrate the response. Acknowledge what went well during the incident response, not just what went wrong.
  5. End with actions, not judgments. Every corrective action should change a system or process, not punish a person.