Summary
Knowledge Silos: Knowledge silos rarely form out of ego; they stem from unaddressed practical conditions. Blanket documentation mandates fail because they cannot capture judgment, context, or critical networks. To dissolve single points of failure, leaders must understand what the expert actually needs, build trust-based agreements, and facilitate transfer through targeted questions rather than passive documentation. Secure your team’s long term delivery capability.
The bottleneck is rarely the knowledge. It is the conditions under which somebody is asked to pass it on.
You know the name. Every question about that one product has led to them for years. The person is fast, reliable and answers everything, which is why nobody notices day to day that they are a bottleneck. It will get noticed on the day they spend three weeks in hospital.
The standard response is a documentation mandate.
It does not work, for a reason most programmes never examine: nobody has asked this person what they would need.
This article is for leaders who have spotted a knowledge monopoly in their department and know that instructions will not shift it. Anyone looking for a tool that harvests knowledge automatically is in the wrong place. The knowledge is not the problem.
The Developer We Wanted to Win for Prievidza
He knew the window regulator electronics from the ground up
My manager and I wanted to win an experienced developer from headquarters for Prievidza. He had known the IFE products from the very start and had helped shape them. This was not a knowledge monopoly born of carelessness. It had formed over years, because he had been there from the beginning.
I enjoyed working with him anyway
In the projects for the test engineering behind those products, he was the contact for several of us. What I valued in him was his competence and the way he solved problems. That is not an aside but a precondition: a conversation about passing on knowledge runs differently when you respect the other person technically and they can tell.
The conversations happened over coffee, not in a meeting room
Whenever I came from Slovakia to Bamberg, I met him if it was possible.
Over an unhurried coffee we talked about the prospect of moving to Slovakia. In parallel, our manager was also speaking with him. This ran over a considerable stretch of time, and it needed to.
What I discovered had nothing to do with electronics
He was a keen cyclist, and he loved the mountains as well. Those were the subjects through which I could make him curious, not the assignment. Slovakia has mountains. That sounds like a side issue and it was not.
And then came the questions that actually mattered
How does it work with trips home? What about holiday periods? He had obligations in Germany that he genuinely had to meet, among them a large forest and its upkeep. And language was a topic. None of that was a question about his knowledge. All of it decided whether he would come.
The agreement that held
I gave him leave whenever he needed it. We had an agreement, and that agreement held, on both sides. That is the whole mechanism. Not a process, not a form, but a commitment he could rely on and a counterpart I could rely on. He later learned Slovak with a local teacher.
This is the point almost always missing from the discussion
When people talk about experts passing on knowledge, the conversation goes straight to job security or ego. Both exist. In this case it was neither. It was a move to another country, and that meant entirely different things: the surroundings, the practical conditions, the language, the forest back home. Arriving with a documentation mandate means you have not understood the question.
What he then did was explicitly not documentation
Rigid instructions along the lines of write your knowledge down strike me as wrong.
Instead he built a whole software team around himself, using his knowledge, and he did it in a way that worked.
He let the team get on with it
When questions came, he pushed back on the team. Rather than coming straight out with his knowledge and his solutions, he set challenges and asked for routes to a solution. Only when something was heading in an entirely wrong direction did he steer corrections. That is the same movement as in a good one-to-one: asking instead of supplying, applied to knowledge transfer.
And it had to feel right for both sides
In my own case it was always that I saw how far we got together compared with what I could have managed alone. In his case you could see that developing the products gave him pleasure and that working with the Slovak colleagues connected him to them as people. Knowledge transfer that feels like loss does not happen. Knowledge transfer that feels like better work happens on its own.
The proof came later
The team he built still delivers today. That is the only measure that counts. Not how many pages of documentation appeared, but whether the work runs without the one person.
No sales conversation. If I am not the right person for you, you will hear that in the first five minutes.
What the Data Shows About Knowledge Monopolies
Almost half of all studied projects hang on one person
Software engineering has a measure for this phenomenon: the Truck Factor, meaning the minimal number of developers whose simultaneous loss leaves a project incapacitated. Avelino, Passos, Hora and Valente published a method in 2016 for computing that value from version history, and applied it to 133 popular GitHub applications across six programming languages.
The result: 46 percent of those projects have a Truck Factor of 1, and a further 28 percent of 2. Three in four systems therefore stall if one or two people drop out. A later study by the same group covering 1,932 projects reports 57 percent with a Truck Factor of 1 and fewer than 6 percent above 5.
These numbers come from open source software, where anyone can contribute and everything is visible. If the knowledge monopoly is the normal case even there, nobody should assume it looks better inside a closed engineering department. The only difference is that you cannot measure it there. You find out at the resignation.
(Sources: Avelino, Passos, Hora & Valente (2016), A Novel Approach for Estimating Truck Factors, ICPC, 1-10; Avelino, Constantinou, Valente & Serebrenik (2019), On the abandonment and survival of open source projects, ESEM.)
Why dissolving it so often fails on non-technical questions
When knowledge transfer requires a relocation, the technical question is not what decides. Bhaskar-Shrinivas, Harrison, Shaffer and Luk published a meta-analysis in the Academy of Management Journal in 2005 covering more than 50 determinants and consequences of adjustment on international assignments, drawing on data from 8,474 expatriates across 66 studies.
Non-work environment features are explicitly among the determinants they examined. And adjustment itself measurably affects job satisfaction, withdrawal cognitions and performance. Translated: whether somebody goes, and whether it works, is decided to a considerable extent outside the job. That is almost never the subject of conversations about knowledge transfer. Anyone building up Slovakia, India or another site should turn that around.
(Source: Bhaskar-Shrinivas, P., Harrison, D. A., Shaffer, M. A. & Luk, D. M. (2005), Input-based and time-based models of international adjustment, Academy of Management Journal, 48(2), 257-281)
And what an unresolved monopoly actually costs
The visible bill arrives at the resignation: replacing a senior engineer costs 150 to 200 percent of annual salary. The invisible one runs beforehand. Sidney Yoshida’s Iceberg of Ignorance holds that the top layer of a company knows only a fraction of its actual problems, around four percent. A knowledge monopoly amplifies exactly that, because every question on a topic ends at one desk and gets answered there. What never reaches a room can never be examined.
(Sources: replacement cost per PLOS ONE and Accenture; Sidney Yoshida, Iceberg of Ignorance.)
Voices From Practice
Prashant Chaudhari worked at Brose in test automation and later became a client. His feedback sits here because it names the capability this article turns on: making complexity into something other people can work with.
“Andy is a fantastic trainer who knows how to make complex ideas simple and engaging. His practical approach and strong communication skills make him a highly effective coach and advisor.”
Prashant Chaudhari, Analyst Software Engineering
Which Monopoly Do You Have, and What Is Really Behind It?
Two questions. First, what this one person holds, so that the cost becomes concrete. Then, what you believe has held them back so far, and the options deliberately include more than job security and ego. If you do not know, the last answer is the honest one and also the best starting position. No points, no grade.
Think of the one person without whom something important stops. What do they hold?
Why has this person not passed their knowledge on so far?
Five Steps That Actually Dissolve a Knowledge Monopoly
These five steps sit in this order deliberately. Anyone starting at step four, meaning the handover itself, fails on the first three without ever learning why.
Step one: ask before you demand
The first question is not what this person should hand over. It is what they would need for this to be good for them. Then listen without negotiating. In most cases something comes back that you did not expect, and in many cases it has nothing to do with knowledge at all.
Step two: settle the practical conditions before you discuss content
Time, location, travel, leave, language, obligations outside work. In our case those were the questions that actually decided it. While they remain open, every conversation about content is premature, because your counterpart is still mentally at the forest back home.
Step three: make an agreement that holds
Not a rule but a commitment with something in return. I gave leave whenever it was needed, and the agreement held on both sides. The value does not sit in the content but in the reliability. A commitment that collapses at the first calendar conflict costs you more trust than it ever saved in time. How to phrase such agreements so they hold sits in the article on goal setting.
Step four: hand over through questions, not through answers
This is the method that worked in Prievidza. The expert answers questions with questions, asks for routes to a solution, and intervenes only when the direction is entirely wrong.
It takes longer at the start and it is the only way the receiving team builds judgement rather than collecting answers. Supply the answers instead and you end up with a library of solutions and nobody who can find the next one.
Step five: force the proof by not asking
The test is a week without access. Not as a threat but as an agreed exercise: for that week no question goes to them. What stalls is your list of outstanding handovers. What runs has been handed over. Everything else is an assumption, and assumptions hold until the first sick note.
And what you should not do
Order a blanket documentation mandate. It produces documents nobody reads, because what matters is not in them: judgement, context, and knowing whom to call when. What belongs in a document does belong there, and I described that separation in the article on building a mentoring programme. Documentation is simply never the answer to a knowledge monopoly. It is the answer to an entirely different question.
You leave with a phrasing you can use, not with a proposal.
Where the Conversation Alone Is Not Enough
Some knowledge monopolies are not a people problem but a structural one. If your site only executes what gets decided elsewhere, the monopoly forms systematically, and you are working on the extended workbench. Where terminology is renegotiated between sites on every call, you are paying the translation tax. If your units do not talk to each other, silo thinking is the bigger problem. And if one resignation endangers your start of production, the cause is rarely the resignation but the dependency nobody addressed before it.
Livia Vieriu took part in one of my trainings. Her feedback sits here because clarity is the actual transfer capability: knowledge only the sender understands has not been passed on.
“Andy is an excellent trainer who really knows what he's talking about and explains everything very clearly. The training is definitely valuable for both your professional career and your personal growth.”
Livia Vieriu
How knowledge transfer can be secured structurally sits in mentoring for team leads and in intercultural mentoring. Terms from this article are defined in the leadership glossary, and the full toolkit sits in the methods overview.
FAQ: Frequently Asked Questions About Knowledge Silos
Q1: What is a knowledge silo or knowledge monopoly?
A situation in which a critical capability or a critical piece of knowledge effectively sits with one person only. Software engineering measures this as the Truck Factor, the minimal number of people whose loss brings the work to a halt. In 46 percent of the GitHub projects studied that value is one.
Q2: Why does a documentation mandate not work?
Because it addresses the symptom. It produces documents about what was describable anyway and leaves out exactly what constitutes the monopoly: judgement, context and network. And it never answers the question of why the person has not passed anything on so far.
Q3: What really stops experts from sharing?
More often than assumed, practical reasons: no time alongside the day job, a receiving team that is not ready, or life circumstances when the handover depends on relocation. Job security and ego exist too, they are simply suspected far more often than they apply.
Q4: How do I spot a knowledge monopoly before it becomes a problem?
From three signals. On a given topic the same name always comes up. That person rarely takes extended leave, or it is noticeable when they do. And nobody except them can say why an older decision was made the way it was.
Q5: Is a Truck Factor of one always a problem?
Not equally everywhere. On a secondary product at the end of its life cycle it is defensible, on a running series it is not. What decides it is what happens if that person is out for three weeks, and what happens if they resign.
Q6: How long does it take to dissolve a knowledge monopoly?
Longer than planned, because handing over through questions costs more time at the start than doing it yourself. Count in months rather than weeks, and measure it not in documents but in whether tasks get completed without a query coming back.
Q7: What if the expert is about to leave?
Then the order changes. Secure first what would otherwise be lost entirely, meaning customer relationships and decision history, and only then the technically describable material.
And say openly that this is about the time afterwards. Somebody who is leaving anyway has no reason left to block, but no reason to make an effort either if nobody asks them.
Q8: How do I persuade somebody to move to another site?
Not through the assignment alone. Ask about surroundings, travel, leave, language and obligations at home, then make an agreement you will actually keep. The meta-analysis by Bhaskar-Shrinivas and colleagues across 8,474 expatriates shows that non-work conditions help determine whether an assignment succeeds.
Q9: Should the expert be the mentor?
If they can be, yes, and that capability is not a given. What is needed is not the strongest technically but the person who can explain their own decisions and withhold answers. Anyone who only supplies solutions extends the monopoly into a second person.
Q10: What if I am the knowledge monopoly myself?
Then start with yourself and the same question: what would you need for the handover to be good for you? And then say it to your manager. Being the only person who can do something does not make you irreplaceable, it makes you unpromotable, because you cannot be taken out of that position.
Q11: How does this connect with leading without authority?
Very directly, because in a matrix you usually cannot instruct the expert at all. What remains is the route through conditions and something in return. More on that in mentoring without authority.
Q12: Is this still worth it when so much is being automated?
Precisely then. What can be described is increasingly retrievable, and what remains is exactly what constitutes the monopoly: judgement, context and network. Those parts grow in value rather than shrinking.
About the Author: The Intersection of Three Worlds
Most providers are either a coach or a consultant. They know knowledge transfer as a concept, not as a coffee conversation that turns out to be about a forest in Germany. I have worked in all three worlds.
Executive leadership: 25+ years of operational automotive DNA, 150 million euro of revenue accountability, an engineering site with 40 engineers built from a greenfield. Executive coaching: ICF PCC certified, more than 1,000 coaching hours.
Intercultural transformation: four years as the accountable leader in Slovakia, two years in Pune, alongside experience in Germany, China, Mexico and the United Kingdom.
The team in this article still delivers today, and the handover started with a question about holiday periods. More about the path is on the page about Andy Balbus and in the case studies.
Results or Excuses?
As long as the person is there, the knowledge monopoly costs you nothing. It costs you everything on a single day, and you do not get to choose that day. Replacing a senior engineer runs at 150 to 200 percent of annual salary, and that is the cheap part of the bill. The expensive part is the decision history nobody can reconstruct, which is why old mistakes get made a second time.
In 30 minutes we name your largest knowledge monopoly, work out which barrier is probably really behind it, and you leave with a question you can put to that person this week. I bring the view from leadership, coaching and cultural change at the same time.
At the resignation it is too late for this conversation: a 30-minute Reality Check
One calendar link, no preparation required.
You can also reach me through the contact page. How the formats connect is visible in Accelerate Now, in executive coaching, in coaching for automotive leaders, in the legacy programme for owners and in Your Power Within. For the role change there is mentoring from expert to leader and for strategic influence mentoring at director level.
To work structurally, use the team charter workshop, the SMART method, prioritisation, uncompromising delegation, active listening, the conflict architecture, the Gemba Walk and remote leadership. To dig into root causes, start with micromanagement, psychological safety, the Indian yes and the chief firefighter syndrome.
Systematic Leadership does not end with a phone Call.
Follow Andy for more Perspectives and Insights.
Leave a Reply