The first story is usually too simple
Right after an incident, everyone wants the clean sentence: deploy broke checkout. Human clicked wrong button. Alert was missed. Those may be true, but they are rarely enough. The useful question is: why did that action make sense at the time?
A timeline is evidence, not a blame map.
Leadership bugs are system bugs too. Pull context out and the team graph starts wobbling.
Blameless does not mean consequence-free
Blameless means you investigate without making people hide details to survive the meeting. It does not mean shrugging. You can be kind to people and ruthless about weak signals, risky defaults, confusing tools, and missing guardrails.
Replace "who caused this?" with "what made this easy to do and hard to catch?"review prompt
Actions should change the system
Training everyone to be more careful is usually a weak action item. Stronger actions alter the path: add an automated check, change the deploy order, page the right owner, make rollback one command, or remove the confusing option.
Good action items are specific enough to close.
Flip the switches and watch the story turn into a tiny operating model.
A review should be useful six months later
Future engineers will not remember the meeting. They will find the doc during a similar outage. Write for them: impact, timeline, contributing factors, detection gaps, what changed, and how to tell if it worked.