Writing Incident Postmortems People Actually Read

Most postmortem templates optimize for completeness — every timestamp, every log line, every person involved. That thoroughness is exactly why nobody except the author reads the document twice. A postmortem that actually changes future behavior needs a different structure entirely.

• Lead with impact and timeline in three sentences — the reader decides in ten seconds whether this matters to them.
• Blameless language, always — 'the deploy process allowed X' not 'engineer Y deployed without checking Z.'
• Action items need an owner and a date, not a vague 'we should look into monitoring this better.'
• Track whether past action items actually got done — an incident review process with no follow-through teaches the team that postmortems don't matter.

The postmortems I've seen actually prevent repeat incidents share one trait: they're short enough that the whole team reads them, and specific enough that the action items get done instead of quietly dropped at the next sprint planning.

A postmortem nobody reads twice didn't prevent the next incident. It just documented this one.