DEV Community

Hive80-lab
Hive80-lab

Posted on Originally published at hive80-lab.github.io

Blameless Post-Incident Reviews: Find Causes, Not Culprits (45-Minute Template)

Every small team runs the same review the first time: someone asks "who pushed this?", the room goes quiet, and the person who did it learns that the safe move next time is silence. Then the incident repeats in six weeks wearing a different costume. The blame reflex feels like accountability and works like a leak.

Blameless is not softer accountability — it is stronger. People do not cause outages; paths that let one keystroke reach production do. The review's job is to interrogate the path.

Here is the 45-minute version that fits any team under 50:

The 72-hour clock. Schedule within 72 hours of resolution — sooner and responders are still fried, later and the timeline is archaeology. Forty-five minutes, hard stop: 10 for the timeline read-back, 20 for the four questions, 10 for actions, 5 for "what would have made it smaller."

Who is in the room. A facilitator (run the clock, protect the quietest voice), every responder including the ten-minute one (they often saw the turning point), one outsider whose only job is asking "why was that normal?", and a scribe sharing the screen. No manager as interrogator — a review where the boss asks the questions produces polished answers, not true ones.

The timeline table. One pass, one shared screen, with detection latency as its own column. Most small-team reviews discover the biggest lever was noticing, not fixing.

The four questions. What happened? Why — kept asking until you hit a system property, not a person? What caught it, and how late? What would have made it smaller — not prevented, smaller. Smaller ships this month; prevented is a wish.

Contributing factors, not root cause. The single-root-cause hunt is blame with a spreadsheet. Real incidents are layered: a config change, a missing staging guard, an alert that fires late, a rotation where one person carries four systems. Fewer than three factors means the room stopped early.

The five-action cap. Reviews that end with fifteen actions end with zero shipped. Five, each with an owner, a date inside two weeks, and a "smallest version that ships" definition. Document changes (runbook lines, alert text, checklist rows) ship same week — documentation is the fastest durability you can buy.

The five blame traps, each with a rewrite:

  • The name — "Sam broke it" → "the deploy path allowed one keystroke to reach production."
  • The adjective — "a careless mistake" → "a mistake the system permitted to be invisible until checkout broke." Careless is a mood, not a cause.
  • The counterfactual trial — "if you'd just checked" → "what makes the check the default instead of the discipline?" Discipline doesn't scale; defaults do.
  • The hero story — "at least Dana stayed up all night" → "what made a midnight hero the plan?" Heroics are load-bearing evidence of an automation gap.
  • The review-as-verdict — "so who owns this mess?" → "who owns the action?" Ownership attaches to forward work, never to punishment.

Ground rules at minute zero: everyone did something reasonable with the information they had; nothing said here appears in a performance review — enforced, not aspirational; "I don't know" is free; critique systems, never names. If your team can't honestly hold rule two, don't run the review yet — blameless theater that feeds a PIP at year end burns the trust the next real review needs.

Three metrics that keep it honest: action completion at 30 days (target 80%+), repeat-incident rate for the same factor within 90 days, and detection latency trend — if minutes-to-notice isn't falling across reviews, your actions are all guards and no sensors.

Worked example: an eight-person fintech, config typo in a Friday 17:40 deploy, checkout down 61 minutes. The draft review was one line long: "Sam merged on a Friday, Sam owns this." The blameless version found four system factors — no staging guard on config changes, a fifteen-minute alert threshold, a freeze calendar that excluded "config-only" deploys, and a review culture where skipping a second pair of eyes was normal at 17:30. Three guards shipped that month. Six months later: zero repeat config incidents, and nobody needed a remediation conversation about a person.

Full template with the worked example and the timeline table: Blameless Post-Incident Review Template — HIVE80lab Ops Notes. It pairs with the incident post-mortem template (the document) and the incident severity matrix (the labels that decide what a response costs).

Score your incident response before the next incident: the free IR Readiness Score is twelve questions across the five IR pillars and returns a tiered fix-first plan in two minutes. If the result says your reviews are the gap: the Ops Starter Kit ($14) has the meeting cards and the post-mortem doc; the Ops Mega Bundle ($29) collects all five kits. Want an outside pair to facilitate your first reviews and hand back a prioritized fix plan? That's the Small-Team Ops Audit ($149, five days), and when the findings point at missing runbooks, the Custom Incident Runbook ($249, 48 hours) turns them into procedure.

Top comments (0)