Why Our Best Incident Retros Happen a Week Later, Not a Day Later

We used to schedule retros within 24 hours to "keep details fresh." The data says our most useful retros happen roughly a week out, and here's why.

The conventional wisdom is to retro fast, before memory fades. We believed it for years, until we compared the action-item follow-through rate of retros held within 24 hours against ones held five to seven days later, and found the gap too large to ignore.

What the timing comparison showed

Retros held within a day of an incident produced action items that were completed within the following quarter at a rate of 51%. Retros held five to seven days later completed at 78%. The facts weren't fresher in the fast retros — the timeline reconstruction quality was actually similar either way, since we log incident channels automatically. What differed was the quality of the thinking about what to actually do about it.

"The day after, I'm still a little defensive and a little relieved it's over. A week later I've actually thought about it in the shower three times and know what I really think caused it."

What a week gives you that a day doesn't

Immediate retros happen while people are running on adrenaline and residual stress, which produces either overly harsh self-assessment or defensive minimization — rarely the calibrated middle where good action items come from. A week's gap lets the emotional charge settle while the facts, captured automatically in the incident channel and metrics, stay perfectly intact.

retro_scheduling_policy
timeline_capture: automatic, within 1 hour (channel export + metric
  snapshots) — this preserves facts regardless of when the retro meets
retro_meeting: scheduled 5-7 days after resolution, not before
exception: >
  Sev-1 incidents with active customer commitments may need a fast
  initial debrief for immediate fixes, but the FULL retro still
  waits the full 5-7 days; the debrief is explicitly not the retro.

What we protect to make this work

This only works because we separated fact capture from the retro meeting itself — automating the timeline the moment an incident closes means nothing depends on memory by the time the meeting happens, whether that's a day or a week later. The delay is safe to take specifically because we removed the thing delay used to cost us.

• Fast retros aren't automatically better retros — measure action-item follow-through, not just how quickly the meeting happened.
• Automate timeline capture immediately so a delayed retro meeting doesn't cost you factual accuracy.
• Give people a few days of emotional distance before asking them to reason calmly about what went wrong and why.