Run the review in four parts: agree the facts from a written timeline, discuss contributing causes, decide on a small set of fixes with named owners, and close with what went well. Circulate the draft first, keep the room blame free, and check actions later. An hour is usually enough.
Before the meeting
Google's postmortem chapter says a postmortem is a written record: the incident, its impact, the mitigation steps, the root causes and the follow-up actions. Write that draft before the meeting, not in it.
- Build the timeline from logs and chat, not from memory.
- Collect impact: who and what was affected, for how long.
- Invite the responders and the owners of affected systems.
- Send the draft a day ahead and ask for corrections.
The chapter also says triggers should be defined before incidents, for example user visible degradation, data loss, on-call intervention or long resolution times. Then nobody debates whether a review is warranted.
The agenda
- Set the frame (two minutes). Say that the aim is contributing causes without indicting any individual or team.
- Walk the timeline (ten minutes). Correct facts only.
- Contributing causes (twenty minutes). Ask how, not who. Use the question set from the human error post.
- Actions (fifteen minutes). Limit to what the team can really finish. Each item has an owner and a date.
- What went well (five minutes). Name practices to keep.
- Wrap up (three minutes). Agree where the final write-up lives.
These timings are suggestions of ours, not from the source.
Facilitation tips
- Pick a facilitator who was not the incident commander.
- Redirect "you should have" to "what would have made that easier".
- Write down parking lot items rather than debating them.
- Let quiet people speak. Ask them directly, kindly.
After the meeting
The chapter says an unreviewed postmortem might as well never have existed, and that outcomes should be shared widely and easy to find. Publish the write-up internally and put the follow-up on a board that someone checks.
When the meeting goes wrong
If voices rise or someone gets defensive, pause and restate the purpose. If a senior person starts assigning fault, the facilitator should step in gently and redirect to the system question. If that fails, take it offline afterwards.
If the meeting runs over, stop, record the open questions, and schedule a short follow up instead of rushing through actions. Rushed actions tend to be vague, and vague actions never get done. A short, well attended follow up is better than a long, exhausted one.
Quick check
Should leaders attend?
Yes, as listeners. The chapter says senior management participation shows support for the culture. They should not use the meeting to assign fault.
Sources
Last reviewed: 19 October 2026.
