Every IT leader has a version of this story.
A server needs a routine reboot, and it turns out only one engineer knows the exact order to shut things down in, because they set it up four years ago and never wrote it down.
A vendor contract renews itself because nobody remembers who owns that relationship. A new hire asks “why do we do it this way?” and gets a shrug instead of an answer.
None of this shows up on a risk register. But talk to sysadmins and IT managers candidly on forums like r/sysadmin and r/msp, where people are more honest than they are in a boardroom and the same anxiety comes up again and again:
"Nobody actually knows how this system works properly. It just... works, until it doesn't".
That’s not a technology problem. It’s a documentation and continuity problem, and it’s quietly one of the biggest risks sitting inside most IT operations today.
The "Bus Factor" Is Higher Than You Think
There’s an old engineering joke about the “bus factor” and that’s the number of people who’d need to get hit by a bus before your systems become unmanageable. In a lot of IT teams, that number is uncomfortably close to one.
It’s not because your team is careless. It’s because documentation is the first thing to slip when everyone is busy keeping the lights on. Tickets get closed. Fires get put out. Nobody schedules time to write down why a system was configured a certain way, because there’s always something more urgent.
The result is institutional knowledge that lives entirely in people’s heads, which works… right up until someone goes on leave, gets promoted, or leaves the company. Then what was “obvious” to one person becomes a mystery to everyone else, usually discovered at the worst possible moment.
This isn’t a fringe problem. PDQ’s State of Sysadmin report, based on a survey of over 1,000 IT professionals found that 69% of sysadmins worry they’re a single point of failure for critical institutional knowledge. Even more telling: 41% believe their own management isn’t aware of the risk that creates.
It’s the people closest to the risk can see it clearly. The people who could actually fix it, by budgeting for documentation time, cross-training, or knowledge management tools often don’t know it exists.
"Over 1,000 IT professionals found that 69% of sysadmins worry they're a single point of failure for critical institutional knowledge".
The Real Question Isn't "Do We Have Documentation?"
This isn’t just a sysadmin worry, either, we see it at the management level too. A separate survey of 1,000 IT managers across the UK and US found that 67% were concerned about the loss of knowledge and expertise when people leave, and 64% said their organisation had already experienced it firsthand.
The concern isn’t confined to the people closest to the keyboard it runs all the way up.
Consider what fragmented documentation actually costs:
Onboarding drag. New IT hires (or new MSPs) take months longer to become productive because there’s no reliable source of truth to learn from.
Vendor and contract blind spots. Nobody can say with confidence what you’re paying for, why, or whether it’s still needed.
Audit and compliance exposure. If you can’t demonstrate how a system is configured or who has access to it, that’s a finding waiting to happen.
Negotiating leverage, gone. Renewing a contract or negotiating with a vendor is much harder when you don’t have a clear record of what was promised the first time.
Most IT teams will tell you, yes, they have documentation. A wiki somewhere. Some old Word docs. A folder of diagrams nobody’s opened since 2022.Â
And yet the numbers above tell a consistent story: most sysadmins feel exposed, most managers are concerned, and the gap between the two rarely gets closed until something forces the issue. The real question is “Could your team explain your critical IT processes without relying on one key person?”
If the honest answer is “not really,” you’re not alone. But it’s worth treating as a solvable problem rather than a permanent state of risk.
Where To Start?
You don’t need a massive documentation overhaul to make meaningful progress. Start by getting honest answers to a handful of pointed questions things like:
- If our most senior IT person left tomorrow, what would we be unable to do?
- Do we have an up-to-date map of our critical systems and how they connect?
- Is there a single source of truth for passwords, access, and permissions, or does it live in someone’s head?
- When did we last test our disaster recovery plan, rather than just having one on paper?
- Who owns each vendor relationship, and is that written down anywhere?
Asking these questions doesn’t fix the problem by itself. But it turns a vague, uneasy feeling into a concrete list of gaps you can actually close, one system, one process, one runbook at a time.
If workload automation sits at the heart of your operations, you may also find these useful: Ortom8’s Health and Value Check for Control-M is a no-obligation review of how stable, secure and well-documented your environment is, and our WLA consultancy work includes the runbooks and knowledge transfer that help reduce reliance on any one person.
