Operations.

The Retrospective

5 min read·Apply by lunch

The question

When something went wrong for your team last month — the slipped deadline, the messy launch, the handover that dropped — did anything about how you work actually change, or did everyone privately note it and move on; and if you can already name the problem that will recur, why haven't you scheduled the hour that fixes it?

The idea

The retrospective comes out of agile software practice, where teams shipping every fortnight discovered they could not afford to learn only from post-mortems — by the time a failure was big enough to examine, ten smaller lessons had already evaporated. So they made learning a scheduled event: at the end of every cycle the team sits down and answers three questions — what went well, what did not, what do we change — and every change leaves the room with one owner and a date. The mechanism matters more than the format. Most teams reflect only when something breaks, which means their rate of improvement is set by their rate of disaster. And the trap inside the ritual itself is the therapy session: an hour of honest venting that produces warm feelings, zero decisions, and the identical conversation next month.

The framework

01
Put it in the calendar before you need it.
A retrospective only works as a rhythm — the same slot at the end of every sprint, month or project phase, held whether the period went well or badly. Reviewing only failures teaches your team that reflection is punishment, and it throws away half the learning: knowing precisely why something worked, so you can do it again on purpose. Forty-five minutes on a recurring invite costs less than repeating one avoidable mistake.
02
Three columns, worked in order — well, badly, change.
Have everyone write before anyone speaks: what went well, what did not, what we should change — silent writing first, because the loudest voice will otherwise set the agenda for the room. Then work the columns in order, and hold one ground rule without exception: the meeting examines the system — the process, the handover, the brief — never the person. The moment a retrospective becomes a trial, people stop bringing you the truth, and the ritual is dead within two cycles.
03
Every change gets one owner and a date — or it isn't a change.
This is the discipline that separates a retrospective from a chat. Cap the output at one to three changes — a team that leaves with seven improvements will ship none of them — and write each one as an action with a single name and a deadline, never a theme with a committee. 'Improve communication' is a wish; 'Priya drafts the handover checklist by Friday' is a change. If a proposal cannot be phrased that way, it is not ready to leave the room.
04
Open the next one by auditing the last one.
The first agenda item of every retrospective is the previous retrospective's actions: done, not done, and why. This closes the loop that makes the ritual compound — people take the meeting seriously in exact proportion to whether its decisions survive it. A team that checks its own follow-through builds, cycle by cycle, the rarest operational asset there is: the earned belief that raising a problem changes something.

Members only · 4 principles + template + AI mentor

364 more frameworks are waiting.

The Retrospective is Day 1 of 365. One framework every morning for a year — across strategy, sales, negotiation, leadership, and more.

$1 /day

Billed $365/yr · cancel any time

365 frameworks

12 topics · templates · AI mentor

Reserve your place — $365/yr →

One payment a year · the whole library · no auto-renewal.

More Operations frameworks

All 24 operations frameworks →