Beyond writing a postmortem document, holding an actual retrospective meeting/discussion extracts additional learning through group discussion and ensures action items get genuine buy-in. This guide covers running one effectively.
Postmortem Document vs Retrospective Meeting
The written postmortem (see How to Write an Effective Incident Postmortem) documents facts; the retrospective is a facilitated discussion extracting deeper insight through group perspective — both have value, and the meeting often surfaces things the document alone misses.
Who Should Attend
Everyone directly involved in the incident response, plus relevant stakeholders (team lead, affected service owners) — keep the group focused and relevant rather than inviting broadly "just in case," which can inhibit the open discussion blameless postmortems depend on.
Setting the Tone: Explicitly Blameless
Open the retrospective by explicitly restating the blameless principle — the goal is understanding systemic factors, not evaluating individual performance. This framing needs active, repeated reinforcement, since blame instincts are natural and easy to slip into unconsciously.
Structuring the Discussion
1. Walk Through the Timeline Together
Review the documented timeline as a group, filling in gaps and correcting any inaccuracies from multiple participants' perspectives.
2. Discuss "Why" at Each Key Decision Point
For each significant action or decision during the incident, discuss why it made sense at the time given the information available — this reveals genuine systemic gaps (missing information, unclear ownership) rather than framing anything as an individual mistake.
3. Identify Contributing Factors Collaboratively
Group discussion often surfaces contributing factors that weren't obvious to any single person working alone during the incident itself.
4. Brainstorm and Prioritize Action Items Together
Collaborative action item generation produces better buy-in than one person unilaterally deciding what needs to change — and often surfaces better ideas than any individual would have generated alone.
Facilitation Techniques
- Ask open-ended "what" and "why" questions rather than leading or blame-implying ones
- Actively redirect any blame-oriented comments back toward systemic factors
- Ensure quieter participants get space to contribute, not just the most vocal voices
The "Five Whys" Technique for Root Cause Analysis
Why did the site go down? → The database ran out of connections.
Why did the database run out of connections? → A connection leak in a recent deploy.
Why wasn't the leak caught before deploy? → No connection pool monitoring existed.
Why was there no connection pool monitoring? → It wasn't part of our standard monitoring setup.
Why wasn't it part of standard setup? → No established checklist for new service monitoring requirements.Repeatedly asking "why" surfaces the systemic root cause, well beyond the surface-level symptom.
Closing the Retrospective
Confirm action items have clear owners and dates before ending — leaving this ambiguous significantly reduces the likelihood follow-through actually happens.
Following Up
Schedule a follow-up check (even brief) on action item completion — retrospectives without follow-through become a demoralizing ritual rather than a genuine improvement mechanism.
Common Errors
Retrospective devolves into blame despite good intentions — actively facilitate and redirect; consider a neutral facilitator (not someone directly involved in the incident) for particularly sensitive incidents.
Continue Reading
- How to Write an Effective Incident Postmortem
- How to Set Up an On-Call Rotation and Alerting Escalation Policy
- How to Build a Status Page for Your Service
Browse more articles in Advanced Observability & Incident Management.
