How often should software engineering teams run retrospectives?

Every sprint (or every 1–2 weeks). After major incidents, run a separate blameless postmortem — don’t cram that into a normal retro.

Should the engineering manager facilitate the retro?

Rotate facilitation. When the EM always runs it, people self-censor. Managers should still attend, listen, and own systemic blockers.

What if retrospectives feel useless?

You’re probably generating themes without owners, deadlines, or follow-up. Start the next retro by reviewing last sprint’s action items — unfinished ones are the agenda.

9 Tips for Running Better Software Engineering Retrospectives

Most engineering retrospectives are theater: sticky notes, vague “communicate better,” zero follow-through. These engineering retrospective tips make retros useful — safer, sharper, and tied to real change.

Retros surface process issues; also watch ongoing team health signals between ceremonies.

1. Open with psychological safety, not icebreakers

State the rule: criticize systems and behaviors, not people. If someone got burned for honesty last quarter, no format will save you — fix that first.

2. Start by reviewing last retro’s actions

Done, not done, blocked. If nothing shipped from last time, don’t generate more ideas. Fix the follow-through problem before collecting new pain.

3. Change the prompt when energy dies

Rotate formats: start/stop/continue, mad/sad/glad, “what almost broke us,” timeline of the sprint. Same three columns every two weeks trains people to phone it in.

4. Timebox venting, then force specificity

“Process is broken” isn’t actionable. Ask: What happened? When? Who was stuck? What would “better” look like next Tuesday?

5. Vote, then pick one or two themes max

A retro that tries to fix eight things fixes none. Dot-vote. Choose the highest-leverage theme. Park the rest in a backlog you’ll actually revisit.

6. Every action needs an owner and a date

“We should document onboarding” dies in the parking lot. “Sam drafts a checklist by Friday; Alex reviews Monday” lives. Write it where work lives — not only in Miro.

7. Separate incident postmortems from sprint retros

Mixing them creates fear and shallow discussion. Incidents need timelines and contributing factors. Sprint retros need cadence and team norms.

8. Invite the right outsiders sparingly

Product or design can help when cross-team friction is the theme. Don’t turn every retro into a stakeholder showcase — honesty drops when the audience grows.

9. Close with commitments people can see

End by restating owners and dates out loud. Put them on the team board. Next retro starts there. That’s how retros stop being therapy and start being operations.

If the same themes keep returning, your team health may be the real issue — not the retro format.