Anila is a fractional exec at opsbridge.io, helping scaling orgs restore ops discipline & clarity to improve margins & accelerate growth.
Every company I’ve worked with has a key person. Their name comes up whenever someone asks who knows how something works. Depending on the function, that person may be very senior or more junior; there’s no single title for them. It’s rarely about authority, but about what they know.
Most leaders call this a retention risk. They worry the person will leave, so they plan a raise, a new title, maybe even a retention bonus. Those aren’t bad ideas, but they miss the bigger issue. The problem was there long before anyone started worrying about retention. The company learned to run on one person’s memory, experience and judgment. That person probably didn’t choose this either; it just happened, one reasonable shortcut at a time.
So, the more useful question for leaders is, “Why does the business still need this one person for these things to work?”
When Dependency Looks Like Strength
Key-person risk stays hidden because, for a long time, it looks like strength. The person is fast, they’re right most of the time, customers ask for them by name, and when something is stuck, asking them is quicker than figuring out why or writing anything down. So, everyone keeps going to them, and every trip makes the next one more likely.
A couple of years in, you end up with a small group holding much of the real operating knowledge of the business, particularly the exceptions nobody else knows. Which customer gets special handling? Why does that billing concession exist? Which number in the report should you trust?
Almost none of it is written down because much of it was never really a formal decision. It was just a habit that worked…until the business grew around it.
How Companies Get Here
The cost of this dependency rarely arrives as a crisis. More often, it becomes an invisible queue waiting for someone’s calendar. A question waits until they’re available. A customer issue sits until they can weigh in. Someone has most of the information but not the piece only they know. Eventually, that waiting becomes so normal that it stops looking like a delay and becomes the process. A process that should flow from one team to another now has a gate in the middle, though nobody intentionally designed it.
There is also another cost. The more people learn to check with the person who knows, the less opportunity they have to develop that judgment themselves. Asking becomes easier than learning. At that point, the organization isn’t just concentrating knowledge; it’s discouraging anyone else from building it, and that’s what makes this a leadership issue.
Nobody designs this deliberately; it just evolves. As companies grow, especially at pace, shortcuts are useful. Asking the person who knows is faster than stopping to redesign a process. Letting one person handle an unusual customer exception is easier than writing down why it exists.
Each decision makes sense on its own, but the accumulated system doesn’t. Growth adds more customers, people, products and exceptions, but the knowledge underneath the business doesn’t always grow with it.
Take The Two-Week Test
Here’s a simple way to see how exposed you are. I call it the two-week test:
• First, write down the 10 or 15 things your company cannot afford to get wrong: customer commitments, the release process, a large renewal, pricing, forecasting or whatever applies to your business.
• Next to each, put the name of the person it actually depends on. Not the name on the org chart or the person who technically owns the process. Put down the person you would really call if something went wrong.
• Then ask: “If this person were unreachable for two weeks, what would stop and what would keep running but quietly get worse?”
A few names will probably appear again and again. You may also find rows where nobody is quite sure whose name to put down. Both tell you something: repeated names show you where dependency has concentrated, and empty rows show you where ownership exists largely by assumption.
Now, look at why each person’s name is there. Do they have information nobody else has? Are they the person everyone trusts to have the answer? Do they hold a customer or supplier relationship that hasn’t been built beyond them? Or does the normal process work until something unusual happens, and then everybody calls them? Those are different dependencies and they require different fixes.
Don’t Just Document The Process
Once companies identify key-person risk, the instinct is often to document everything that person does. That helps, but it only gets you so far. Process documents describe a normal day, but what often makes the key person valuable is what they do on an abnormal one: when to bend the rule, when to escalate, what they check first and which apparently urgent issue can actually wait. That’s judgment, and judgment is harder to put into a flowchart.
Start with the last few times something went sideways and that person was called in. What did they notice? What did they ask? What did they decide, and why? Then put someone else alongside them the next time those decisions come up. The goal isn’t simply to transfer information; it’s to build the judgment to use it.
And sometimes, the answer isn’t another person at all. If somebody has become a permanent gate in a process, ask whether the gate still needs to exist, or whether what they know belongs in the process itself. Otherwise, you can spend a lot of time solving key-person risk by creating a second key person.
The two-week test isn’t really a list of people you can’t afford to lose. It’s a map of where your business still depends on what one or two people know to run it the way you expect. Run the test and look at the names, then look past them.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?