The Answer Was Sitting in Last Year's Retro the Whole Time

The lesson filed, not learned

📚 Learnings — “Have we run into something like this before, and what did we learn from it?”

Maya opens the retro document at 4 PM on a Friday in Manchester, six months into her second vendor onboarding that has gone sideways in exactly the same place as the first one. Wrong contact on the client side, discovered in week four instead of week one. She scrolls up to check — and there it is, from the last time, in a retro doc titled “Vendor Onboarding — Lessons Learned,” dated eleven months ago: confirm the primary contact before kickoff, not after. Someone wrote it down. Someone even bolded it. Nobody read it again until Maya went looking on a Friday afternoon, for the second time, having already paid for the lesson twice.

The retro wasn’t wasted, exactly. The insight is real, and it’s genuinely in a document somewhere. But a document that nobody opens except in hindsight isn’t a lesson learned. It’s a lesson filed — correctly labelled, properly stored, and functionally identical to a lesson that was never captured at all, because the moment it would have been useful is precisely the moment nobody thought to look.

A retrospective is not the same thing as a memory

Teams are good at running retros. The ritual is well established: what went well, what didn’t, what we’d do differently. The failure isn’t in the running of it. It’s in what happens to the output afterwards, which is usually nothing. The retro produces a document, the document joins several hundred other documents, and the next time a similar project starts, nobody thinks to search for it — because searching implies you already suspect the answer exists, and the whole point of a mistake is that you don’t see it coming the second time either.

Peter Senge’s argument in The Fifth Discipline was that most organisations don’t fail to learn because they lack the capacity for insight. They fail because the insight, once produced, has nowhere durable to live where it can shape the next decision. The learning happens. It just happens in a place — a doc, a slide, someone’s head — that isn’t consulted at the moment it would matter. Thirty years on, most companies have simply moved the same problem into better-formatted documents.

There’s a second, quieter failure underneath the first. Even when someone does remember roughly what went wrong last time, they often can’t find the specific detail — which vendor, which week, which exact contact issue — because the retro doc that would answer it is buried in a folder named after a project that finished two quarters ago. The lesson isn’t gone. It’s just filed somewhere that assumes you’ll remember where you put it.

The move: learnings as records, linked to what they’re about

Hold a learning the way the earlier objects in this series get held — not as a paragraph in a doc, but as a record with a shape. What broke. What should happen differently. And, critically, what it’s connected to: which workspace, which kind of project, which vendor, which recurring pattern — so the next similar situation can find it without anyone having to remember it exists.

Tagged, not buried. A learning that’s tagged to “vendor onboarding” or to a specific vendor’s name surfaces again the moment someone starts a new vendor onboarding, whether or not they think to go looking. The retro doc from eleven months ago required Maya to remember it existed. A tagged record doesn’t.

Queryable before the mistake, not just after it. The card’s question — “show me everything we already learned from something like this” — only works if it can be asked before the project starts, not just during the retro that closes it. That’s the actual point of holding learnings as records instead of documents: the query runs at kickoff, when it can still change something, rather than at the postmortem, when it can only explain what already happened.

Attributed, not anonymised. A learning tied to the actual project and the actual person who surfaced it carries more weight than “best practice #14” in a wiki nobody wrote. When the record says this came out of the Lyon vendor rollout, in March, after the same contact issue, it reads as evidence rather than generic advice. Specificity is what makes a lesson worth acting on instead of skimming past.

Put together, the question stops depending on anyone’s memory of what they read once. The pattern surfaces itself, in the room, at the moment someone is about to repeat it.

The second mistake is the one that costs more than the first

There’s a real asymmetry here, and it’s worth being blunt about it. The first time a vendor onboarding goes wrong because of a missing contact, that’s an ordinary cost of learning something new. The second time, it’s not new information any more. It’s the same mistake, made by an organisation that already had the answer and simply couldn’t find it in time. That’s a different and more expensive kind of failure — not a gap in the team’s competence, but a gap in whether the company can act on what it already knows.

This is also the quiet reason retros start to feel pointless after a while, even to the people running them diligently. If the insight never changes anything the second time round, the retro becomes theatre — a ritual of writing things down that nobody expects to matter. Making the learning findable at the moment it’s useful is what keeps the ritual honest.

What this doesn’t do

It doesn’t generate insight. Holding a learning as a searchable record does nothing for a team that isn’t having honest retros in the first place — a shallow “what went well” session produces a shallow record, tagged beautifully, saying very little. The record is only as good as the reflection that produced it.

It doesn’t decide which learnings still apply. Circumstances change; a lesson that was correct eighteen months ago about a vendor who has since changed their entire onboarding process might now be actively wrong advice. Surfacing an old learning is not the same as certifying it. Someone still has to read it and ask whether it still holds.

And it doesn’t force anyone to act on what surfaces. A learning that comes up at the right moment, attributed and specific, can still be ignored — teams under deadline pressure skip the contact confirmation anyway, because they’re in a hurry, and the record was right there. Visibility removes the excuse of not knowing. It doesn’t remove the choice to ignore it.

The honest limit

What this removes is the specific, avoidable version of Maya’s Friday afternoon: the mistake made twice, not because the first lesson was wrong or hidden on purpose, but because it lived in a place nobody thought to check until it was already too late to matter. That’s a real cost, repeated across every team that runs retros diligently and then never opens the doc again.

What it can’t remove is the discipline of reflecting honestly in the first place, and the humility of actually reading what surfaces instead of overriding it because this time feels different. A company can have every learning perfectly tagged and searchable and still repeat its mistakes, if nobody stops to read the record before starting the next one. Holding the lesson is not the same as heeding it.

That part, like the reflecting itself, stays the team’s to do.

Part of the series on what a shared record holds, after Perfect Meeting Memory, Every Decision Keeps Its Receipts, Action Items That Outlive the Meeting, The Questions Nobody Wrote Down, and A Plan That Flags Its Own Drift.