I’ve seen how easily knowledge accumulates around one person in a business.

They know which spreadsheet needs updating, how to handle an unusual enquiry, who needs to approve a particular decision and which workaround gets a system to behave when the documented process doesn’t quite work. None of that knowledge necessarily appears unusual when you’re close to it. It simply becomes part of how the job gets done.

Over time, that accumulation can quietly make the business dependent on one person’s knowledge without noticing it.

The process appears to work.

From the outside, everything may look reasonably reliable. Work gets completed, customers are looked after, and problems are dealt with when they arise.

What is harder to see is how much of that reliability depends on one experienced person knowing what to do when the normal process isn’t enough.

They know a particular customer needs handling differently, remember which piece of information needs correcting before it goes into another system, and know who to chase when an approval is late or which unofficial step avoids a problem further down the workflow.

That is why the process can appear robust: the person has learned how to compensate for its weaknesses.

Absence reveals the dependency.

You often discover how much operational knowledge has accumulated around somebody only when they’re not available.

Another employee may understand the role perfectly well and still take much longer to move the work forward. They know the formal process, but they haven’t accumulated all the exceptions, shortcuts, and judgement calls that have developed around it.

Questions start moving backwards and forwards between people, approvals take longer because nobody is quite sure who normally handles an exception, and customers may wait while someone works out what happens next.

In some businesses, this becomes the norm. Certain tasks take longer when a particular employee is on holiday or off sick.

That is a useful signal.

Good employees can hide weak processes.

I think this distinction matters when assessing how well a business operates.

An experienced employee who knows the business inside out can make an imperfect process look much stronger than it really is. Their knowledge, relationships, and judgement fill gaps that the documented workflow, systems, or training do not cover.

That is valuable to the business, but it can also hide risk in the process.

If nobody documents what that person knows, the organisation becomes dependent on their continued availability. Training new employees becomes harder because much of the job can only be learned through experience. Growth can also become more difficult because the process is hard to replicate consistently across a larger team.

None of that means the employee is the problem. In many cases, their capability is the reason the problem hasn’t caused more disruption.

The risk is bigger than holidays.

Key-person dependency is sometimes treated mainly as a continuity issue: what happens if somebody is away unexpectedly?

That matters, but the impact can extend beyond continuity.

If a workflow depends heavily on one person’s knowledge, they can become the default route for questions and approvals even when they are present. Other employees may hesitate to make decisions because they know the experienced person will have the answer, so work moves at that person’s speed.

The same dependency might make delegation difficult. Managers may believe they've handed over a process, only to find the original owner still being pulled back into exceptions and decisions throughout the day.

As the business grows, that can become a genuine capacity constraint.

Documenting the process is only part of the answer.

It can be tempting to solve this by writing more documentation.

That can certainly help, but I don’t think the answer is to produce a longer process manual. The first job is to understand why so much knowledge had to accumulate outside the formal process in the first place.

Perhaps the system does not cope well with common exceptions. Maybe approvals are unclear, data regularly arrives in the wrong format, or the documented process was designed years ago and no longer reflects how the business operates.

If employees have developed workarounds, those workarounds contain useful information. They show where the official workflow has failed to accommodate reality.

For that reason, capturing knowledge needs to go hand in hand with improving the process itself.

Look at where the knowledge lives.

When I review a critical workflow, one thing I want to understand is how much of it exists within the business and how much exists only in the heads of the people who have learned how to make it work.

Can another competent employee follow the process without constant assistance? Are exceptions handled consistently? Is important information stored somewhere accessible, or does everyone know who they need to ask?

Those questions help distinguish a genuinely repeatable process from one that works only because the right person is currently holding it together.

The goal is not to reduce the value of experienced employees. Their judgement and knowledge can be some of the most valuable assets in the business.

Instead, aim to make sure routine work does not depend on undocumented knowledge.