Most businesses have one: a person whose absence would cause immediate, visible disruption. The founder whose institutional knowledge holds the whole operation together. The team member who is the unofficial answer to every question. The colleague who, if they handed in their notice tomorrow, would create a gap that wouldn't be easy to fill.

Key-person dependency is one of the most common structural vulnerabilities in small service businesses, and one of the least addressed, because the person in question is usually doing such a good job of making it invisible. The business is running. Things are getting done. It's only when that person steps back (for a holiday, for illness, or permanently) that the dependency becomes clear.

This post is about how to reduce it practically, proportionately, and without disrupting the business in the process.

Understand what you're trying to reduce

Key-person dependency isn't about any individual. It's about where knowledge and decision-making authority exist in the business, and whether they're distributed across the structure or concentrated in a single point.

The goal is to ensure that critical knowledge, processes, and decisions aren't entirely dependent on any one person being present. That's achieved through structure: documentation, clear ownership, connected systems, and deliberately distributed knowledge.

This is important to understand because the conversation about key-person dependency can feel uncomfortable if it's framed as being about a specific person. Framed as something that makes the business more resilient, the team's work more sustainable, and the organisation less fragile is a much easier conversation to have.

Step one: identify where the dependency is

Before addressing key-person dependency, you need to know where it is. Here is where to look first:

Process knowledge. Who knows how the most important things actually get done? I'm talking about the version that includes the workarounds, the exceptions, and the judgment calls. If the honest answer to "how does this process work?" is "ask [name]," that's a dependency.

Relationship knowledge. Who holds the key relationships with clients, with suppliers, and with partners? What would happen to those relationships if that person left? How much of the relationship exists in the system, and how much exists only in that person's history with the contact?

System knowledge. Who knows how the tools and platforms work? Not just how to use them, but where everything lives, how the data is structured, what the integrations do, and what would break if someone changed something. If only one person can navigate the CRM or knows what all the tabs in the spreadsheet mean, that's a dependency.

Decision-making authority. Which decisions consistently come back to one person because they're the only one with enough context to make them? If a founder or senior leader is regularly pulled into decisions that should be made independently by their team, the context needed to make those decisions isn't distributed enough.

Step two: document before you distribute

The most important step in reducing key-person dependency is documentation. You need to get critical knowledge out of people's heads and into a form the business can actually use.

Don't simply ask the key person to write a document. Work with them to extract, structure, and record what they know in a way that's useful to someone who doesn't already have that knowledge.

A few principles that make documentation more likely to stick:

Document the actual process. The way things are supposed to work and the way they actually work are often different. Documenting the ideal process produces a document that doesn't reflect reality and therefore doesn't get used. Documenting the actual process, including the workarounds and the exceptions, produces something useful.

Write for someone who has never done this before. Every step that feels obvious to the person doing the documenting is a step that will cause confusion for someone encountering the process for the first time. Include the decision points. Link to the tools and documents needed at each step. Say who is responsible for each action.

Start with the highest-risk processes. You don't need to document everything at once. Start with the processes that would cause the most disruption if the key person were suddenly unavailable. This could include client onboarding, service delivery, invoicing, whatever carries the most weight in your specific business.

Step three: build the knowledge into the system

Documentation is only the first step. The second step is building that knowledge into the operational systems of the business so that the process is embedded in how the work actually gets done.

This means structuring your project management tool to reflect documented processes rather than relying on individual memory. It means building checklists into the workflows so that critical steps aren't dependent on anyone remembering to do them. It means ensuring that client information lives in the CRM rather than in email threads or one person's notes. It means connecting tools so that information flows automatically rather than being carried manually by a person who has learned where everything lives.

When the knowledge is in the system rather than in the person, the person can leave, temporarily or permanently, without taking the knowledge with them. The system holds it.

Step four: distribute decision-making deliberately

Reducing key-person dependency in decision-making is about building the context and the authority that enable other people to make decisions independently. This means being explicit about which decisions should be made at which level of the organisation and ensuring that the people who should be making certain decisions have the context, the information, and the confidence to do so. A team that always escalates to the founder is doing so because they either don't have the information needed to decide, aren't sure whether the decision is theirs to make, or have learned that the founder will override them anyway.

Addressing decision-making dependency means being clear about what is delegated, providing access to the information needed to exercise that delegation, and then actually letting people decide, including when they decide differently from how you would have.

Step five: cross-train intentionally

Once knowledge is documented and built into systems, the final step is ensuring that more than one person understands how the key processes work.

This requires deliberate, regular opportunities for people to work across functions - to shadow the key person on the processes they own, to take primary responsibility for tasks with the key person available as backup, and to build familiarity with the systems and processes before they need to use them independently.

The goal is resilience. A business where two or three people understand how each critical process works is significantly more resilient than one where only one person does, even if that one person is excellent.

Regarding the people carrying the dependency

The people who are key dependencies are often carrying more than their role formally requires. They've absorbed knowledge, relationships, and decisions over time because that's what the business required.

Reducing key-person dependency isn't simply good for the business. It's often a relief for the person at the centre of it. The weight of being the answer to everything is exhausting. Distributing that weight more evenly is better for the individual as well as healthier for the organisation.

Start here

If you recognise key-person dependency in your business but aren't sure where to begin, pick the one process that would cause the most immediate disruption if the person who knows it best were suddenly unavailable. Write down every step, in order, in enough detail that someone who has never done it before could follow it. Store it somewhere the team can find. Ask one other person to read it and tell you where they'd get confused.

That's one process sorted.

From there, the work is simply continuing with the next most important process, the next most critical system, the next decision that should be distributed but isn't.

Consistent, proportionate progress over time is how key-person dependency gets reduced in practice - as a sustained operational habit.

Reducing key-person dependency is one of the things a well-structured operational system enables. If you'd like help mapping where your business is most exposed and building the structure to address it, Evolve is designed for exactly this, starting with a full operational audit and ending with full implementation. You might also find the post on what happens when a key person leaves useful context. Get in touch to talk through where your business is.