Knowledge base vs. wiki vs. shadowing: which keeps know-how?
What a wiki, a knowledge base and a shadowing week each keep when someone leaves, where each one fails, and how to choose for your team.
Short version: a wiki holds what people chose to write, a knowledge base holds what someone curated and keeps current, and shadowing holds what the successor thought to ask in one week. All three fail the same way: the knowledge nobody wrote down never gets in. Here is what each one keeps, what it loses, and how to choose.
Key takeaways
- A wiki keeps what people chose to write, and drifts out of date without an owner.
- A knowledge base keeps curated, current answers, but only what someone thought to add.
- Shadowing transfers skill quickly, but leaves nothing behind once the expert is gone.
- All three miss the judgment nobody wrote down, so ask for it before people leave.
Someone gives notice on a Tuesday. By Friday, the team is standing around a production line that will not start, because the only person who knew the workaround is packing up a desk.
That is the moment every operations lead is trying to avoid, and it is usually when people go looking for a fix. Three fixes come up again and again: a wiki, a knowledge base, or a shadowing week. They sound like variations on the same idea. They are not. Each one keeps a different kind of knowledge, takes a different amount of effort, and lasts for a different length of time.
The real question behind "knowledge base vs. wiki"
When people compare a knowledge base and a wiki, they usually compare features: pages, search, permissions, editing. That misses it.
The question that matters is simpler. When the person who knows the work is gone, can the next person find the answer on their own, without asking anyone?
Three things decide that: how the knowledge is structured, how much effort it takes to keep, and how long it stays true. Feature lists don't.
What a wiki holds, and what it misses
A wiki is a shared writing space. Anyone can add a page, and that openness is the point.
It works when the team has a habit of writing things down and a reason to keep doing it. In practice, most wikis fill up fast at the start and then go quiet.
You have seen the symptoms. A page last edited three years ago. A link to a tool nobody uses. A runbook that stops right before the part that actually breaks. The wiki isn't wrong. It is just stale, and nobody owns the staleness.
What a wiki misses is the knowledge that never got written down because the person who held it was too busy doing the work. The exception in the fourth step. The client who needs a call before the invoice goes out, not after.
What a knowledge base holds, and what it misses
A knowledge base is a curated set of answers. Where a wiki is open to everyone, a knowledge base has an owner, a structure and a standard: each article answers one question, sits in a known place and gets reviewed.
That makes it far easier to search and far less likely to rot. A good knowledge base is the best place for the answer to live.
Its weak point is the same as the wiki's, just better hidden. Somebody still has to write every article, and they can only write what they know is missing. The workaround that lives in one person's head doesn't become an article until someone asks about it. Usually that is after the person has left.
What shadowing holds, and when it runs out
Shadowing is the oldest method there is. Sit with the person. Watch. Ask questions. Write what you can.
On its best day it gets more across than any document. You see the judgment calls, the tone in a phone call, the moment someone decides to escalate. None of that survives in a wiki page.
Then the questions end.
Shadowing lasts as long as the questions do. Once the successor stops asking, the learning stops. Anything not covered that week is gone, and you rarely know what you missed until months later, when it matters.
It has a second cost. For that week, two people are doing one job slowly. For a small team, that isn't a detail.
Knowledge base vs. wiki vs. shadowing at a glance
| Wiki | Knowledge base | Shadowing | |
|---|---|---|---|
| What it holds | Whatever people chose to write | Curated answers to known questions | What the successor saw and asked in one week |
| Who keeps it current | Everyone, so often nobody | A named owner | Nobody; it is a one-off |
| Effort | Low to start, high to keep honest | High to build, moderate to maintain | A week of two people's time |
| How long it lasts | Until the work changes | As long as someone maintains it | As long as the successor remembers |
| Where it fails | Goes stale | Never contains what nobody knew to write | Ends when the questions do |
The three failure modes
Line the three methods up and a pattern appears.
- The stale wiki. It described the work once, accurately, and then the work changed. Nothing kept up.
- The tidy knowledge base with a hole in it. Every article is good. The one thing the team needs on a Friday evening was never written, because nobody knew it existed.
- The shadowing week that ended. It passed on the most, but it passed it on once, in a room, out loud.
All three have the same root. The knowledge had to come out of someone's head first, and nothing made sure it did.
The missing step: asking before they leave
Whichever tool you pick, the hard part is getting the knowledge out of the person's head before their last day. Nobody writes down what they don't realise they know. They do say it, though, when someone asks the right question.
That is why a structured conversation beats a blank page. Ask how a normal week runs, what goes wrong, who they call and which rules get bent, and write the answers into whatever your team already searches. We put together 20 knowledge transfer interview questions for exactly this.
It is also what OakHive does. An AI interviewer talks with the person leaving, by voice and in their own language, and turns the conversation into a handover guide for the successor, a summary for the manager that lists what wasn't covered, and a chat the team can ask later, in OakHive or in Microsoft Teams. Your wiki or knowledge base stays where it is; it just stops missing the part that was never written. See how it works.
How to choose
Team size, turnover risk and who has to find the answer later should decide this, not a feature comparison.
Small team, low turnover, strong writing culture. A wiki can hold. Keep it honest: name an owner for every page, and put a date on it.
Support-heavy or regulated work, where the same questions come up again and again. A knowledge base earns its cost. Give it an owner and a review date.
One critical role with a single successor already in place. Shadowing earns its place. Do it deliberately, and write down what you can while it happens, because the week ends.
A few people hold work nobody else can see. None of the three is enough on its own. Interview those people before they hand in their notice, then put the answers wherever your team looks. If you suspect this is your team, here are the signs.
Who has to find the answer later settles most of the argument. If it is the successor sitting next to them, shadowing might be enough. If it is a new hire six months from now, or a manager covering two teams, you need something that outlives the conversation.
A quick way to decide
Ask one question: if this person's last day were two weeks from now, what would be lost first?
If the answer is "the written procedures", a wiki or knowledge base will do, as long as you keep it current.
If the answer is "the way they handle the tricky cases", shadowing helps for a week and then stops.
If the answer is "most of it, and nobody would know what to ask", start with the questions, before someone hands in their notice. Every week you wait has a price, and you can put your own number on it.
Frequently asked questions
What is the difference between a knowledge base and a wiki?
A wiki is an open writing space where anyone can add or edit pages. A knowledge base is curated: each article answers a specific question, has an owner and gets reviewed. Wikis are faster to start; knowledge bases stay accurate longer.
Is shadowing enough for knowledge transfer?
Only for short handovers with the successor already in place. Shadowing passes on judgment and context well, but it ends when the questions do, and anything not covered that week is lost. Write down what you learn while it happens.
Why do wikis go out of date?
Because nobody owns them. Pages are written once, when someone has time, and the work changes after. Naming an owner and a review date for each page is the simplest fix.
How do you get undocumented knowledge into a knowledge base?
Ask for it. Interview the person who holds it, before they leave, with questions about how the work runs, what goes wrong and who they call. Then turn the answers into articles grouped by task.
