How to Manage Key Person Dependency?

On a Friday morning, one person is missing, yet order processing comes to a halt. This person knows which Excel file is current, how to correct erroneous webshop orders, who to call in case of late delivery, and what exceptions can be allowed in billing. The others are good professionals, but they can't move forward without them. When we ask how to manage key person dependency, it's not about one person's performance. It's about eliminating an operational risk that the company's growth has often built up over years.

The presence of a key person is valuable in itself. Many organizations need experienced colleagues who recognize exceptions, understand customer histories, and make responsible decisions in uncertain situations. The problem begins when a repetitive, business-critical process relies solely on their personal knowledge, access, or connections.

Key person dependency is not an HR issue

It's easy to treat the situation as a workforce issue: you need a substitute, a more detailed job description, or more training. These can be useful elements, but they rarely solve the root cause. Dependency usually arises at the intersection of process, information, and responsibility.

For example, a buyer is indispensable because they know which supplier price list is valid and keep track of product codes that differ from those in the ERP. Not necessarily because they don't want to share their knowledge. It may be that the system lacks data, price lists arrive via email, and they have developed their own control methods for each exception.

The same happens in production when a shift leader knows how to adjust the plan to actual capacities. Or in e-commerce, when a colleague manually reconciles webshop, inventory, and courier data daily. In such cases, the person doesn't just do the work: they become the integration between systems and process control.

The business consequence is not just the risk of absence. Turnaround time slows, substitution is uncertain, managerial time spent on oversight increases, and expansion becomes more difficult. It's also a burden for the key person: they get called during vacations, can't delegate tasks, and are constantly the last escalation point.

How to manage key person dependency starting from the actual process?

The first step is not to create a knowledge base or acquire a new system. First, understand what actually happens in the course of a case, order, manufacturing task, or invoice. Not as it appears in the regulations, but as employees perform it day by day.

It's worth choosing a specific, high-impact business process. This could be the process from order receipt to delivery, approval of a purchase request, modification of a production plan, or compilation of a monthly management report. Follow the path of a real case and see where others have to stop waiting for a particular colleague's decision, file, or access.

During the investigation, it's not enough to ask who does what. The critical questions are more like: where does the information come from, where is it re-recorded, who checks it, what exceptions occur, and what happens if the person is unavailable for a week? Often, it turns out that key person dependency is not due to a single task but several smaller, interdependent informal solutions.

Separate expertise from hidden routines

Not all person-bound knowledge needs to be standardized. A seasoned salesperson's negotiation sense or an engineer's problem-solving ability is genuine expertise that can't be captured in a flowchart. The goal is not to make every decision mechanical.

However, it's a different category if someone is unique because they know the shared drive's folder structure, have the passwords, know which email to extract data from, or are the only one who can initiate a monthly data compilation. These are not strategic capabilities but operational vulnerabilities.

It's useful to categorize every critical step into three groups: decisions requiring professional judgment, tasks executable by clear rules, and exceptions that are difficult due to incomplete or contradictory information. This distinction helps avoid unnecessary documentation while keeping real risks hidden.

Knowledge transfer should be usable in the work environment

Long, rarely updated procedure descriptions provide little protection on their own. A substitute needs to find the necessary data, decision rules, and responsible parties at the moment of the process. This could be a short work instruction, checklist, flowchart, or a jointly used case management interface - the form is secondary.

The key is that the documentation should be sufficient to complete a real case. "Checking billing" is not an instruction. It's more useful if it records which data must match, where they can be checked, who is authorized to approve deviations, and what to do in case of an error.

It's worth validating documentation with a substitution test. Another employee should perform the task based on the description while the key person observes. If they have to ask three times where to find data or what a status means, the process is not yet transferable. This is not the substitute's fault but shows the missing information points in the operation.

Access and data are also business continuity issues

In many companies, the most critical dependency is not knowledge but authorization. Order notifications arrive at a manager's personal email address. A colleague's private authentication app is used to access a supplier portal. Only one person's admin account works for a server or business system.

These situations need to be managed in a controlled manner. Common systems should operate with organizationally owned access, appropriate authorization levels, and documented responsibility. The goal is not for everyone to access everything. On the contrary: necessary access should be available, traceable, and replaceable while maintaining security.

The same applies to data. If the order status is in the webshop, inventory in a spreadsheet, and shipping information in an email, the only accurate picture forms in the colleague's mind. First, decide which system is the data owner. Only then is it worth examining whether a data connection, shared workspace, or automated notification is needed.

Not every problem is solved by full automation

Many immediately suggest full automation to reduce key person dependency. This is sometimes justified, especially for high-volume, rule-based administration. If an employee copies data between three systems for hundreds of orders daily, the manual process not only creates dependency but also a risk of errors.

But if the process is full of poorly defined exceptions, varying customer agreements, and incomplete master data, automation only accelerates the disorder. In such cases, rules need to be simplified first, data sources clarified, and when human decision is necessary determined.

A minor change can yield significant results. It may be enough to have a unified status list, an approval point, or a shared case management view. In other cases, a lasting solution might be system integration, a custom internal application, or a transitional solution built around the old system. The right choice is determined by the process's frequency, business risk, variability, and error costs.

Make risk reduction measurable

Key person dependency doesn't disappear just because some documents are created. It's worth monitoring a few simple operational indicators: how many people can independently perform the critical task, how long it takes to activate a substitute, how many cases wait for a single approver, and how much manual data transfer occurs in the process.

For managers, a process dependency overview can be particularly telling. It's not about evaluating individuals but making visible which business processes have a single executor, decision-maker, or technical access. Thus, the risk is addressed not when someone resigns or falls ill but becomes a planned development task.

Well-managed key person dependency doesn't make experienced colleagues less important. On the contrary: it relieves them of repetitive checks and information searches, allowing them to use their knowledge where it's truly needed. In a reliable company, critical work doesn't continue in one person's memory but even when that person is not in the office.