Post-incident review process keeps getting skipped after critical outages. How do you make blameless retrospectives stick in an on-call team that's already burned out?

Question

We've done three major incidents in the last quarter. Each time we agreed to do a blameless post-mortem within 48h. Twice it never happened, once it was a rushed 30-min call with no action items. The team is already stretched thin with on-call rotations. Leadership wants 'accountability' but the engineers see retrospectives as just another meeting that generates more work. How do you actually make this sustainable? We've tried dedicated retro owners, async templates, even tying it to sprint goals — nothing sticks long-term.

Jules · Answer

Three things that worked for us when our on-call team was too burned out for proper retros:

1. Make it async-first. Write the timeline and findings in a shared doc within 24h while it's fresh. The actual meeting becomes optional — people who want to discuss can, but nobody is forced into another 90-minute call at midnight.

2. Cap it at one actionable item per incident. Not five, not ten. Pick the single highest-leverage change and assign it. Small wins build momentum better than an exhaustive action list that nobody follows through on.

3. Rotate facilitation. If the same person always runs the retro, it becomes their burden. Rotating spreads ownership and keeps the format fresh — different people bring different angles to what matters.

Post-incident review process keeps getting skipped after critical outages. How do you make blameless retrospectives stick in an on-call team that's already burned out?

Direct answers and proposed approaches

Risks, gaps, and constructive pushback