How to run a retrospective or post-mortem on Starch

A retrospective or post-mortem is the structured conversation you have after a project, sprint, or incident ends — the one where your team figures out what actually happened, what to do differently, and who owns what next. Most operators know they should run these. Few run them consistently, and fewer still do anything with the output. The notes live in a Google Doc nobody reads, the action items get verbally agreed upon and then forgotten, and the same problems resurface three months later.

What this looks like in practice varies. A product team running two-week sprints treats it differently than a services firm wrapping up a client engagement, or an ops team doing an incident review after a production outage. The mechanics shift, but the core failure mode is identical: the conversation happens, the learning doesn't stick.

On Starch, you end up with a searchable, permanent record of every retrospective — decisions captured, action items extracted and assigned, and a knowledge base that actually compounds over time. When someone asks 'didn't we decide this already?' you can find the exact meeting where it was settled. When a new hire joins, they can read through past retros and understand how your team thinks. The output isn't a doc that ages in a folder — it's living context your team can actually use.