Write Blameless Postmortems

Guides writing blameless postmortems: documents that analyze an incident to drive organizational learning rather than assign blame. The core reframe is procedural: instead of asking "who caused this," it asks "what conditions allowed this," trading punishing individuals for improving systems and trading hidden information for shared learnings and psychological safety. It defines concrete triggers for writing one: SEV1/SEV2 incidents, customer-facing outages over 15 minutes, data loss or security incidents, near-misses that could have been severe, novel failure modes, or any incident that needed unusual intervention.

It ships three ready-to-use templates. The Standard Postmortem template covers an executive summary, a UTC timeline, root cause analysis (including a "5 Whys" drill-down and a proximate-cause-plus-contributing-factors breakdown), detection and response sections (what worked, what did not), customer/business/technical impact, lessons learned (what went well, what went wrong, where the team got lucky), a prioritized action-item table with owners and due dates, and an appendix for supporting graphs and related incidents. A dedicated 5 Whys Analysis template walks through each "why" with its answer and supporting evidence, such as a metric reading, a code diff, or a pull request reference, ending in primary, secondary and tertiary root causes mapped to systemic improvements typed as prevention, detection or mitigation. A Quick Postmortem template compresses the same discipline, what happened, timeline, root cause, fix, lessons, for minor, SEV3-level incidents that do not warrant the full document.

A facilitation guide scripts a 60-minute postmortem meeting: a 5-minute opening that resets the blameless norm ("we're here to learn, not to blame"), 15 minutes walking the timeline chronologically, 20 minutes of analysis discussion (what failed, why, what conditions allowed it, what would have prevented it), 15 minutes brainstorming and prioritizing action items with owners and due dates, and a 5-minute close confirming owners and any follow-up. It also lists a recommended postmortem cadence (draft within 1-2 days, meeting by day 3-5, document finalized and tickets created by day 5-7, action items tracked over the following weeks, patterns reviewed quarterly), a table of anti-patterns to avoid paired with the better approach for each: focus on systems instead of playing the blame game, ask "why" five times instead of a shallow one-pass analysis, scope actions to what is achievable instead of leaving unrealistic ones that never get done, and track actions in a ticketing system instead of letting a meeting produce no follow-up at all; and paired do's and don'ts: start immediately since memory fades fast, be specific with times and errors, include graphs, assign owners, share widely; never name and shame, never skip small incidents since they reveal patterns, never turn it into a blame document or busywork, never skip verifying that actions were completed.

Use it for conducting post-incident reviews, drafting the postmortem document itself, facilitating the blameless review meeting, identifying root causes and contributing factors, and turning findings into actionable, owned follow-up items. Skip it for anything unrelated to postmortem writing or outside this domain; deeper worked examples live in resources/implementation-playbook.md when the built-in templates are not detailed enough.

Input is the incident itself: its timeline, metrics, and the team's account of what happened and why. Output is a filled-in postmortem document, standard, 5-whys, or quick form depending on severity, a facilitated meeting agenda, and a prioritized, owned action-item list intended to feed a ticketing system.

References external reading rather than a live integration: Google's SRE postmortem-culture writeup, Etsy's blameless-postmortems post, and PagerDuty's postmortem guide, plus the skill's own resources/implementation-playbook.md for deeper examples.

Engineers, on-call responders, and SRE or engineering leads who need to run a post-incident review, write up what happened, and turn it into systemic fixes rather than individual blame, especially teams building or maturing a blameless incident-review culture.