Every organisation has people who know how work really gets done. They know which spreadsheet is current, which approval is required, where an exception should go and how to recover when a system or process fails. Their expertise is valuable. The risk appears when the business cannot operate reliably without them.
This is often mistaken for a people problem. In reality, it can be a process-design problem: undocumented decisions, unclear ownership, hidden workarounds, fragmented information and controls that exist only in someone's memory.
A resilient process makes critical knowledge accessible, repeatable and reviewable. It does not remove expertise from the people who hold it; it gives the organisation a way to retain and use that expertise consistently.
Why key-person dependency becomes an operational risk
When one person is the only reliable source of process knowledge, normal absence can become a continuity issue. Decisions wait, exceptions accumulate, quality becomes inconsistent and colleagues may create different workarounds. The organisation may appear efficient because an experienced employee quietly absorbs complexity that the formal process does not handle.
The warning signs are often visible: only one person can explain a critical workflow; approvals depend on informal relationships; teams maintain private spreadsheets; procedures are outdated; exceptions are resolved through direct messages; or performance drops sharply when a particular colleague is unavailable. These signals do not mean the employee is doing anything wrong. They indicate that the process relies on undocumented knowledge.
How to identify the points of dependency
Start with critical customer, operational and control processes. For each one, identify the decisions, systems, hand-offs and exceptions that must work for the outcome to be delivered. Ask more than whether a procedure exists: can another trained colleague follow it, understand the decision criteria and recognise when to escalate?
- Knowledge dependency: one person understands the rules, context or exception logic.
- Access dependency: only one person can reach a system, file, mailbox or approval route.
- Decision dependency: work stops because authority or criteria are unclear.
- Relationship dependency: progress relies on informal contacts rather than a defined hand-off.
- Recovery dependency: only one person knows how to resolve failures or restore normal service.
Turn individual expertise into organisational knowledge
Document the process while the expert is involved. Capture the purpose, trigger, inputs, sequence, decision rules, exceptions, controls, system dependencies, owner and escalation route. Use real cases to test whether the instructions are clear. A procedure that describes only the happy path will not protect the organisation when an unusual case arrives.
Then introduce practical knowledge-sharing: paired execution, shadowing, reverse-shadowing and periodic cross-training. The person learning the process should perform it while the expert observes, then explain the steps and decision points back. This exposes gaps that a document review alone may miss.
Measure whether the process is becoming more resilient
Track the number of critical activities with at least two capable trained operators, the age of unresolved exceptions, rework, hand-off delays and the proportion of procedures that have been tested recently. Avoid treating document completion as proof of resilience. The real test is whether another authorised colleague can complete the work safely and to the required standard.
Prioritise dependencies by impact and likelihood. A single-person dependency in a low-impact task is not the same as one in a regulated control, customer-critical service or payment process. Assign an owner, agree a remediation date and review whether the change actually reduced disruption.
A practical five-question review
- Which important activity would stop if one colleague were unavailable for a month?
- What knowledge, access or approval is concentrated in that person?
- Where is the documented process incomplete or out of date?
- Who else has demonstrated the ability to perform the task independently?
- What evidence will show that continuity and quality have improved?
Strong employees should make a business more capable, not become the only thing keeping a process operational. The goal is to protect their expertise by making it transferable, supported and embedded in the way work is designed.
Connect the finding to a wider improvement plan
Key-person dependency is often connected to other operating issues: unclear roles, weak process ownership, poor documentation, manual workarounds and limited performance visibility. Treat it as a system-level improvement opportunity. Brivixo helps teams connect evidence, process diagnosis, decisions and follow-through so that operational improvements can be prioritised and reviewed.
Explore business process improvement · Explore operating model software · Explore LeadLeak
Adapted and expanded from Brivixo’s LinkedIn post: Sign #4: Everything depends on “the person who knows”.
Put the operating loop into practice
Brivixo is designed to keep evidence, decisions, work and measured results connected.
Explore Brivixo →