The retro happened. The lesson still got relost
A migration goes sideways because of a vendor timeout nobody accounted for. Three months later, a different project hits the exact same vendor timeout. The retro from the first incident happened — there's a deck, there was a discussion, someone even wrote an action item that said "document this." Nobody ever did, or they wrote it somewhere nobody thought to search before starting the second project.
That's the actual failure mode behind missing lessons learned: not that teams don't run retrospectives, but that what comes out of a retro rarely survives past the meeting in a form anyone can find again. A slide deck is fine for the room it was presented in and useless six months later when the same situation resurfaces on a different project.
What actually breaks the loop
The lesson has no fixed home. If retro output sometimes goes to a deck, sometimes to a doc, sometimes to nothing, nobody develops the habit of checking one place before planning.
Nobody checks before planning starts. Even a well-written lesson is dead weight if the next planning session never queries it. The habit that matters is searching before committing to an approach, not writing it down after.
"Document it" has no owner or deadline. An action item that says "someone should write this up" with no name and no date is a wish, not a task — and it shows in how often it actually gets done.
A retro-to-wiki framework that survives past the meeting
1. Fixed retro template. Every lesson gets a wiki page with the same shape: what happened, the root cause, what changes going forward, and a link back to the task or incident. A named owner writes it.
2. Publish the same day, not "later." The wiki page goes up before the retro meeting ends, not after someone finds time. Same-day publishing is the single habit that determines whether a lesson survives.
3. Tag by domain, not by project. "Vendor," "migration," "auth," "deploy" — tags that let a different project find the lesson later, since the next team hitting this problem almost never worked on the original project.
4. Link the decision, not just the symptom. If the retro led to a real decision — switch vendors, add a timeout, change a review gate — log it with log_decision and link it from the wiki page. The lesson and the decision should be one click apart.
5. Query before planning, every time. Before committing to an approach on a new project, run search_decisions and a wiki search for the domain tags involved. This is the step that actually closes the loop — everything before it is just record-keeping if nobody reads it back.
6. Prune quarterly. A stale lesson that describes a system that no longer exists is worse than no lesson — it wastes the next reader's time and erodes trust in the wiki. A named owner reviews and archives outdated pages each quarter.
7. Track repeat incidents as the real metric. The number that actually matters isn't how many retro pages exist — it's whether the same root cause shows up twice. If it does, the lesson wasn't findable, wasn't specific enough, or nobody checked.
Anti-patterns
- Optional retros — skipped under deadline pressure are exactly when the lesson would have mattered most
- Slide decks with no wiki page — technically documented, practically unfindable
- Blame-framed retros — teams stop being honest about root cause the moment a retro turns into naming a person
- Action items with no owner — "document this" without a name attached rarely gets done
- No cross-project sharing — a lesson trapped in one project's private space might as well not exist for the next team
How WKFGo supports this
Wiki pages tagged by domain, linked from the task or incident that produced them, not orphaned in a separate tool.
search_decisions — the MCP tool a planning session should run before committing to an approach, to check whether this exact mistake already has a paper trail.
update_wiki_page / publish_meeting_wiki — publishing retro output the same day, straight from the meeting, instead of a slide deck that gets filed and forgotten.
Knowledge Hub — a cross-project index so a lesson tagged "vendor timeout" surfaces for a team that never worked on the original incident.
A realistic weekly rhythm
Monday planning: before committing to an approach on anything unfamiliar, run search_decisions plus a wiki search for the relevant domain tags. After any retro: publish the wiki page the same day, tagged, linked to the task. Quarterly: review pages for staleness and check whether any root cause repeated — that's the one number worth tracking, not how many pages exist.
FAQ
Are retros enough on their own? Only if what comes out of them ends up somewhere searchable. A retro that produces a slide deck and nothing else is a meeting, not a process.
How do we avoid retros turning into blame sessions? Frame the write-up around systems and root cause, not individuals, and log the decision that followed — that's what future readers actually need.
Is this worth it for a small team? Yes — a short, tagged wiki page costs a few minutes and pays off the first time it prevents a repeat mistake, regardless of team size.
What's the MCP side of this?
search_decisions for querying past lessons before planning, and update_wiki_page / publish_meeting_wiki for getting retro output into the wiki the same day.
Publish retros to wiki
Take the last retro your team ran and give it a wiki page today — root cause, decision, domain tags, linked to the task. Then make searching it the first step of your next planning session, not an afterthought.