Key Person Risk
If that person left tomorrow, how long before the business can't function? For most South Island businesses I work with, the answer is less than a fortnight.
Key person dependency is one of the most common and least discussed risks in small businesses across Otago, Canterbury, and Southland. It is not a staffing problem. It is a process problem. When critical knowledge lives in a person's head rather than in documented systems, the business is exposed every single day.
Key person dependency rarely exists in isolation. It is usually connected to the same operational gaps I address as part of the operational efficiency approach: processes that were never written down, systems that were not designed to share knowledge, and a team that learned to work around the gaps rather than through them.
Your business has a key person dependency problem when any of these are true.
01
You can't take more than a day off without fielding calls about things that should be routine
02
One staff member handles something critical that nobody else has been trained to do
03
A key person handed in their notice and the first reaction was panic, not a handover plan
04
Your most important processes live in someone's head, not in a document anyone can actually follow
05
Onboarding new staff takes months because knowledge has to be extracted from the people who hold it
Not a knowledge audit. An actual fix.
01
I sit with the team and identify every process, decision, and piece of knowledge that only one person holds. That includes the workarounds they do automatically, the contacts they manage personally, and the judgment calls they make without documentation. Most people do not realise how much they hold until it is mapped explicitly.
02
Not all dependencies carry equal risk. I prioritise the knowledge that would cause the most damage if the person holding it left tomorrow, got sick, or was unavailable for a month. The goal is to understand the actual risk profile, not just list everything.
03
I write process documentation in plain language, structured for the person doing the job for the first time, not the person who created it. Undocumented processes are also the most common blocker for businesses exploring whether they are ready for AI: the tools need the same foundation the team does.
04
Documentation alone does not fix key person dependency. I run the handover with the team, confirm the documentation works in practice, and stay until the knowledge is genuinely distributed. The engagement closes when the team is working the new way, not when the documents are written.
Why it matters beyond risk
Every business owner I work with who has a key person dependency problem also has a ceiling problem. They can't take on more work because capacity is locked in individuals. They can't step back from the day-to-day because too much depends on them personally. They can't sell the business for what it is worth because a buyer can see the dependency risk clearly, even when the owner cannot.
Fixing key person dependency is not about losing what makes the person valuable. It is about making sure their knowledge outlasts their tenure. The best people want to grow into bigger roles, not stay as the single point of failure for a process the business cannot afford to lose.
The clearest test: if a critical staff member gave notice today, what would break? If the answer includes customer relationships, operational processes, or technical knowledge that only they hold, you have a dependency. Another signal is onboarding time. If new staff consistently take six months to become effective because they are learning from people rather than from documented systems, the knowledge is locked in individuals, not in the business.
In the short term: chaos, overwork for the remaining team, and a scramble to recover knowledge that should have been documented years earlier. In the medium term: service quality drops, customers notice, and the business loses ground that is expensive to recover. In the worst cases, a single departure triggers a cascade where customers leave, other staff follow, and the business can no longer function at its previous level. Most of this is preventable with preparation that takes weeks, not months.
The most common mistake is writing documentation for the person who already knows the process. Good process documentation is written for the person doing it for the first time. It includes the why behind each step, not just the what. It is tested by someone who has never done the task before. And it is updated when the process changes. The test is simple: can a new staff member follow this without asking for help? If not, it is not finished.
Specialisation is when someone is exceptionally good at something. Dependency is when no one else in the business could do it at all if they were unavailable. Specialists are valuable. Dependencies are risks. The goal is not to remove specialisation but to ensure the knowledge behind it is not locked in a single person. In most cases, the specialist themselves prefers this outcome: being recognised for expertise rather than being chained to it as the only person who can do the work.
Find out where your business is most exposed.
I map the dependencies in a Diagnose stage. Fixed fee, scoped upfront. No commitment beyond the first stage.
Book a Free Discovery ChatDealing with broader operational problems beyond knowledge risk? Read about the Operational Efficiency approach →