Key-person dependency is often described as a documentation problem. Sometimes it is. More often, the missing knowledge is not a list of steps. It is a set of decisions.
The experienced operator knows which request is urgent, when a client needs reassurance, what can wait and which exception will create trouble later. A checklist that records only clicks and fields misses the real work.
Find where work waits for a person
Review the last month of delivery. Look for approvals, assignments, estimates, client replies and corrections that paused until one person became available.
Record the trigger, the information they checked, the decision they made and what happened next. This creates a decision map instead of a generic procedure.
Separate rules from judgement
Stable rules belong in the workflow. For example, every new client needs a signed agreement, billing contact, owner and kickoff date before delivery begins.
Judgement should stay visible and supported. The system can collect context, show relevant history and route unusual cases to the right person without pretending that every situation can be automated.
Create explicit ownership and escalation
Every state needs an owner. Every blocked state needs a timeout and an escalation path. Otherwise the new system only digitises waiting.
A useful workflow answers: who owns this now, what are they waiting for, when should it move and who is notified if it does not?
Make exceptions teach the system
When the experienced person overrides a rule, capture why. Repeated overrides may reveal that the rule is wrong, the input is incomplete or a new path is needed.
This is how software becomes operational memory. It records not only the normal route but also the patterns that cause the route to change.
Test absence safely
Do not wait for an emergency. Choose a low-risk period in which the key person observes without intervening unless necessary. Measure what stalls, what gets escalated incorrectly and what context the team cannot find.
Use the result to improve the workflow, not to blame the people testing it.
Know when software helps
Documentation is enough when the work is infrequent and linear. Workflow software becomes useful when many people share the process, state changes matter, exceptions recur and the cost of waiting is meaningful.
Start with the bottleneck map. If the dependency lives inside a shared workbook, review the signs that a spreadsheet has become an operational liability.
A 30-day dependency reduction plan
- Week 1: identify the three decisions that wait most often for the key person and collect recent examples.
- Week 2: define the stable rules, required context and escalation conditions for those decisions.
- Week 3: place the rules inside the workflow, assign backup owners and make blocked states visible.
- Week 4: run an observed absence test and record every intervention the key person still had to make.
Repeat with the next group of decisions. Trying to extract an entire role in one documentation sprint usually produces broad notes that nobody uses.
Avoid these anti-patterns
Do not turn the key person into a full-time process writer. Capture knowledge from actual work. Do not automate every exception after seeing it once. Look for recurring patterns. Do not create a second gatekeeper by giving one backup person all the knowledge. Distribute visibility and use named escalation paths.
Measures that show real improvement
Track work items waiting for one person, median blocked time, decisions completed by backup owners, escalations resolved without intervention and errors caused by missing context. Documentation volume is not the outcome.
The best result is not zero questions. It is fewer avoidable waits and better questions that arrive with the context needed for a decision.
The goal is not to make experienced people replaceable. It is to stop the operation from becoming unavailable whenever their attention is elsewhere.
Join the discussion.
Add a useful correction, question or operating lesson. Your email address is never published.