"Only Sara knew how that deploys"
A senior developer leaves, and the release freezes for two weeks because the deploy runbook lived in her head, not in a document anyone else could follow. A new hire takes three months to become productive — not because the system is complex, but because the actual knowledge is scattered across old Slack threads nobody can search.
This is weak knowledge transfer, and its signature symptom is a high bus factor: the number of people who could leave before a piece of the system becomes unmaintainable. When that number is one, someone's vacation is a release risk.
A folder of stale PDFs doesn't fix this. What fixes it is a task-linked wiki that gets updated as part of the work, not as a separate documentation project nobody has time for.
Symptoms and the real cost
| Symptom | Cost |
|---|---|
| One person owns each integration | PTO becomes a release blocker |
| Onboarding takes 90+ days | New hires can't become productive |
| Runbooks live in DMs, not the wiki | Nothing is searchable when it's needed |
| "We should document this" repeats every retro | The gap never actually closes |
| Knowledge Hub exists but sits empty | The tool isn't the problem — the habit is |
Teams that ignore this pay for it after someone resigns, not before — which is exactly when it's most expensive to fix.
A framework for closing the gap
1. Map the bus factor. List every task or system with exactly one person who understands it. That's your risk list, ranked by how critical each piece is.
2. Give each domain a wiki template. Deploy process, on-call escalation, third-party integrations — each gets a fixed structure so writing it down isn't a blank-page problem.
3. Link the wiki to the task. When a task involving a single-owner system moves to Done, updating the linked wiki page is part of the definition of done — not an afterthought.
4. Pair before someone owns something solo. A day of shadowing before full ownership costs less than three weeks of guessing after the owner is gone.
5. Index the Knowledge Hub by task. Every task-critical wiki page should be findable from the task itself, not just from a folder someone has to already know exists.
6. Add a wiki sign-off to offboarding. Before someone's last day, the runbooks they own get reviewed against reality — not against what they remember writing months ago.
7. Pull knowledge gaps into every retro. Any incident that happened because "nobody but X knew" becomes a wiki action item, not just a line in the postmortem.
Leading indicators beat lagging ones
| Leading (weekly) | Lagging (after the fact) |
|---|---|
| Bus-factor list reviewed and shrinking | Stakeholder blindsided by a departure |
| Wiki updates tracked as part of Done | Firefighting and blame after an incident |
| Knowledge Hub coverage per domain | Arguing over "which number is real" |
| Decisions logged as they're made | The same mistake repeats next project |
Anti-patterns
- Writing documentation only after an incident forces it.
- A wiki graveyard — pages nobody has touched in a year and nobody trusts.
- Video-only knowledge capture — nobody can search a 40-minute recording for one command.
- "Sara knows" as a permanent answer instead of a temporary one.
- Documentation with no named owner, so it goes stale the moment it's written.
How WKFGo supports this
- Wiki and Knowledge Hub — pages linked directly to the tasks and systems they document.
get_wiki_page/update_wiki_page(MCP) — an AI assistant can pull or update documentation from inside the editor, without a context switch.- Task-linked issues — knowledge tied to the specific task where it's needed, not buried in a general folder.
- Task history — a record of who changed what, useful when reconstructing a decision nobody remembers making.
Where this shows up
Fintech teams often have one person who understands the compliance-critical parts of a flow — the exact place you don't want a single point of failure. SaaS teams frequently still have a manual deploy step only one engineer has actually run end to end. Outsourced or high-turnover teams feel this hardest, since the "just ask around" fallback disappears every time someone's contract ends.
In all three cases, closing the gap proactively is cheaper than doing it during an offboarding scramble.
Start this week
Draw the bus-factor map — it takes an hour, not a quarter. For the highest-risk item on it, write a deploy or runbook wiki page good enough that someone who's never touched that system could follow it during a dry run. At the next retro, ask one question: "which incident this sprint had no doc behind it?" Turn the answer into a wiki task.
The payoff shows up as shorter onboarding and PTO that doesn't threaten a release — track time-to-first-deploy for new hires as a concrete signal that it's working.
Role-specific starting points
Product managers: add a documentation-updated checkbox to the definition of done for any epic that touches a single-owner system.
Engineering: block merges on new integrations that don't link to a wiki page — a five-minute rule that prevents a much larger cost later.
PMO / leadership: pilot this on one squad before mandating it org-wide. A working playbook from one team is worth more than a policy nobody's tested.
Summary
Weak knowledge transfer isn't fixed by buying a wiki tool — most teams already have one sitting mostly empty. It's fixed by making documentation part of Done, reviewing the bus-factor list on a cadence, and treating "only one person knows this" as a risk to close, not a fact of life.