The Key-Person Risk in Software
A company can have working software and still carry serious continuity risk if one person is the only one who knows how the system works, how it deploys, where the credentials live, or what to do when something breaks.
What is key-person risk in software?
Key-person risk in software is the business exposure created when important technical knowledge or control is concentrated in one person. The underlying issue is that the company depends on one individual to keep a system understandable, operable, or recoverable.
The risk can sit in source code, architecture knowledge, credentials, deployment procedures, vendor relationships, debugging knowledge, or the history behind decisions that were never documented. The software itself may work well. The problem becomes visible when the company asks whether someone else could safely take over.
This is why key-person risk is closely tied to software business continuity. A system is only as resilient as the organization's ability to operate, repair, and hand it off when the usual person is unavailable.
What does the bus factor mean in software?
The bus factor is an informal way of describing how many people could disappear from a project before the work becomes difficult or impossible to continue. A bus factor of one means a single person holds knowledge or access the organization cannot easily replace.
In practical business terms, bus factor software risk is broader than coding knowledge. One person may know how the application deploys, which vendor account matters, where a certificate lives, why an integration was built a certain way, or how to recover from a failure that has happened before.
The question is not whether that person is valuable. The question is whether the company has allowed valuable expertise to become a single point of failure.
What is single developer dependency?
Single developer dependency occurs when one developer becomes essential to the safe operation or maintenance of a system. That person may be the original builder, the senior engineer who understands the architecture, the founder who wrote the first version, or the contractor who has quietly supported the application for years.
The dependency can grow without anyone making a deliberate decision. A developer solves one problem, then another, then becomes the person everyone asks when something goes wrong. Over time, technical knowledge, credentials, deployment access, and decision history can accumulate around that person.
Other engineers can work on parts of the system but rely on one person for the larger picture and the consequences of major changes.
The formal process may be incomplete, outdated, or dependent on steps that only one person knows how to perform safely.
Important accounts, secrets, certificates, vendor portals, or recovery mechanisms may depend on one individual's access or memory.
Recurring incidents and technical decisions become dependent on one person's historical knowledge of the system.
Important decisions, dependencies, procedures, and workarounds may be known through conversation instead of a durable record.
Continuity can depend on knowledge of vendor accounts, APIs, contractors, cloud services, or support channels that the rest of the company does not understand.
The Dave problem
Dave built something useful. Maybe it automates quotes, moves customer data between systems, generates reports, or replaces the spreadsheet everyone hated. The software solves a real business problem, so more people begin using it and more processes begin depending on it.
The problem starts when Dave becomes the documentation, support desk, security model, and disaster recovery plan. The application may still look like a small internal tool, but the company is now carrying a business continuity risk disguised as software convenience.
AI-assisted coding makes this pattern easier to create because one capable employee can build surprisingly important software without a traditional engineering project. The issue is not Dave. The issue is what the business has allowed to accumulate around Dave.
How does key-person risk become technical debt?
Technical debt includes future cost created by decisions that make software harder to understand, maintain, secure, or change. Concentrated knowledge creates that future cost because every important decision, incident, handoff, or staffing event becomes harder when the system depends on one person's memory.
The code can be clean while the business still carries technical debt. A system with strong tests and good architecture may still create continuity risk if only one person controls deployment, understands the vendor dependencies, or knows how to recover after a failure.
This is why technical debt management has to look beyond code quality. Ownership, documentation, deployment, continuity, and organizational knowledge all affect whether the business can safely own the software.
What are the warning signs?
Key-person risk usually becomes visible through operating behavior before it becomes visible in the codebase. The same person is repeatedly pulled into every important decision, incident, release, or explanation of how the system works.
Why documentation alone does not solve the problem
Documentation is part of the solution, but it is not the whole solution. A company can have a wiki full of notes and still depend on one person for judgment, context, access, or practical recovery experience.
Useful continuity requires that another qualified person can actually operate, change, deploy, and recover the system. Documentation supports that capability, but shared responsibility and practical knowledge matter as well.
The test is simple: if the key person became unavailable tomorrow, could someone else use the existing documentation, access, and operating practices to keep the system running?
How does AI affect key-person risk?
AI can reduce some forms of key-person dependence by explaining unfamiliar code, helping document systems, generating tests, and making older code easier for new engineers to understand. It can also create new forms of dependence when one employee uses AI to build important software faster than the organization can establish shared ownership around it.
A person who understands a business process can now turn that knowledge into a working app or automation without a large development team. If that software becomes important, the employee may hold both the business context and the technical context. That can make the single point of failure stronger rather than weaker.
What does software business continuity require?
Software business continuity means the company can keep important systems operating when people, vendors, accounts, or services become unavailable. That requires more than backups. It requires enough shared knowledge and access to operate the software under stress.
Architecture, dependencies, operating assumptions, and common failure modes are known beyond the original builder.
Production, vendors, cloud services, credentials, certificates, and recovery paths are accessible through managed business processes.
Documentation explains what the system does, where it runs, what it depends on, how it deploys, and how it recovers.
Continuity is stronger when another qualified person has actually deployed, repaired, or recovered the system before a crisis.
What should business leaders ask?
Executives do not need to know every technical detail. They do need to know whether the company can continue operating without one specific person holding the whole system together.
How should companies reduce key-person risk?
The goal is not to make every employee interchangeable. Deep expertise is valuable. The goal is to keep expertise from becoming an avoidable single point of failure.
That usually means spreading operational knowledge, moving critical access into managed business accounts, documenting systems for the next maintainer, assigning clear ownership, and making sure someone else has practical experience with deployment and recovery. The work should focus first on the systems that matter most to revenue, customers, operations, security, or continuity.
Some key-person dependence may be acceptable, especially in small companies. The important thing is that leadership knows where it exists and understands the consequence of carrying it.
When is a key-person risk assessment useful?
An assessment becomes useful when one employee or contractor has become indispensable to a critical software system, when a founder is preparing to hand off technical responsibility, when an important maintainer may leave, or when the company realizes that software continuity depends on knowledge that has never been formalized.
A focused Technical Debt Audit can review ownership, documentation, architecture, dependencies, deployment, access, security, maintainability, and continuity. The goal is to identify where single-person dependency creates meaningful business risk and what deserves attention first.
Find out where the business depends on one person too much.
Most companies begin with a focused two-week Technical Debt Audit. The goal is to understand where key-person risk sits, what could interrupt operations, what deserves attention, and what can remain as it is.