Writing postmortems

REQUIRED BACKGROUND: the technical-writing skill (hard rules, truth rules, style).

Overview

Audience: the engineer who hits something similar in a year, not the people in the room. Core principle: facts from evidence, causes from mechanisms, lessons from both, and no names. Classification: historical; once reviewed it is immutable, and corrections are dated addenda.

When to invoke, and not

Invoke after an incident is resolved, or at a stable milestone of a long one. A defect that reached users and a near miss (a guard caught what review missed) earn the same write-up. Do NOT invoke during the live incident: the runbook governs that. Not for assigning accountability: a postmortem that needs a person's name to make sense is describing a process hole. Not for a status update to stakeholders, which is a report.

Skeleton

# [System]: [the failure, as its symptom, one line]