postmortem-review-boardlisted

# Postmortem review board One postmortem closes one incident. A board exists to see what a single document cannot: the third outage this quarter with the same trigger, the action items filed and never shipped, the failure class spreading quietly between teams. Without it, each team learns its lesson alone and the organization pays for the same lesson again at a higher price. ## Method 1. **Gate entry on severity and impact, never on volunteering.** Every SEV1 and SEV2, plus any incident above a stated customer or revenue threshold, comes to the board. Route lower severities to team-local review so the board reads the incidents that carry org-wide signal instead of drowning in all of them. 2. **Grade against a written rubric before the discussion starts.** A pass needs a real timeline, a root cause that survives "five whys" past the first human in the chain, contributing factors, and action items with named owners and dates. "Operator error" is where the analysis quit, not a root cause. Bounce failing writeups instead of workshopping them live. 3. **Keep it blameless, out loud and every time.** The board judges the system and the writeup, never the responder. The first review that turns into a tribunal is the last honest postmortem you get: the next one arrives sanitized, and sanitized postmortems are the board's blind spot. 4. **Split team-local fixes from cross-cutting actions.** For each incident, ask whether the remedy protects only the