Blameless Postmortems: Language for Learning Without Blame
5 exercises on postmortem key phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
When writing a postmortem, how should you describe what caused the incident?
CONTRIBUTING FACTORS: The phrase "The contributing factors were..." shifts focus from individuals to systemic conditions. It invites multiple causes and prevents blame. Examples: "The contributing factors were: no automatic rollback on error spike, alert thresholds set too high, and runbook out of date." / "Contributing factors included: unclear ownership of the config file, no staging environment parity, and insufficient monitoring." / "The contributing factors were a combination of time pressure from the release deadline and gaps in our on-call rotation." Options A/C/D name or imply individual blame, which makes postmortems less honest and psychologically unsafe for contributors.
2 / 5
You're presenting the sequence of events at the postmortem. Which opening is most professional?
TIMELINE LANGUAGE: "The timeline shows:" followed by timestamped events is the standard postmortem format used at Google, Atlassian, and most engineering organisations. It's factual, precise, and keeps the narrative grounded in data. Examples: "The timeline shows: 09:00 config change merged; 09:04 latency increased 40%; 09:12 page triggered." / "The timeline shows feature flag enabled at 16:30, first customer report at 16:38, rollback completed at 16:52." / "Timeline: 22:00 cron job ran; 22:01 DB CPU hit 100%; 22:03 primary failover triggered." Options A/B/C are informal and lack the precision needed for a formal postmortem document.
3 / 5
A junior engineer is afraid they'll be blamed. What framing do you use in the postmortem?
SYSTEM FAILURE FRAMING: "This was a system failure, not a human failure" is the cornerstone phrase of blameless postmortems, popularised by Google SRE and Etsy engineering. It acknowledges that humans operate within imperfect systems. Examples: "This was a system failure — our CI pipeline should have caught this before it reached production." / "We don't blame individuals. This is a system failure: our alerts didn't fire early enough." / "System failure: the deployment tool had no guardrail to prevent this class of change." Option B dismisses the issue, C is sympathetic but not systemic, D is the opposite of blameless culture.
4 / 5
How do you present action items at the end of a postmortem?
FRAMING ACTION ITEMS: Postmortem action items need specific ownership, due dates, and tie back to the contributing factors. The format "(1) Action — owner: X, due: date" makes follow-through accountable. Examples: "Action: Increase alert sensitivity on payment errors. Owner: SRE, due: next sprint." / "Action: Add staging parity for config changes. Owner: DevOps, due: 2024-02-15." / "Action: Document the on-call escalation path. Owner: Ana. Due: end of month." Options A/D are vague with no ownership, option B reverts to individual blame rather than process improvement.
5 / 5
How do you close the postmortem learning section?
WHAT DID WE LEARN: The "What did we learn?" section should name specific systemic improvements, not personal lessons or superstitions. Examples: "What did we learn? Our feature flag system has no gradual rollout capability — we need to build that." / "What did we learn? We lack observability into the connection pool state. Adding metrics is now a P1." / "What did we learn? The incident declaration threshold is too high — we were firefighting for 20 minutes before declaring." Option A is wishful thinking, C is blame-adjacent, D is a folk heuristic, not a systemic insight.