How to run a team retrospective on Starch

A team retrospective is a structured conversation where you look back at a project or sprint, name what worked, surface what didn't, and agree on what changes next time. It sounds simple — and the concept is — but most teams either skip it entirely or run it so loosely that nothing actually changes afterward. Action items get buried in someone's notes, the same problems resurface in the next cycle, and the meeting starts to feel pointless.

What this looks like in practice varies: an engineering team running two-week sprints has a different retrospective shape than a marketing team wrapping a product launch or an ops team closing out a quarterly initiative. The core job is the same — capture what happened, extract the lessons, route the follow-ups — but the inputs, cadence, and who owns what differ.

On Starch, a retrospective stops being a one-time meeting that fades into a forgotten doc. Your meeting is transcribed and summarized automatically, action items are extracted and assigned, and everything archives into a searchable history your whole team can find later. When next quarter rolls around and someone asks 'didn't we try that before?' — you search and find the exact decision, not a vague memory. Follow-up tasks route into your project tracker so they don't live and die in someone's notes app.