Look at the action items from your last four quarterly retrospectives. Be honest about how many of them resulted in a different outcome the quarter after they were written. If your company is like most, the answer is somewhere between "two or three" and "I don't actually know, nobody tracks that." And yet you'll run the next retro just like the last four, because retros are a ritual everyone agrees they should perform, even if the evidence that they change anything is thin.
I'm not arguing against retrospectives. I'm arguing against the form most companies use them in, which produces neat documents and almost no behaviour change. The lessons are real. The mechanism that would carry the lesson into the next cycle simply doesn't exist.
What actually happens in a quarterly retro
The pattern is so consistent it's almost comforting. The leadership team gathers, often offsite, often with a facilitator. The themes that emerge are honest and slightly embarrassing: we overcommitted again, we ignored dependencies between teams, we shipped initiatives without clear owners, we let the OKR refresh slip until it was perfunctory, we said yes to the board on something we hadn't actually planned for. People nod. Someone says "we have to stop doing this." Action items get written on a board, then transcribed into a doc, then shared.
The doc lives in a wiki. It is referenced occasionally — usually by the person who wrote it, when they're preparing for the next retro three months later and want to compare notes.
Next quarter, the same themes appear. Sometimes verbatim. The team notices, briefly. Someone says "didn't we say this last time?" The room laughs uncomfortably. Then they write the same lessons down again, in slightly different words, and move on.
Why the lessons don't carry
A post-mortem is a document. A pattern is changed by a structure. Those are two different categories of object, and the first cannot turn into the second by itself.
When the only artefact produced by the retrospective is a list of lessons in a wiki, the actual structure of the next planning cycle has not moved. The same planning template will be used. The same calendar will impose the same time pressure. The same goal-setting tool will allow the same failure modes. The same incentives will reward the same behaviour. Given that the structural inputs are identical, it should not surprise anyone that the structural outputs are identical too. The lessons are real and ignored, not because anyone is lazy or in bad faith, but because the lessons never became rules. They stayed advice.
Advice can't change a system. Rules change a system. The retrospective produces advice, the operating model continues to produce the same behaviour, and the gap between them is where the repetition lives.
What it would take for a lesson to actually carry
A lesson carries into the next quarter only if it becomes part of how the next plan is built, not a document the next plan ignores. Three concrete forms work, in increasing order of how much they require you to change.
The first is a change to the planning template. If last quarter's lesson was "we kept committing to initiatives without naming a delivery owner," then the next planning template must have a required field that won't let an initiative be created without one. The lesson is enforced by the tool, not by memory. The owner of the planning template — and there should be one, named — is responsible for updating it after each retro to embed the lessons that came out.
The second is a change to the cadence. If the lesson was "we noticed the H2 forecast was wrong in October, two months after we could have," then the cadence needs to put the H2 forecast in front of the team in August. The earlier signal is the structural intervention. Adding "be more vigilant about the forecast" to a wiki accomplishes nothing.
The third is a guardrail in the system itself. If the lesson was "we let multiple high-priority initiatives compete for the same team without noticing," then the system holding initiatives and capacity needs to refuse to accept the over-allocation silently — it has to flag it, ideally before the plan is approved. This is the hardest of the three, because most tooling isn't set up to enforce that kind of cross-cutting constraint. But it's also the one that actually makes the failure mode structurally impossible to recur unnoticed.
Why companies prefer the document
The doc is easier. Writing a lesson down feels like progress, and it discharges the emotional weight of the retro — the room has acknowledged the problem, named it, and committed to "doing better." Nobody had to take an unpopular decision. Nobody had to change a template, push back on a cadence, or fight with a tooling team about adding a guardrail. The work of changing the structure is harder and more political than the work of writing the lesson down, and the lesson-writing produces the same momentary feeling of resolution.
This is also why the same lessons appear in every retro. The structural changes that would actually prevent the repeat are exactly the changes the leadership team has consistently chosen not to make, because each of them costs more than writing the lesson did.
The Vindaris view
Retrospectives are inputs to the operating system, not artefacts in a folder. If the lesson doesn't show up as a structural change — a new required field, a shifted cadence, a guardrail in the system — before the next planning cycle starts, it didn't land. It was processed emotionally and discarded structurally, which is the worst possible combination, because the company has now also developed a false sense that the lesson was addressed.
Stop measuring whether the retro happened. Start measuring whether the structure changed. If you can't point to a specific edit in the planning template, calendar, or tooling that traces back to a lesson from the last retro, the retro didn't do anything except make people feel briefly better.