I've seen this happen more than once over the years. Something breaks, nobody can quite figure out what's going on, and eventually somebody says, "Call John. He'll know."
Maybe his name isn't John, but almost every company that's been around long enough has one. He's the person who remembers why something was built the way it was, which customer needed that strange exception, or why a process that looks unnecessary absolutely cannot be removed. Having someone like that on your team is incredibly valuable. It can also create an incredible amount of risk.
When Knowledge Becomes Part of the Architecture
We normally think of architecture as applications, databases, integrations, servers, APIs, and all the other pieces that make a system work. But after enough years, people can become part of the architecture too.
The system works because Sarah knows to check something every Tuesday. A deployment succeeds because Mike knows about the extra step that isn't in the documentation. Support gets an unusual customer issue and immediately sends it to David because he's the only person who has seen it before. Eventually those things become normal, and nobody considers them a problem because the process works.
Until Sarah goes on vacation.
The Human Version of Technical Debt
In my last article, I talked about temporary fixes becoming permanent parts of a platform. I think undocumented knowledge works almost the same way.
One person learns something because they had to solve a problem. The next time it happens, everyone goes back to that person. Why spend three hours investigating something when Jennifer can solve it in ten minutes? It makes perfect sense at the time.
But every time we do that without transferring the knowledge, we make Jennifer a little more important to the operation of the system. Eventually she isn't simply an experienced employee. She's a dependency.
This usually doesn't happen because someone intentionally refuses to document what they know. The company is busy. Customers need things. Production issues happen. Projects have deadlines. Writing down something you already know how to do never feels quite as important as solving today's problem.
So we tell ourselves we'll document it later.
Sound familiar?
When Your Best People Become Bottlenecks
There's an irony here. The people most likely to become bottlenecks are often some of your best employees.
They're dependable. They know the product. They understand the customers. They've seen the mistakes before. When something important happens, they're exactly the people you want involved, so we involve them in everything.
Before long, they're answering questions all day, reviewing everyone else's work, joining every important call, troubleshooting production issues, helping Support, helping Product, and helping newer employees understand the system. Then leadership wonders why they aren't getting their own work done.
We've rewarded expertise by making it almost impossible for the expert to escape it.
Documentation Helps, but It Isn't the Answer
The obvious response is, "We need better documentation." Yes, we probably do. But I've also seen companies create hundreds of pages of documentation that nobody reads and that becomes outdated almost as quickly as it was written.
The real goal isn't documentation. The goal is knowledge transfer.
That might mean documentation, but it could also mean pairing people together, rotating responsibilities, or having another developer troubleshoot the problem while the experienced person helps instead of immediately taking over. Sometimes it simply means asking the person who knows something to explain why instead of always asking them to fix it.
There's a big difference between documenting steps and transferring understanding.
Can Someone Else Do It?
I think that's a surprisingly useful question for leaders to ask. If this person were unavailable for two weeks, could somebody else deploy the application? Could somebody else troubleshoot that integration? Could somebody else explain why this business rule exists? Could somebody else work with that important customer?
If the answer is consistently no, you've found organizational risk.
That doesn't mean the employee has done anything wrong. Quite the opposite. It usually means they've become extremely valuable. Our responsibility as leaders is to make sure their knowledge becomes valuable to the organization too.
The Goal Isn't to Make People Replaceable
Whenever this subject comes up, someone inevitably hears "knowledge transfer" and thinks we're talking about making employees replaceable. That's not how I see it.
The person who can solve every problem is valuable. The person who can help five other people learn how to solve those problems is even more valuable.
That's how teams mature. It's also how experienced employees get the opportunity to move forward instead of spending the next ten years being the person everyone calls whenever the same old system breaks.
A Healthy System Should Survive a Vacation
Maybe that's the simplest test. Your employees should be able to take a vacation without checking Teams every few hours. Someone should be able to get promoted without leaving a hole behind them. Someone should be able to retire after twenty years without everyone suddenly realizing that twenty years of business knowledge just walked out the door.
Technology companies spend a lot of time thinking about redundancy. We build redundant servers, storage, networks, backups, failover systems, and disaster recovery plans. Yet sometimes we'll allow one person to be the only person who knows how a critical part of the business actually works.
That's a strange kind of redundancy plan.
So perhaps there's another question we should ask when evaluating the health of an established platform:
What does the system know, and what do only our people know?
Because eventually people move on. The knowledge shouldn't have to leave with them.
Thanks,
Michael Cronin
Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/
