A retro that changes nothing is a meeting that should not exist.
"Run retrospectives that produce real action items instead of documented complaints."
Why this exists
Retros fail when they turn into venting sessions with no follow-through, or performance reviews disguised as reflection. We run them because repeating the same bugs and process failures is an embarrassing choice.
Operational Flow
Schedule the retro within five days: After five days, memory softens and useful friction disappears. Capture feedback while the project details are fresh.
Send a pre-work prompt 24 hours early: Ask what worked, what failed, and what you would change. People think better in writing than under live pressure in a call.
Limit the meeting to 45 minutes: Review the async responses, cluster common themes, and focus on the two or three issues that appeared more than once.
Assign exactly one owner per action item: Do not assign tasks to 'the team.' If there is no single owner, note it as acknowledged with no action.
Follow up on previous action items: Start every retro by checking if last time's actions were completed. This is the only accountability mechanism that works.
Write a two-paragraph summary in Notion: Keep it readable in under three minutes so anyone starting a similar project can find it.
What good looks like
- The retro produces one process change shipped before the next project, such as a new Linear template or a tighter handoff checklist.
- An engineer references a past retro summary unprompted when starting a new project.
- The facilitator notices a pattern, like citing QA timing three times, and proposes a systemic fix.
What NOT to do
- Don't let retros become performance reviews. If feedback is personal, deliver it directly and separately.
- Don't generate more than four action items. A list of twelve is a list of zero. Prioritize ruthlessly.
- Don't run a retro without pre-work. Brainstorming from a cold start produces surface-level observations instead of root causes.
The worst retro we ever ran was forty-five minutes of everyone agreeing that communication was a problem, followed by a vague promise to be more proactive, followed by the exact same communication breakdown on the next project. There was no owner and no change. The problems were real, but we did not treat them like solvable engineering problems. We treated them like weather: observed, discussed, and accepted. We changed the format after that. The pre-work prompt cut the on-the-spot performance anxiety, and people started writing down the actual issues instead of the diplomatic versions.
Retros work best when they are boring. A dramatic retro means something festered for too long. If the team is calibrated correctly, the retro mostly confirms what everyone already noticed, leaving twenty minutes to discuss one thorny problem. The goal is steady improvement, not catharsis. Track your action items, revisit them, and either close them or explicitly abandon them. This discipline is the difference between a team that gets better and a team that just gets older.