Breaking The Bottleneck - Episode 3: The Three Root Causes and Why Generic Solutions Fail
This article is Part 3 of "Breaking the Bottleneck," an 8-episode series on key person dependency risk and organizational resilience.
In this episode, we explore the three root causes of key person dependency: why it forms, how it gets perpetuated, and why most attempts to fix it fail without addressing the root cause.
Previous episodes in this series:
Next episode: "Which Path Are You On? The Three Implementation Realities" is coming soon.
Here's what usually happens when an organization realizes it has a key person dependency problem.
The leadership team panics. They decide to fix it. They implement "solutions":
"Let's document everything in Confluence"
"Let's cross-train people"
"Let's require people to write down their processes"
Three months later, nothing has changed.
The key person is still indispensable. The documentation is gathering dust (nobody reads it). The cross-training didn't stick (people went back to calling the key person when they hit a problem). The organizational dependency is exactly as strong as it was before.
Why did the solution fail? Because they were treating the symptom, not the disease.
Key person dependency isn't created randomly. It's created by three specific organizational failures. Until you address the root cause, any solution will fail.
Root Cause #1: Leadership Didn't Create a Cross-Training Culture
When people are cross-trained, they understand how their role fits into the broader system. They can make better decisions faster because they have context. They can cover for each other without escalating every decision. They can grow into new roles. Cross-training is the antidote to key person dependency.
But here's the problem: most organizations don't have a cross-training culture.
Why? Because cross-training is usually seen as:
A nice-to-have, not a must-have
Someone's side project, not a core responsibility
An extra burden on already busy people ("now you're doing two jobs")
A threat to job security ("if I train someone else, I'm replaceable")
When leadership doesn't prioritize cross-training, it doesn't happen. And when it doesn't happen, knowledge concentrates in the person who knows how to do the work.
The Leadership Failure
The real failure here is that leaders don't create the conditions for cross-training to succeed. They don't:
Allocate time for cross-training: it gets deprioritized when you're busy
Provide resources to make it systematic: no tools, no structure, no follow-up
Recognize people who learn new skills, so there's no incentive
Address the psychological concerns: people fear being replaced, so they resist
Follow up after cross-training ends: skills get rusty if not used
When cross-training happens in a vacuum (without leadership support, resources, or incentives), it fails. People go through the motions, but they don't internalize the knowledge. When the original person leaves, the cross-trained person struggles because they never had the context or support to truly master the role.
Why This Creates Key Person Dependency
Without cross-training, critical knowledge stays with the person who developed it. That person becomes the only person who can execute that work reliably. They become indispensable.
And once they're indispensable, cross-training becomes even harder: the person is too busy to train anyone, and there's no time in the schedule for others to learn.
Root Cause #2: Knowledge Wasn't Documented, and There's a Reason Why
Documentation sounds like the obvious solution to key person dependency. "Just document everything. Then anyone can do the work." Except it's more complicated than that.
The Documentation Problem
First, let's be clear: most organizations don't document their processes well:
Critical processes exist only in people's heads
When people do document, the documentation is outdated within weeks
Documentation is often created by people who are too close to the process. They skip the "obvious" steps that aren't obvious to anyone else
Nobody reads the documentation (it sits in a wiki that nobody knows about)
When documentation does exist, people don't trust it or follow it
But the real question is: why doesn't documentation happen?
The Real Reason Documentation Fails
There are three reasons documentation doesn't happen in organizations with key person dependency:
Time pressure: when you're growing fast and the key person is handling everything, there's no time to document. It feels like wasting time when there's urgent work to be done ("It's faster to just do it than to document it");
Psychological resistance: people resist documenting their work because, consciously or unconsciously, they believe documentation threatens their job security. "If I document this, someone could do my job. If someone can do my job, I'm replaceable." Documentation becomes an act of self-preservation to avoid;
Structural incentives: documentation often isn't incentivized. Your performance reviews don't measure whether you documented your work. Your bonus doesn't depend on it. Your promotion doesn't require it. So documentation gets deprioritized. Always.
Why This Creates Key Person Dependency
Without documentation, knowledge lives in people's heads. When that person leaves, the knowledge leaves with them. New people have to figure things out from scratch. That's why onboarding takes 6 months instead of 6 weeks. That's why mistakes happen. That's why you need to hire the person back as a consultant because nobody else can do what they did.
And when a key person realizes how valuable their undocumented knowledge is, they have even less incentive to document it. It's their security blanket.
Root Cause #3: Processes Aren't Standardized, so Individual Judgment Becomes Critical
Here's a subtle but critical issue: in many organizations, the same task is done differently depending on who's doing it. There's no standard way to process a customer request. There's no standard way to close a deal. There's no standard way to handle an exception. Each person has their own method.
When processes aren't standardized, individual judgment becomes critical. The key person is the key person because they know which judgment calls to make, which exceptions to approve, which shortcuts are safe to take. This creates massive dependency.
The Standardization Problem
When processes aren't standardized:
New employees can't learn from the process, as there is no process to learn
Decisions are inconsistent because different people make different calls
Quality is unpredictable, as it depends on who's handling it
One person becomes the expert in making judgment calls, so they become indispensable
Cross-training doesn't work, since you can't cross-train someone on a process that doesn't exist
Documentation doesn't work: how do you document judgment calls?
The real failure here is that leadership didn't invest in process design. They didn't define standard ways of working. They let processes emerge organically, which means they're inconsistent, messy, and concentrated in individual people's heads.
Why This Creates Key Person Dependency
Without standardized processes, the organization becomes dependent on the people who understand the nuances, the exceptions, the judgment calls. These people become indispensable because they're the only ones who "know how things work around here."
And when that person leaves, everything becomes chaotic because nobody else knows how to make those judgment calls.
Why Generic Solutions Fail
Now let’s get to the core insight: most organizations try to fix key person dependency by implementing generic solutions without addressing the root cause.
They implement documentation tools (Confluence, Notion) without creating a documentation culture. People don't use the tools. Documentation is created but not maintained. It becomes a graveyard of outdated information.
They implement cross-training programs without addressing psychological barriers. People go through the motions but don't truly learn. Skills get rusty because there's no follow-up. When the original person leaves, the cross-trained person struggles.
They implement process standardization projects (Six Sigma, business process optimization) without creating a culture that values standardization. People resist the new processes because they feel too rigid. They revert to their old ways.
The Fundamental Mistake
The mistake is treating key person dependency as a technical problem when it's actually a systemic and cultural problem. You can't fix a systemic problem with a tool. You can't fix a cultural problem with a process. You need to address both the systems and the culture simultaneously.
This requires:
Leadership commitment to cross-training. Not just a mandate, but time, resources, and incentives
A culture that values documentation: leadership models it, people are rewarded for it, it's part of daily work
Standardized processes that are regularly reviewed and improved, not imposed from the top, but co-created with the people doing the work
Psychological safety so people don't fear being replaced
Without these, any solution will fail.
The Vicious Cycle
Here's how the three root causes create a self-perpetuating cycle:
Leadership doesn't create a cross-training culture, so knowledge stays with individuals
Because knowledge is concentrated, documentation seems unnecessary (the key person knows it all)
Because processes aren't standardized, the key person's judgment becomes critical
So the key person becomes more indispensable
So they're even busier
So there's even less time for cross-training or documentation
Cycle repeats
And the organization gets stuck in a death spiral where key person dependency deepens over time.
How Organizations Accidentally Create Key Person Dependency
It's important to note: most key person dependency is created accidentally, not intentionally.
It happens when:
A crisis occurs and the most capable person steps up and solves it. They become the hero. They solve the next crisis too. And the next. Until they're the crisis solver
The organization grows faster than the systems can keep up. Documentation seems like a distraction when you're growing 200% YoY. Standardization seems unnecessary when everyone "gets it." Cross-training seems like a luxury when you're understaffed
Leadership is focused on revenue and growth, not on organizational resilience. So they don't prioritize the unsexy work of documenting, standardizing, and cross-training.
People are hired for their individual capabilities, not for their ability to build systems and scale. So they do the work themselves instead of creating structures that allow others to do the work.
None of this is malicious. It's just the natural result of growth without intentional design.
The Path Forward
Understanding the three root causes is the first step. But the real work is addressing them. And here's where it gets specific: the solutions look different depending on your organizational context.
A startup with 30 people needs a different approach than a 500-person company. A low-tech organization needs a different approach than a high-tech one. A company in crisis needs a different approach than a company in stable growth.
That's why generic solutions fail. The solution needs to be tailored to your specific situation, your specific root causes, and your specific organizational culture.
In the next episode, we'll identify which path you're on. Then in episodes 5, we'll provide specific, implementable solutions for your context.
Reflection: Which Root Cause Is Strongest in Your Organization?
Before moving to the next episode, ask yourself:
Do you have a strong cross-training culture? Or does cross-training happen ad hoc when there's time?
Is your organization good at documentation? Or does critical knowledge live in people's heads?
Are your processes standardized? Or does each person do things their own way?
If you answered "no" or "sort of" to these questions, you've identified your root causes. Now you know why generic solutions have failed. Now you're ready for solutions that actually work for your situation.
Ready to Diagnose Your Root Causes?
If you want to understand which of the three root causes is strongest in your organization, I offer a free 30-minute consultation to assess your specific situation and identify where to focus your efforts.
In the next episode of the series
The next episode, "Which Path Are You On? The Three Implementation Realities," helps you identify your organizational context (startup, established low-tech, or established high-tech). This determines which solution approach will work best for you.
Follow me on LinkedIn or subscribe to ONUS Advisory updates to be notified when the next episode is released.
About Francesco Malmusi
I'm a founder and C-level operator. One of the most common mistakes I see organizations make is trying to implement generic solutions to key person dependency without addressing the root cause. Understanding your root causes is the first step toward building organizational resilience that actually lasts.
If you want to break the bottleneck in your organization, let's start by understanding what's really driving the dependency.