Engineering Practice
Postmortems: multiple-choice review
Crux Multiple-choice synthesis across the postmortems unit — blameless culture, contributing factors vs single root cause, action-item quality, the five-whys critique, and learning culture.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a judgement call you make in a real retro — not a definition to recite, but the difference between fixing a system and blaming a person.
Goal
Confirm you can separate blame from systemic analysis: why blameless is an information decision, why complex failures are multi-causal, what makes an action item real, and where the five-whys habit fails.
Quiz
Completed
A team has a remarkably clean incident history — almost no sev1 postmortems filed in a year. A new SRE lead reads this as a warning sign. Why?
Heads-up Maybe — but a senior reads a suspiciously clean history as a smell, not a trophy. Reported incidents drop under blame long before real incidents do; the absence of postmortems is evidence about reporting, not reliability.
Heads-up Possible but not the primary read. The classic cause of an artificially clean history is cultural — fear of blame keeps incidents off the record — not a tooling gap. Both warrant a look, but blame is the named failure mode here.
Heads-up That is the trap. A history with zero reported sev1s in a complex system is itself the anomaly worth investigating — it usually means the organization has made reporting feel dangerous.
Quiz
Completed
A retro concludes: 'Root cause: engineer pushed an untested config. Action: added a deploy checklist.' What is the strongest senior critique?
Heads-up A checklist can be a perfectly good action item. The defect is stopping at a single human root cause and ignoring the systemic conditions, not the checklist itself.
Heads-up Five-whys reinforces the single-root-cause model and, per Allspaw's Infinite Hows, drags the room toward hindsight bias and blame. The fix is asking 'how' to surface multiple contributing conditions, not drilling for one deeper cause.
Heads-up Quantified impact matters, but the headline flaw is the framing: 'engineer pushed' pins it on a person and 'added a checklist' treats a single root cause as solved while the real contributing factors stay in place.
Quiz
Completed
Two proposed action items: (A) 'The team should be more careful when deploying.' (B) 'Add a staging smoke test that exercises the payment config path; owner Mara; due 2026-06-15.' Why is only B a real action item?
Heads-up Intent is not an action item. 'Be more careful' cannot be assigned, tracked, or verified done — it is exactly the kind of non-item that lets a retro feel productive while changing nothing.
Heads-up An owner is accountability for the fix, not blame for the incident. Blameless covers cause analysis; action items still need one named person or they drift unowned and never ship.
Heads-up A team-wide exhortation scales to nobody. An item owned by everyone is owned by no one; the per-item single owner is what makes follow-through trackable.
Quiz
Completed
Allspaw's 'Infinite Hows' argues for asking 'how' instead of 'why' in an investigation. What is the mechanism behind that preference?
Heads-up Tone is a side effect, not the mechanism. The substantive difference is that 'how' surfaces the conditions and tradeoffs behind a decision, while 'why' interrogates a person for a justification.
Heads-up The opposite. 'How' deliberately resists the single-root-cause model and reveals multiple interacting contributing factors; collapsing to one cause is the failure Allspaw is warning against.
Heads-up This is an epistemics and culture argument from Dekker and Leveson, not a compliance rule. The point is that 'why' embeds hindsight bias and blame, regardless of regulation.
Quiz
Completed
A team writes thorough postmortems but ships under 40% of action items within 90 days; the same class of outage recurs. What does the unit say this combination means?
Heads-up Document length is not the lever. The failure is follow-through: items written and filed but never shipped. The document is the cheap part; the value is the work it commits you to.
Heads-up Sub-50% completion is a reported industry norm, but the unit treats it as the central failure to fix, not an acceptable baseline. The senior target is well above 85% with 30/60/90-day tracking.
Heads-up The fix is to protect follow-through — severity-trigger the ceremony, give each item a single owner and due date, track to closure — not to abandon the practice that surfaces the contributing factors.
Quiz
Completed
Your org wants a full postmortem for every production hiccup, including transient blips that self-resolve in seconds. What is the senior position on this policy?
Heads-up Retros are expensive in engineer time and review meetings. A full postmortem for every transient blip burns the budget that should go to following the sev1 items to closure. You ration which incidents earn a full retro.
Heads-up Too rigid. The trigger is set by severity and customer impact — often sev1/sev2, an SLO breach, or downtime past a threshold — not a hard sev1-only line. The point is a deliberate threshold, not a single fixed bar.
Heads-up Ad-hoc per-engineer judgement produces inconsistent coverage and lets the inconvenient incidents slip. A team-level severity trigger is what makes the policy fair and predictable.
Recap
The through-line of the unit is one stance: failure is data about the system, not evidence against a person. A clean incident history can signal suppressed reporting; a single human root cause hides the multi-causal reality; a real action item is specific, owned, and dated; asking ‘how’ beats asking ‘why’ because it surfaces conditions instead of culprits; and the whole ceremony only pays off if you ration it with a severity trigger and track items to closure well above 85%.