Startup Retrospective: The Ritual That Came Out of a Fatal Sailboat Race

As a kid, Norm Kerth raced sailboats. Occasionally someone died.

He watched the adults he respected rerun those races, every decision by every sailor, in front of the whole sailing community, until the club knew what to change. Thirty years later, he said, those lessons were still fresh in his mind every time he got on a boat.

A startup retrospective is that ritual pointed at a company. Kerth's definition, from Project Retrospectives: "a gathering at the end of a project" where everyone involved "collectively learns what he or she can from the experience."

Software teams in 2001 mostly didn't hold the meeting. The reason gets at why most retros fail now. Someone has to feel safe enough to say the release slipped because of a call they made. So Kerth wrote a rule and had facilitators read it out loud before anything else: "Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand."

He took it from Gandhi's letters to his adopted daughter: in spite of their actions, they are doing the best job they know how to do.

His one-line lesson: the retrospective you least want to run is the one with the most to teach you.

Whether that rule does the work, or just sets the tone, is open. Loeffler traces the effect to Rosenthal, whose results reproduced in only 40% of cases.

His example. A team had just failed badly. Three days in a room moved them from "oh no, we are failures" to 23 practices that would have prevented the failure or made it visible earlier. The team leader then told the VP of IT that no other software project in the company was doing any of those 23.

The knowledge existed. It reached one room.

The Army had institutionalized this by 1993, in Training Circular 25-20: "a professional discussion of an event, focused on performance standards, that enables soldiers to discover for themselves what happened, why it happened, and how to sustain strengths and improve on weaknesses."

Four beats: what was supposed to happen, what happened, why, how to improve. When participants work out the answer themselves, they learn and remember more than when a leader hands it to them.

Google turned it into a written object. The SRE book's postmortem chapter opens with Devin Carraway: "The cost of failure is education." A postmortem there is "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring."

Triggers are defined before anything breaks. Senior engineers review the draft for whether the root cause went deep enough and whether the action plan is scoped. The finished doc lands in a repository so the next on call can find it.

Then the chapter's sharpest line: "An unreviewed postmortem might as well never have existed."

The recurring element is the artifact. The Army published a manual, because an unwritten format drifts. Google keeps a repository, because a lesson in one team's doc is invisible to the next. Kerth wrote a handbook of exercises, because a habit needs a form.

Four psychologists name the mechanism. Ellis, Carette, Anseel and Lievens describe systematic reflection as three activities: explaining your own behavior, checking your read of the data against a different read, and getting outcome feedback.

The middle one is the part retros skip. "Consider a different approach that could have been taken" is the prompt that breaks hindsight bias, the tendency to read an outcome as inevitable once you know it.

The same paper reports that reflection works better as people attribute results to specific and internal factors.

So the test for your next retrospective: can you name the decision, what you believed when you made it, and what the belief cost? A retro that ends at "the market was tough" has filed the outcome and skipped the cause.

The founders who compound are boring about this. One quarter, one decision, five lines: what we decided, what we assumed, what the number was supposed to do, what it did, what we'd tell ourselves next time. Twenty minutes. Then it gets stored where the next quarter's decision will look, next to the decisions themselves, not in a folder called retros.

Kerth's failed team learned 23 things. The company learned none of them. That is the normal outcome of a good meeting that leaves no record.