postmortem-writing

Postmortem Writing - Incident Retrospective Writing Guide

Skill Overview

Postmortem Writing is a specialized skill for writing no-blame incident retrospective documents. It provides root-cause analysis methods, a timeline template, and an action-item framework to help teams learn from failures and prevent similar incidents from happening again.

Applicable Scenarios

Post-incident retrospectives: When the production environment experiences SEV1/SEV2-level incidents, service interruptions lasting more than 15 minutes, or any data loss, use this skill to systematically write an incident retrospective document.

Retrospective meeting facilitation: When you need to organize and lead a no-blame retrospective meeting, the skill provides meeting structure, facilitation techniques, and discussion frameworks to keep the meeting focused on system improvements rather than individual accountability.

Building a retrospective culture: When a team wants to establish or improve a retrospective culture and define retrospective process standards, the skill offers best practices, templates, and anti-pattern warnings.

Core Functions

Structured retrospective template: Provides a standard incident retrospective document template, including an executive summary, detailed timeline, root-cause analysis (5 Whys), detection and response evaluation, impact analysis, and action-item tracking—complete with all major modules.

No-blame culture framework: Helps teams build psychological safety and encourage information sharing and organizational learning by contrasting blame-oriented and no-blame-oriented ways of thinking.

Root-cause analysis tools: Integrates the 5 Whys method and system diagram visualization to guide teams in digging into the underlying causes of incidents, identifying systemic flaws rather than individual mistakes.

Common Questions

What is a no-blame retrospective?

A no-blame retrospective is an incident analysis philosophy. The core idea is to attribute the problem to systemic defects rather than individual errors. By asking “what conditions allowed this issue to happen” instead of “who caused this issue,” it encourages candid communication, sharing lessons learned, and improving system safeguards.

How do you use 5 Whys for root-cause analysis?

The 5 Whys method involves continuously asking “why” five times until the root cause is found. For example: service failure → database connection exhaustion → every request opens a new connection → the code bypasses the connection pool → the developer is unfamiliar with the code pattern → lack of connection management documentation. The resulting improvement actions are to add documentation and tests.

How do you ensure retrospective action items get followed through?

Effective action-item management requires four elements: clear priority (P0/P1/P2), specific owners, verifiable deliverables, and deadlines. It’s recommended to record action items in the ticketing system to track completion status, and to review patterns across incidents at the quarterly level to identify opportunities for systemic improvements.