"You'll have to ask Mr. Berger - he's been doing this for twenty years." If that sentence gets said in your company, you have a single-person knowledge silo: knowledge that exists in exactly one head. No manual, no documentation, no second person who could step in.
Knowledge silos don't come from bad intentions. They form because someone takes on a task, does it well, and nobody ever asks how. Ten years later, the entire customs handling, the pricing calculation, or the maintenance of the old production line hangs on one person. As long as that person is around, nobody notices. At the first extended absence, everybody does.
The good news: knowledge silos can be broken up without anyone having to "give up" their knowledge or feel replaced. Here are five strategies that work in practice - each with the typical mistake that makes it fail and the criterion that tells you it's working.
Strategy 1: Systematically map who is the only one who knows what
What to do
Before you document anything, you need a map. Walk through your core processes - order handling, purchasing, complaints, invoicing, IT - and ask two questions per process: Who can do this? And: Who else can do this?
Wherever the second question has no answer, you've found a silo. Also note how critical the process is and how likely an absence is (retirement in two years counts differently than a 30-year-old on a permanent contract). That gives you a simple priority list: critical plus foreseeable departure first.
Important: don't only ask the managers. They often have no idea which Excel sheet in sales contains the actual truth, or that the vacation backup in accounting exists only on paper. Ask the people who do the work.
Typical mistake
The mapping turns into a mega-project. A consultant, three workshops, a 40-page risk matrix - and six months later the document is outdated before the first measure ever ran. Keep the mapping deliberately rough. A list of twenty rows where you tackle the top five beats any perfect analysis.
How you know it's working
For your five most critical processes, you can answer the question "What happens if person X is out starting tomorrow?" in one sentence - and the answer isn't "no idea."
Strategy 2: Interviews instead of "just write it down"
What to do
The reflex response to knowledge silos is: "Ms. Krause, why don't you document your area?" That almost never works. Not out of laziness, but because experts can no longer see their own knowledge. Anyone who has done a job for fifteen years considers ninety percent of it obvious - exactly the ninety percent their successor will be missing.
What works: asking questions. Have someone conduct the interview who doesn't know the process and keeps asking naive follow-ups. "And what do you do when the supplier doesn't respond?" - "Oh, then I just call Meier directly, he sits right..." Sentences like that never end up in self-written documentation, but they are the actual knowledge.
The snowball principle matters too: every conversation surfaces names. "Invoice approval is actually done by Max and Hanne." So Max and Hanne are the next people to talk to. That way you work your way through the company along the lines of who actually holds the knowledge - not along the org chart, which often claims otherwise.
If nobody internally has time for these conversations: that's exactly what tools now exist for. With wissa.ai, an AI conducts the interviews via chat, 15 to 20 minutes per person, automatically follows mentioned names to the next knowledge holder, and builds process documentation from it in which every statement can be traced back to the conversation it came from.
Typical mistake
The interview turns into an interrogation or a performance review - then the knowledge holder shuts down. Make it clear from the start: the point is to safeguard the person's knowledge, not to replace or evaluate the person. Sharing your knowledge doesn't make you expendable - it means you can finally take a vacation without being called three times a day.
How you know it's working
Someone outside the field reads the documentation and can explain the process in broad strokes - including the edge cases that previously existed only by word of mouth. And: contradictions surface ("The boss says it runs through SAP, the team says through three spreadsheets on the department drive"). That's not failure - that's the moment you see for the first time how things actually run.
Strategy 3: Name backups - and run through the process once
What to do
Every critical process needs a name in the second row. But a name on a piece of paper is not a backup. The backup has to have actually done the process once - with the knowledge holder sitting next to them, watching and stepping in only when things get stuck.
Concretely: the backup runs the month-end close, enters the customer order, files the customs declaration. Once, end to end, with real data, in the real system. Afterwards you know two things: whether the documentation holds up and whether the backup could act in an emergency.
A proven occasion is the knowledge holder's vacation. Two weeks in which the backup takes over and isn't allowed to call (except in a genuine emergency) are the most honest test there is.
Typical mistake
The backup exists only on the org chart. When it matters, it turns out they were formally named but have no access to the system, don't know the password, and have never seen the process. Naming without a run-through is self-reassurance, not risk coverage.
How you know it's working
The knowledge holder was gone for two weeks and there was no backlog, no emergency calls during vacation, and no pile of "we'll sort that out when he's back."
Strategy 4: Document knowledge where the work happens
What to do
Documentation nobody finds doesn't exist. The 2021 process manual in the "QM_final_v3" folder on the file server has never cushioned a single absence. Knowledge has to live where it's needed at the moment the question comes up: linked in the wiki the team already uses, attached to the transaction in the ERP, as a checklist right at the workstation.
That includes more than process steps. Usable documentation also answers: Which systems do I need, and who knows them? Where are the credentials? Who do I call when case X happens? A tool register with access details and contact people prevents the classic first day of a crisis: eight hours of password hunting.
Screenshots help enormously. "Then click the Billing tab" is unambiguous with a picture and a guessing game without one.
Typical mistake
A new tool gets introduced just for the documentation. One more login, one more place you'd have to check. After three months, nobody looks at it anymore. Use what you already have - or at least make sure there is one single entry point everyone knows.
How you know it's working
New employees and backups find answers themselves instead of asking. It becomes measurable during onboarding: when the new hire says in week two, "I found that in the documentation," the system works. When he's standing at his colleague's desk for the fifth time, it doesn't.
Strategy 5: Institutionalize keeping it current
What to do
Most documentation projects don't fail at the start - they fail at the after. The process changes - new supplier, new ERP module, the 2019 Word template gets replaced - and the documentation stands still. After a year it's wrong, after two years nobody trusts it anymore, and everyone is back to asking Mr. Berger.
Staying current needs a mechanism, not an appeal. Options: a fixed review slot every quarter (30 minutes per core process, no more), a documentation update as a mandatory item in every process change, or recurring short interviews that ask what has changed. What matters is that changes become visible - whoever can see what changed since the last version can also tell whether the documentation is alive or just lying around.
Here too, the effort can stay small: wissa.ai updates the documentation after every conversation and shows the difference from the previous version - so you see at a glance what changed instead of laying two Word files side by side.
Typical mistake
Responsibility assigned to "everyone" means responsibility assigned to "no one." If keeping the documentation current has no name and no date attached to it, nothing happens. Name one person per area who doesn't have to write everything themselves but makes sure it happens.
How you know it's working
When questions come up, the documentation is actually the first thing people open - the employees themselves, unprompted. That only happens if it's accurate. The moment the first wrong entry is left uncorrected, trust tips.
The common thread: start small, but start
You don't have to run all five strategies at once. The realistic order: first the map (strategy 1), then interviews for the two or three most critical silos (strategy 2) and run-throughs with the backups (strategy 3). Where things live (4) and the update routine (5) follow from that almost by themselves.
If you don't want to handle the interview part with your own capacity: that's exactly what wissa.ai does - AI-led conversations with your employees, 15 to 20 minutes per person, voluntary and with no performance evaluation, GDPR-compliant with EU hosting. The result is living process documentation with an org chart, knowledge risks, and onboarding plans. The beta waitlist is open: Join the beta waitlist.
FAQ
What is a single-person knowledge silo?
A single-person knowledge silo exists when knowledge about a process, a system, or a customer relationship lives with exactly one person - with no documentation and no trained backup. If that person is out, the process stops.
How do I spot knowledge silos in my company?
For each core process, ask "Who else can do this?" Wherever the answer is missing or comes hesitantly, a silo sits. Everyday warning signs: calls during vacation, sentences like "only Schmidt knows that," and tasks that pile up as soon as one particular person is out sick.
Why doesn't "just write down what you know" work?
Because experts no longer fully see their own knowledge. What has been routine for years gets left out as obvious - but that is exactly what the successor will be missing. Interviews with naive follow-up questions draw out this implicit knowledge; self-documentation almost never does.
How do I convince knowledge holders to share their knowledge?
With honesty about the purpose: it's about risk coverage, not replaceability. Concrete arguments that land: undisturbed vacations, fewer interruptions, relief from routine questions. Participation must be voluntary, with a clear commitment that the conversations won't be used for performance evaluation - that convinces the works council too.
How long does it take to break up a knowledge silo?
For a single critical silo: a few weeks. One or two interviews, the documentation built from them, one run-through of the process with the backup. It only becomes a big lift if you want everything at once - so: prioritize and start with the two or three most critical ones.