Imagine that a trusted employee is unexpectedly unavailable on the morning a critical task must be completed.
Payroll needs to be submitted. A customer is waiting for a revised proposal. A supplier has placed an order on hold. A system is producing an error that has happened before.
Everyone knows who normally handles the problem. What nobody knows is how that person handles it.
The instructions may not be written down. The necessary login may be stored somewhere only that employee can access. Important context may exist in an email thread, a private spreadsheet, or memory. Even if a written procedure exists, nobody else has used it.
The business has not merely lost an employee for the day. It has temporarily lost part of its operating system.
This is key-person dependency: a situation in which essential work depends on the knowledge, access, judgment, or relationships held by one person. It often develops quietly, and it is especially common in small businesses where employees wear multiple hats.
The employee is not the problem. The unmanaged dependency is.
Expertise Is an Asset. Exclusivity Is a Risk.
Every business needs experienced people. A capable employee who understands the customers, systems, exceptions, and history of a process creates tremendous value.
The risk appears when the business cannot continue without that individual.
That dependence can affect more than productivity. It may delay revenue, interrupt customer service, cause missed regulatory or contractual obligations, weaken security, or force the owner to make decisions without reliable information.
The disruption does not require a resignation or a major emergency. It can begin with an ordinary vacation, illness, family emergency, promotion, or scheduling conflict.
Ask a simple question:
If this employee became unavailable tomorrow, what important work would slow down, stop, or become unsafe?
The answer reveals where valuable expertise has become an operational single point of failure.
How One Person Quietly Becomes the Process
Key-person dependencies rarely result from poor intentions. They usually grow from reasonable short-term decisions.
A new employee learns a task from the owner. Over time, that employee improves the method, handles increasingly complex exceptions, and becomes the person everyone asks for help. Because the work gets done, documenting it never becomes urgent.
Other conditions make the dependency stronger:
- The process changes faster than its written instructions.
- Access is granted only to the person who normally performs the task.
- Customer or vendor history remains in personal email and memory.
- Employees rely on private spreadsheets or notes to track exceptions.
- Cross-training is postponed because everyone is already busy.
- A backup is named but never practices the work.
- The employee becomes the unofficial help desk for a fragile system.
From the outside, the process may appear reliable. In reality, one employee is continuously compensating for missing instructions, unclear ownership, limited access, or poorly designed tools.
The business sees the person’s excellent performance. It may not see the structural weakness that performance is hiding.
A Procedure Is Not the Same as Continuity
The usual response is: “We need to document everything.”
Documentation matters, but a detailed procedure does not automatically make work transferable.
A forty-page manual may describe every screen and button while failing to explain the decisions that matter. It may omit the unusual situations that require judgment. It may be outdated, inaccessible during an incident, or understandable only to the person who wrote it.
Continuity requires more than instructions. A capable backup also needs:
- Authority to perform the work
- Secure access to the required systems and records
- An understanding of the expected outcome
- Clear decision thresholds and escalation points
- Practice handling routine work and realistic exceptions
- A way to determine whether the task was completed correctly
The real test is not whether a document exists. It is whether another authorized person can use it to complete the work safely.
Start With the Work That Matters Most
Trying to document every task at once will create unnecessary work and probably fail. Start with the activities whose interruption would have the greatest effect.
Look first at work connected to:
- Payroll and employee obligations
- Billing, collections, and cash flow
- Customer commitments and service delivery
- Purchasing and critical suppliers
- Security administration and system recovery
- Legal, regulatory, tax, or contractual deadlines
- Essential equipment, platforms, or accounts
For each activity, identify the normal owner, the backup, the required systems, the deadline, and the consequence of delay.
This creates a prioritized continuity map rather than an indiscriminate documentation project.
Build Minimum Viable Continuity
A small business does not need enterprise-level bureaucracy to reduce key-person dependency. It needs a simple system that makes essential work transferable.
1. Define the outcome
Begin with what must be accomplished, when it must happen, and how someone can confirm success. A useful procedure explains the purpose of the work—not merely the sequence of clicks.
2. Capture decisions and exceptions
Routine steps are often easy to reconstruct. Judgment is harder to transfer.
Document the thresholds that change the normal process: when an issue requires owner approval, when a customer must be contacted, when a payment should be paused, or when a technical problem should be escalated.
3. Separate business access from personal access
Critical records and accounts should not depend on an employee’s personal inbox, personal device, or individually held recovery method. Use business-controlled accounts, approved shared storage, secure password management, and appropriately assigned backup access.
This does not mean everyone should share one username and password. Access should remain attributable to individual users wherever the system permits it.
4. Assign a real backup
Writing a name next to “backup” is not enough. The backup needs sufficient authority, access, knowledge, and time to perform the task.
The primary employee should not be the only person capable of granting that access during an emergency.
5. Practice the handoff
Have the backup complete the work during a planned absence while the primary employee remains available if needed. Observe where the backup gets stuck, which assumptions were undocumented, and which permissions are missing.
This turns cross-training into a test of the process rather than a presentation about it.
6. Keep the process current
Procedures decay as systems, employees, customers, and policies change. Build updates into the work. A short review after a major change—and a periodic confirmation by the process owner—is usually more effective than an annual documentation scramble.
Do Not Punish the Person Who Kept the Business Moving
Employees sometimes resist knowledge-transfer efforts because they hear a threatening message: “We need to make you replaceable.”
That is a management failure.
The better message is: “Your expertise is important enough that the business should not depend on you being constantly available.”
Reducing the dependency can protect the employee as well as the company. It makes genuine vacations possible, reduces interruptions, creates development opportunities for other employees, and allows the expert to move into higher-value work instead of remaining permanently tied to routine problems.
The process should recognize expertise, not extract knowledge and then devalue the person who created it.
Avoid Creating New Risk While Fixing the Old Risk
Poorly designed continuity efforts can create additional problems.
Do not solve an access dependency by placing passwords in an unprotected spreadsheet. Do not grant every employee administrative rights. Do not duplicate sensitive customer information across multiple systems merely so more people can find it. Do not require so much documentation that employees stop maintaining it.
The goal is controlled redundancy:
- More than one capable person
- More than one authorized path to critical information
- Clear ownership and accountability
- Secure, business-controlled access
- Enough documentation to perform and verify the work
Resilience does not mean giving everyone access to everything. It means ensuring essential work can continue through an approved alternative when the normal person or path is unavailable.
An Eight-Question Key-Person Dependency Review
Choose one essential business process and ask:
- Who is the only person who fully understands how this work gets done?
- What happens if that person is unavailable for one day, one week, or permanently?
- Where are the instructions, records, contacts, and decision history stored?
- Can the business securely access the necessary accounts without that person?
- Which exceptions require experience or judgment that has not been documented?
- Who is authorized and prepared to act as the backup?
- When did the backup last perform the work from beginning to end?
- How will the business know the process and backup remain ready?
If the answers depend on “we would call that employee,” the business does not yet have a backup plan. It has an emergency contact.
Make Essential Knowledge a Business Capability
A small business will always depend on good people. The objective is not to remove that dependence or make every employee interchangeable.
The objective is to prevent valuable expertise from becoming a hidden point of failure.
Start with one essential process. Identify what only one person knows, establish secure access, assign a genuine backup, and test the handoff. Each completed transfer reduces operational friction during absences and gives the business more capacity to adapt when change arrives.
The strongest processes benefit from expert employees without requiring those employees to be available every time the business needs to function.
References
- Ready Business provides business continuity and preparedness resources centered on maintaining essential operations.
- NIST Special Publication 800-34 Rev. 1 describes contingency planning as a process of identifying requirements and priorities, developing recovery strategies, training personnel, and testing plans.
- CISA: Questions Every CEO Should Ask About Cyber Risks recommends establishing repeatable cross-training for risk and incident-management responsibilities.