Only one person knows how to do that

When only one person knows how something works, your business is running on borrowed time. Here’s how to fix key person risk with documented, repeatable processes.

Every organization has that person. You know exactly who I’m talking about.

The one who’s been there twelve years. The one who knows why the monthly report has to be exported as CSV first, then imported into the other system, then manually adjusted for the three accounts that don’t follow the normal rules. The one everyone goes to when something breaks. The one whose vacation days make the whole team nervous.

What happens when they quit?

I’m not being dramatic. This is a real risk with a real name - the bus factor. Software engineers coined the term. It measures the minimum number of people who’d have to be “hit by a bus” before a project grinds to a halt. If your bus factor is one, you’re in trouble. And frankly, most teams I’ve talked to at Tallyfy are sitting at exactly that number for at least a few critical processes.

Bus factor problem is everywhere

Here’s a number that stopped me cold. Research shows that 65% of systems have a bus factor of two or less. Two people. That’s all that stands between a functioning operation and chaos.

And it’s not just tech teams. Finance departments have the person who “just knows” the reconciliation process. HR has the one who handles the weird edge cases in benefits enrollment. Operations has the person who manages the vendor relationship that keeps the supply chain moving. None of this is written down anywhere.

Running Tallyfy taught us with workflow automation at Tallyfy, we’ve observed that roughly 80% of processes in most organizations exist only in someone’s memory. Not in a handbook. Not in a wiki. In someone’s head.

That’s not a process. That’s a hostage situation. It’s the definition of tribal knowledge — expertise that exists nowhere except inside one person’s head.

The worst part? Leadership rarely sees this as urgent. They see it as a “nice to have” - something they’ll get around to documenting eventually. Then someone gives two weeks’ notice and suddenly it’s a five-alarm fire.

What knowledge silos actually cost you

Let me get specific, because vague warnings don’t change behavior. Money does.

IDC research puts the cost of knowledge silos at roughly $100,000 per 100 employees per year in lost productivity alone. That’s just the time people waste hunting for information that should be readily available.

But the real damage goes deeper. Employees waste 5.3 hours every week waiting for data from colleagues or recreating information that already exists somewhere. That’s six full work weeks per year per person, burned on what amounts to an internal scavenger hunt.

And when someone actually leaves? About 42% of what they did can’t be covered by the people who remain. Not because the remaining team is incompetent - because the knowledge simply wasn’t shared.

Think about that for a second. Almost half the work vanishes.

In discussions we’ve had about this at Tallyfy, one pattern keeps coming up: companies don’t realize the cost until it hits them. A key employee retires. An operations manager moves to a competitor. A finance lead goes on extended medical leave. And suddenly the team is spending weeks reverse-engineering processes that the departing person could’ve explained in an afternoon - if anyone had thought to ask.

The replacement cost alone is brutal. SHRM estimates it costs between 50% and 200% of an employee’s annual salary to replace them. For technical roles, it can hit 150%. But that number doesn’t even account for the knowledge that’s permanently lost. The shortcuts. The workarounds. The “you have to call Jim at the vendor, not the main line, because he’ll actually fix it” kind of stuff.

Why people hoard knowledge

This is the uncomfortable part. Some knowledge silos aren’t accidental. They’re strategic.

I think most managers don’t want to admit this, but some employees intentionally make themselves irreplaceable. They keep processes in their heads because it gives them job security. If nobody else can do what they do, they can’t be fired. They become untouchable.

I’m not saying these people are malicious. Most of the time, they’re not even doing it consciously. They’re just responding to incentives. If the organization doesn’t value documentation, if there’s no reward for sharing knowledge, if the only thing that gets you a raise is being the person everyone depends on - well, what do you expect?

But the result is the same. The organization becomes dependent on individual humans instead of repeatable systems. And that’s fragile.

There’s another pattern that’s equally dangerous: the expert who genuinely wants to share but doesn’t know how. They’ve been doing the work for so long that they can’t articulate the steps anymore. It’s muscle memory. Asking them to write it down is like asking a jazz musician to notate their improvisation. They’ll either produce something incomplete or give up entirely.

This is why “just document your processes” is terrible advice. It sounds reasonable. It almost never works. Proper process documentation requires a fundamentally different approach than asking people to write manuals.

The documentation graveyard problem

Here’s where it gets interesting - and where I think most organizations go wrong.

The typical response to key person risk goes like this: someone in leadership gets nervous, they buy a wiki or a knowledge base, they send out a company-wide email asking everyone to “document their processes,” and then… nothing happens. Or worse, people spend a week writing documents that immediately go stale because nobody maintains them.

We’ve all seen this. The company wiki that’s three years out of date. The Google Drive folder full of SOPs that describe how things worked before the last software migration. The SharePoint site that everyone forgot exists.

I’m going to say something that might sound contradictory coming from someone who builds process software: nobody reads documentation. Seriously. Cottrillresearch found that employees spend 1.8 hours per day searching for information. The information exists somewhere, but nobody can find it, nobody trusts it, and nobody knows if it’s current.

Static documentation is a graveyard. Things go there to die.

The fix isn’t better documentation. It’s processes that document themselves.

Processes that run are processes that survive

This is the core insight, and it’s why we built Tallyfy the way we did.

A living workflow - one that people follow every day as part of their actual job - stays current because it has to. When the process changes, the workflow updates. When someone finds a better approach, it gets captured in real time. The documentation isn’t a side project. It’s the work itself.

Think of it this way. A recipe sitting in a drawer gets forgotten. A recipe you cook from every Tuesday stays sharp. If the recipe is wrong, you notice immediately because the food tastes bad. You fix it. The recipe evolves.

That’s the difference between static documentation and a living process. One collects dust. The other gets better.

In the age of AI, this matters even more. AI agents need structured workflow patterns to follow - sequential steps, parallel tasks, decision points. If your processes live only in someone’s head, AI can’t touch them. You’re locked out of the single biggest productivity shift of the decade because you never bothered to write down how your business actually runs.

Process quality is performance. And undocumented processes are the worst kind of bad - they’re invisible.

How to actually fix key person risk

Enough diagnosis. Here’s what works, based on hundreds of implementations and feedback we’ve received at Tallyfy.

Identify your single points of failure. Walk through your org chart and ask one question about every function: if this person left tomorrow, could someone else do their job within a week? If the answer is no, you’ve found your risk. Start there.

Don’t ask people to write manuals. Instead, have them walk through the process while someone captures it in a workflow tool. Record the steps as they happen. Capture the decisions, the exceptions, the “oh and you also need to do this” moments. The goal is to extract knowledge through doing, not through writing.

This is the Tallyfy philosophy — when someone follows a workflow to complete their actual work, they’re simultaneously maintaining the documentation. The process and the documentation are the same thing. No separate maintenance. No stale wikis. No homework.

Cross-train relentlessly. Research from Tulane University found that deliberate knowledge-sharing activities increased productivity by up to 24%. Not because people got faster at their own jobs - because they stopped being blocked when the one expert was unavailable.

Build it into offboarding. Every departing employee should spend their last two weeks walking through their processes with a colleague while those processes get captured in a structured system. Not an exit interview. A knowledge transfer. There’s a massive difference.

Reward sharing, not hoarding. If your culture celebrates the hero who swoops in to save the day, you’re incentivizing people to create crises that only they can solve. Instead, recognize the people who make themselves replaceable by teaching others and documenting their work.

This is business continuity, not busywork

I know what some people are thinking. “We’re too busy to document processes.” I hear it constantly.

But here’s the thing. You’re not too busy. You’re too busy doing the wrong things. Those 5.3 hours per week that employees waste searching for information? That’s your documentation time, hiding in plain sight. You’re already paying for it. You’re just getting nothing in return.

The American Management Association reports that 83% of executives acknowledge their organizations have silos. Ninety-seven percent say those silos have had a negative effect on business. Everyone knows the problem exists. Almost nobody does anything about it.

The organizations that take this seriously - the ones that treat process documentation as infrastructure rather than overhead - are the ones that survive leadership changes, scale without chaos, and actually benefit from AI when they deploy it. Because they have something for AI to work with.

My guess? You already know who your key person risks are. You can probably name them right now. The question isn’t whether the problem exists. The question is whether you’ll fix it before the next resignation letter lands on your desk.

---

Related questions

What is the bus factor and why does it matter?

The bus factor measures how many people on a team would need to be unavailable before a project or process stalls completely. A bus factor of one means a single departure - planned or otherwise - can cripple operations. It matters because most teams have critical processes that depend on just one or two people, and that concentration of knowledge creates enormous operational risk.

How do you calculate key person risk?

Map every critical process in your organization and identify who knows how to execute each one. If only one person can do it, that’s a bus factor of one - your highest risk. Score each process by business impact (what happens if it stops?) and knowledge concentration (how many people can run it?). The processes with high impact and low knowledge distribution are your priority targets.

What is the difference between key person risk and knowledge silos?

Key person risk is about people - the danger that one individual’s departure cripples a function. Knowledge silos are about information being trapped in departments, tools, or individuals rather than flowing freely across the organization. They’re related but distinct. You can fix key person risk through cross-training while still having knowledge silos between departments. Ideally, you tackle both.

How much does it cost when a key employee leaves?

The direct replacement cost runs between 50% and 200% of the employee’s annual salary according to SHRM. But the hidden cost of lost knowledge is often larger - roughly 42% of what a knowledgeable employee does can’t be replicated by remaining staff. Add lost productivity, retraining time, and process disruptions, and the true cost can easily exceed 300% of their salary for senior or specialized roles.

Can AI help reduce key person risk?

Only if your processes are already documented. AI agents need structured workflows to follow. If the knowledge lives in someone’s head, AI has nothing to work with. The sequence matters: first capture and document your processes in a structured system, then bring in AI to optimize and automate them. Skipping the documentation step and jumping straight to AI just automates confusion.