BitBootcampBitBootcamp ← all explainers 🔄 Review ⚙ Settings

Drill 31 — The Postmortem That Named Names

Theme: People & Process · Format: 20-min drill or 60-min tabletop · Difficulty: advanced

The story

A painful outage; the postmortem identifies that an engineer skipped a verification step. The document says so, with the name. In the review meeting, leadership asks the engineer pointed questions; the engineer apologizes. The action item: "engineer will be more careful; team will remember to double-check." Everyone leaves feeling accountability was served.

⏸ Stop here and ask the room: predict this team's incident statistics for the next two quarters.

Run it — facilitator script

Timing: 2 min story · 10 min questions · 3 min reveal · 5 min transfer. As a 60-min tabletop: extend the third question into a full rewrite exercise — hand out a (fictional) blameful postmortem and have the room produce the blameless version, action items and all.

Facilitator caution: this drill can get personal. Keep every example fictional — and if the room starts relitigating a real internal incident with real names attached, stop it immediately and redirect: same shape, different story, no names. The drill is about the mechanism, and it only works if nobody in the room is defending themselves.

The stop question is a prediction exercise — insist on actual predictions (incident count up or down? near-miss reports up or down?) before revealing. The counterintuitive answer is that reported incidents may briefly look better, which is exactly the poison.

"What did every observer in that meeting learn about reporting their own mistakes?"

Listen for: the observer's-eye view — the meeting was attended by twenty people and only one was named, but all twenty updated their behavior: visibility of your mistakes gets you interrogated by leadership. Strong answers connect this to sensor loss — the team just muted its own error-detection network.

Weak signal: "they learned to double-check" — that's the lesson leadership intended to send; the drill is about the one actually received.

"What's the difference between accountability and blame?"

Listen for: accountability is owning the system's response — the named engineer can be accountable for driving the fix, the team accountable for adding the guard; blame is assigning the outage to a person's character and stopping the analysis there. A crisp test: does the "accountability" produce a control that works when this engineer is on vacation?

Weak signal: "blameless means no consequences" — blameless postmortems are compatible with performance management; they're incompatible with using the postmortem as performance management. If the room conflates the two, spend time here.

"Rewrite the action item so it would survive the engineer leaving the company."

Listen for: systemic rewrites — the skipped verification step becomes automatic (a pipeline gate, a required field, a default), with an owner and a due date. Push for the reasonableness question: what made skipping the step seem reasonable that day? The answer (time pressure, a flaky check everyone skips, unclear ownership) is where the real action item lives.

Weak signal: "add the step to the checklist" or "training" — memory and vigilance are the components that just failed; a control that consists of remembering harder isn't one.

The reveal

Near-miss reports drop to zero — not because near-misses stopped. Two quarters later, a major incident arrives with two precursor events that people had noticed and not reported. The blameful postmortem didn't reduce errors; it reduced error visibility.

Why this happens — the mechanics

Blame optimizes for information suppression. Error reporting is voluntary — near-misses in particular are known only to the person who almost caused them — so the reporting rate is set by one question: what happened to the last person who was visible? After a naming-and-shaming, each individual's rational move is silence, and the organization loses its only sensor network for problems that haven't exploded yet. Psychological safety — the shared belief that reporting won't be punished — isn't a soft perk here; it's the operating condition of the sensor.

The seduction of blame is that it's cheap and it feels like closure. A name is a satisfying root cause: the investigation can stop, the fix is an apology, and the org chart doesn't have to change. Systemic analysis is harder — it has to ask what made skipping the step seem reasonable? and follow the answer into time pressure, flaky checks, and ambiguous ownership, which usually implicates decisions made well above the named engineer. "Human error" as a conclusion is where an investigation stops; in mature safety cultures it's where the investigation starts.

Aviation learned this the expensive way. The Aviation Safety Reporting System (ASRS) — run by NASA (the National Aeronautics and Space Administration), deliberately independent of the regulator — grants reporting pilots limited immunity precisely because the industry concluded that knowing about near-misses is worth more than punishing them. Tens of thousands of reports a year feed fixes to procedures, cockpit design, and airspace — that reporting flow is a large part of why commercial aviation is as safe as it is. The blameful postmortem makes the opposite trade: one moment of accountability theater, purchased with the next two quarters of blindness.

Diagrams

Problem — how the failure unfolds:

timeline
    title Two quarters after the postmortem that named names
    section Quarter 1
        Week 1 : Postmortem names the engineer : Pointed questions in review
        Week 2 : Action item - be more careful : Observers learn the real rule
        Rest of quarter : Near-miss reports drop to zero
    section Quarter 2
        Mid-quarter : Two precursor events noticed : Neither one is reported
        Quarter end : Major incident arrives : Blame cut error visibility

Solution — where the guardrails go:

flowchart TD
    A["Painful outage"] --> B["Blameless postmortem: what<br/>made the action seem<br/>reasonable?"]
    B --> C["Systemic action items:<br/>guards, checks, defaults —<br/>each with an owner"]
    C --> D["Skipped verification step<br/>becomes automatic, not a<br/>memory task"]
    B --> E["Protected near-miss<br/>reporting channel"]
    E -.-> F["Near-miss volume tracked<br/>as a health metric"]
    F -.-> G["Precursor events surface<br/>while they are still cheap"]
    G --> H["Fixes land before the<br/>major incident can form"]

What good looks like

The lesson

Blameless isn't softness — it's instrumentation. Humans are the only sensors that can detect near-misses, and blame turns those sensors off. Postmortems ask "what made this action seem reasonable?" and produce systemic action items (guards, checks, defaults) — "be more careful" is not a control. Aviation figured this out decades ago; their near-miss reporting system is why planes are safe.

Named concepts: blameless postmortems, psychological safety as a reliability control, near-miss reporting, systemic vs. personal action items.

Real-world echoes

Transfer

How many near-misses were reported last quarter? Zero is the worst possible number — it means the reporting channel is dead, not that nothing almost happened.

Make it a ticket: rewrite last quarter's postmortem action items so each one is a guard, check, or default with an owner — delete every "be more careful" — and stand up the protected near-miss channel with a two-minute reporting path and a weekly triage slot.

Related