What Happens When Only One Person Knows How the Process Works?
Every organization has one.
The employee who knows exactly how the monthly report is built.
The person everyone calls when a system stops working.
The team member who knows which spreadsheet is actually accurate, which vendor to contact, which approval really matters, and which step in the official process everyone quietly skips.
When something goes wrong, someone inevitably says:
“Ask them. They know how it works.”
At first, having an employee with that level of knowledge can feel like an advantage. They are experienced, dependable, and capable of solving problems that others cannot.
But there is a difference between having a valuable expert and building an operation that depends entirely on one person.
When critical business knowledge exists primarily in an employee's memory, that employee becomes a single point of failure.
And that creates an operational risk many organizations do not recognize until the person is unavailable.
The Employee Everyone Depends On
Consider a situation that happens in businesses every day.
An employee takes a week off.
Nothing unusual has happened. They planned the vacation months ago, their calendar is blocked, and everyone knew they would be gone.
Then Monday arrives.
A customer asks a question that nobody else knows how to answer.
Someone needs to run a report but cannot find the correct file.
An automated process fails, and nobody knows how it was configured.
A vendor sends an invoice that looks different from normal, but the only person who understands the agreement is unavailable.
By Wednesday, someone is texting the employee on vacation.
The problem isn't that the employee took time off.
The problem is that the business could not operate normally without them.
Now imagine the same situation lasting longer.
What happens if that person gets sick?
What happens if they are promoted?
What happens if they unexpectedly resign?
What happens if the company doubles in size and that employee can no longer personally answer every question?
These scenarios expose something important:
The organization does not actually own the process. The employee does.
How Businesses Become Dependent on One Person
Most organizations do not intentionally create this situation.
It happens gradually.
An employee learns how to perform a task.
Then they encounter an exception and learn how to handle that too.
A system changes, and they figure out a workaround.
A customer has a special requirement, so the employee remembers it.
A vendor has an unusual procedure, so the employee learns that as well.
Over time, that person accumulates hundreds of small pieces of operational knowledge.
Some of it may be documented.
Much of it isn't.
Eventually, the employee knows not only what to do but also all the unwritten details that make the process work.
They know:
- Where information is stored
- Which version of a file is current
- Who needs to approve something
- Which customers require special handling
- How to correct common errors
- Which reports need manual adjustments
- What to do when a system fails
- Which vendor contact responds fastest
- Which steps in the documented process are outdated
- Which exceptions occur frequently enough to matter
None of those pieces of information may seem significant by themselves.
Together, they can represent an enormous amount of organizational knowledge.
The danger is that the business may not realize how much knowledge has accumulated in one place.
The “Bus Factor” Problem
Technology and project management teams sometimes describe this risk using a concept called the bus factor.
The idea is simple: How many people could suddenly become unavailable before a project or process could no longer continue?
The name is intentionally dramatic, but the underlying question is valuable.
For a critical business process, what happens if the person who normally performs it is unavailable tomorrow?
If the answer is:
“We would have a serious problem.”
Then the organization has identified an operational vulnerability.
The cause does not need to be dramatic.
People take vacations.
Employees get promoted.
Responsibilities change.
People retire.
Teams reorganize.
Employees accept opportunities at other companies.
A resilient organization should be able to absorb those normal changes without losing the ability to perform essential work.
Your Best Employee Can Also Be Your Biggest Operational Risk
This is where the issue becomes uncomfortable.
The employee creating the risk may be one of the best employees in the company.
They are often the person who solves problems quickly.
They know the customers.
They understand the systems.
They remember the history behind decisions.
They can fix issues without escalating them.
Leadership trusts them.
The problem is not the employee.
The problem is how the organization has structured knowledge around that employee.
In fact, highly capable employees can unintentionally hide weak processes.
Because they know how to navigate every exception and workaround, the process appears more reliable than it actually is.
The employee becomes the bridge between disconnected systems, incomplete documentation, unclear responsibilities, and inconsistent procedures.
As long as that person is available, everything works.
Remove them from the process, and the weaknesses suddenly become visible.
That is why operational resilience cannot depend solely on having great people.
Great people need great systems around them.
The Hidden Costs of Knowledge Silos
The most obvious risk is business interruption, but concentrating knowledge in one person creates several other costs.
1. Decisions Slow Down
When only one person can answer certain questions, everyone else has to wait for them.
A simple request can sit for hours or days because the person with the necessary knowledge is busy, in a meeting, traveling, or working on something more urgent.
The employee becomes a bottleneck even if they are extremely productive.
2. Employees Cannot Work Independently
Teams become conditioned to ask the expert instead of solving problems themselves.
Over time, this creates dependency.
Instead of knowledge spreading throughout the organization, more and more questions flow toward the same person.
That makes the problem worse.
3. Growth Becomes Difficult
A process that depends on one experienced employee may work well at a small scale.
But what happens when the company grows?
If transaction volume doubles, customer volume doubles, or the team expands, the expert cannot necessarily double their availability.
Eventually, the organization reaches a capacity limit.
The process cannot scale because the knowledge required to operate it has not scaled.
4. Training Takes Longer
New employees struggle when processes are poorly documented.
Instead of learning from a repeatable system, they learn by shadowing someone else.
That creates inconsistent training.
One employee learns one version of the process. Another learns something slightly different. Important details may be communicated verbally and forgotten.
The company gradually develops multiple ways of performing the same task.
5. Improvement Becomes Harder
You cannot easily improve a process you cannot clearly see.
When important steps exist only in someone's memory, leadership may not understand how the process actually works.
That makes it difficult to identify bottlenecks, measure performance, introduce automation, or redesign the workflow.
Before a process can be improved, it must first become visible.
Documentation Is More Than Writing Instructions
When organizations recognize this problem, the immediate response is often:
“We need better documentation.”
That is true, but documentation alone is not enough.
A 40-page procedure nobody reads does not create operational resilience.
Neither does a folder filled with outdated instructions.
Useful documentation should help another capable employee understand and perform the process without relying constantly on the original expert.
For many processes, that means documenting several things.
The Purpose
Why does this process exist?
Understanding the objective helps employees make better decisions when something unexpected happens.
The Trigger
What starts the process?
Is it a customer request? A date? A transaction? A system notification?
The Steps
What actually happens from beginning to end?
This should reflect reality—not the process everyone thinks is happening.
Ownership
Who is responsible for each part?
Clear ownership prevents tasks from disappearing between departments or employees.
Systems and Information
What tools, files, reports, or data are required?
Employees should know where the source of truth lives.
Exceptions
What happens when something does not go according to plan?
Exceptions are often where the most valuable institutional knowledge exists.
Escalation
When does someone need help, and who should they contact?
Good documentation reduces unnecessary questions without pretending every situation can be predicted.
Start With the Processes That Matter Most
Trying to document every activity in a company at once is usually unrealistic.
Instead, prioritize.
Ask:
Which processes would cause the most disruption if the person responsible for them were unavailable tomorrow?
Those are the processes to address first.
A simple exercise can reveal a great deal.
List the organization's critical recurring processes.
Next to each one, identify:
- The primary person who knows the process
- A backup person who could perform it
- Whether current documentation exists
- Where that documentation is stored
- The systems required
- The impact if the process stopped for a day, a week, or a month
Patterns will quickly appear.
You may discover that several critical processes depend on the same person.
You may find processes with no backup owner.
You may discover documentation that has not been updated in years.
You may even find processes leadership did not realize existed.
That is valuable information.
Cross-Training Turns Knowledge Into Capability
Documentation captures knowledge.
Cross-training turns that knowledge into organizational capability.
There is a major difference between reading instructions and actually performing a process.
A backup employee should occasionally complete the task while the primary employee is available to answer questions.
That does two things.
First, it proves whether the documentation actually works.
Second, it exposes all the small details the original employee may have forgotten to document because those details have become automatic to them.
One of the best tests of a process is simple:
Can someone else successfully perform it using the documentation provided?
If not, the process is still dependent on tribal knowledge.
Stop Rewarding Heroics as a Business Model
Many organizations unintentionally reward operational dependency.
An employee solves an emergency at 10 p.m., and everyone celebrates their dedication.
Someone answers questions throughout their vacation, and leadership praises their commitment.
A manager personally reviews every important transaction because “nothing gets through without them.”
These employees may genuinely deserve appreciation.
But repeated heroics can also signal a system problem.
A healthy organization should not require its best employees to rescue routine processes constantly.
The goal should be to make exceptional effort necessary for exceptional situations—not normal operations.
If the same person repeatedly saves the day, the better question may be:
Why does the day keep needing to be saved?
Technology Can Help—After the Knowledge Is Captured
This issue is particularly important as organizations adopt automation and artificial intelligence.
Businesses often want to automate processes that are heavily dependent on experienced employees.
But automation requires clarity.
If nobody can explain the process except the person who has performed it for ten years, the organization is not ready to automate it.
First, capture the knowledge.
Map the workflow.
Identify the decisions being made.
Understand the exceptions.
Clarify where information comes from and where it needs to go.
Then technology becomes much more useful.
Automation can handle repeatable steps.
AI can make documented knowledge easier to search and access.
Workflow systems can assign ownership and track progress.
Knowledge management platforms can make procedures available across teams.
Dashboards can show whether processes are operating as expected.
But technology should distribute and strengthen organizational knowledge—not simply create a more sophisticated version of the same dependency.
Protect Your Experts by Making Them Less Essential
This may sound counterintuitive, but reducing dependency on an expert actually makes that employee more valuable.
If a highly experienced employee spends much of their day answering routine questions, fixing recurring mistakes, and helping others navigate undocumented processes, the organization is not getting the highest value from their expertise.
Documenting and distributing their knowledge frees them to focus on more important work.
Instead of repeatedly explaining how the current process works, they can improve it.
Instead of correcting the same problem every week, they can eliminate the root cause.
Instead of being the only person capable of completing a task, they can train others and take responsibility for more strategic work.
The objective is not to make experienced employees replaceable.
It is to make their knowledge reusable.
That is a major difference.
Build an Organization That Can Operate Without Heroes
Strong businesses need talented people.
But strong operations should not depend on any one person being available every day.
Processes should be visible.
Responsibilities should be clear.
Knowledge should be documented.
Critical activities should have backup owners.
Employees should be cross-trained.
Systems should make information accessible to the people who need it.
And when someone takes a vacation, the organization should be able to let them actually take a vacation.
That is not bureaucracy.
It is operational resilience.
Sometimes the most important operational question is not:
“Who knows how to do this?”
It is:
“What happens if they aren't here tomorrow?”
If the answer makes you uncomfortable, you have probably found a process worth improving.