When Your Product Depends on One Engineer: How to Reduce Key-Person Risk
If your most knowledgeable engineer were unavailable for eight weeks starting tomorrow, what would stop? Run the list in your head as you read it: releases, hotfixes, deployments, customer escalations, architecture decisions, database changes, integrations, security updates, and production troubleshooting. If several of those trace back to one individual, your company carries key-person risk, and it carries that risk no matter how well the team is performing this quarter. Strong delivery today and concentrated knowledge are not opposites. They often travel together, because the person who ships the most is the person the most work flows through.
The evidence that this matters is real, though it comes with a caveat worth stating up front. In a 2019 study of open source projects, Avelino and colleagues examined 1,932 popular GitHub repositories and found that 315 of them, about 16 percent, lost the core developers who carried the project, and development continued afterward in only 41 percent of those cases. That evidence base is open source rather than commercial, and the commercial version of the problem is usually worse, because a paying product also carries customer-specific behavior and domain rules that never appear in a repository and cannot be picked up by a stranger reading the code. This is where a dedicated product engineering team can help, though most of the work described below is something your own team can start this week.
Key-person risk in software means that critical parts of a product become difficult to change, release or support if one specific person is unavailable. It differs from a resource shortage: hiring another developer adds capacity, but it does not distribute the product, operational and customer knowledge that currently lives in one person's head.
A Resource Shortage and Key-Person Risk Are Not the Same Problem
This distinction is the core of the whole subject, and it is the thing most writing on the topic misses. A resource shortage sounds like "we need another developer." Key-person risk sounds like "if this specific developer disappeared, critical parts of the product would become difficult to change, release, or support." They feel similar from the outside because both surface as pressure on the team, and they call for completely different responses.
Hiring solves the first problem. It does not automatically solve the second, and it can quietly make the second worse. A new hire has to be onboarded, reviewed, and taught, and all of that load falls on the senior engineer who already holds the knowledge and is already the bottleneck. For the first few months you have added capacity to the team and added work to the one person you most needed to free up. The concentration has not moved. It has a longer queue in front of it.
Two patterns from real product teams show how the same concentration wears different clothes. At one specialist engineering-software company, a single developer held both the software knowledge and the structural-engineering domain knowledge the product depended on, so no code change was safe without them and no domain question had a second answer. At a booking-software company, developers were pulled off product work again to field support and domain questions, because the answers lived in their heads rather than anywhere a support team could reach. Different symptoms, one underlying cause: knowledge sitting in too few places.
Where Key-Person Risk Hides in Mature Software Products
Most of the risk is not dramatic, and that is why it goes unnoticed until a resignation makes it visible. It shows up as small dependencies that everyone has learned to work around. The clearest signals are these:
- One person reviews all the critical changes, and nothing ships without them.
- Only one person knows how deployments really work.
- Customer-specific logic exists only in someone's memory.
- Certain modules have no meaningful documentation.
- Nobody else understands why the architectural decisions were made.
- Support escalations always end up with the same engineer.
- The team avoids touching certain code because only one person understands it.
- Holiday planning quietly shapes release planning.
- One person holds privileged production credentials or owns an operational process end to end.
There is one more item specific to established B2B products, and it is the one teams are most likely to miss, so it deserves naming on its own. The riskiest knowledge is often not code knowledge at all. It is domain knowledge: why a particular rule exists, which customer asked for it years ago, and what breaks downstream if it changes. That knowledge is invisible in the repository, it rarely gets written down because the person who holds it considers it obvious, and it is the hardest of everything here to transfer.
How to Measure Your Engineering Bus Factor
You do not need a tool or a metric to measure this. You need a method, and it takes an afternoon. List your critical knowledge domains: modules, integrations, deployment processes, infrastructure, customer variants, business rules, security responsibilities, and support knowledge. For each one, write down honestly how many people could work in that area today, independently, without stopping to ask someone for help.
The names that appear on almost every line are your bus factor, and a bus factor of one on any revenue-critical domain is a material risk rather than a theoretical one. It is also the number an acquirer will eventually put a price on, whether or not you measured it first. During technical due diligence, "who is the only person who can do this" is a standard question, and the honest answer moves valuations.
Seven Moves That Reduce the Risk
Once you can see where the concentration sits, the work becomes concrete. These seven moves do the most, and they work in roughly this order.
1. Identify the critical knowledge domains
Map before you fix. Most teams are wrong about which areas are concentrated, and they discover that only when they lay the domains out and count owners. The mapping exercise surfaces disagreements that are worth having in the open, and it stops you from spending effort hardening an area that was never the real single point of failure.
2. Build characterization tests
Documentation records what people believe the system does. Tests record what it does. For a mature product with thin documentation, characterization tests are often the fastest route to a safety net, because they capture current behavior as executable evidence that a second engineer can trust. They are the same artifact that de-risks a modernization decision, which is why the effort pays off twice.
3. Write architecture decision records
For each significant decision, capture what was decided, why, which alternatives were considered, the constraints at the time, and the consequences. An architecture decision record stops the next engineer from reverse-engineering intent out of the code, which is where most well-meaning but wrong "fixes" come from. Someone changes a rule that looks arbitrary, and it turns out a major customer depended on it.
4. Create runbooks
Write runbooks for deployments, incidents, database maintenance, integrations, customer onboarding, rollback, and environment setup. The test for a good runbook is specific and unforgiving: can another competent engineer execute this without calling the person who wrote it? If the answer is no, the runbook is a set of reminders for the owner, not a transfer of the knowledge. Nalashaa's web app maintenance services exist for exactly this kind of operational continuity.
5. Pair strategically, not randomly
Prioritize the highest-risk modules rather than pairing wherever it is convenient. The second engineer has to modify the code, review changes, debug a real incident, and deploy it, because passive knowledge-transfer meetings do not transfer knowledge. People learn a system by working in it under real conditions, not by watching a walkthrough and nodding.
6. Rotate ownership
Avoid permanent single-owner structures where one person touches an area and nobody else ever does. Introduce secondary owners, rotate code reviews, spread work across modules, and share the on-call rotation. Rotation feels slower in the moment because two people now touch what one person used to own, and it is the difference between a team that survives a departure and one that stalls on it.
7. Capture domain knowledge, not just code knowledge
Build domain glossaries, worked examples, and written business-rule documentation. In specialist B2B software, the answer to "why does this strange rule exist" is worth more than the code that implements the rule, because the code can be read and the reason cannot. This is the knowledge that walks out the door quietly, and it is the knowledge a new engineer most needs and least often gets.
Building a second line of product ownership? Our product engineering pods work inside client-controlled repositories with documentation, test automation, and structured knowledge transfer as deliverables, so the knowledge stays with your product rather than with any one person.
A 30/60/90-Day Risk Reduction Plan
The seven moves become a program when you sequence them. Ninety days is realistic for a single product, and the plan below works because its final phase produces evidence rather than another document.
Days 1 to 30: find the risk
Map the critical modules, identify the single-owner components, and document who holds critical access and credentials. List the processes that live in nobody's written record, identify the customer-specific knowledge that exists only in conversation, and record the production dependencies that would matter in an incident. The output of this month is a written risk register, not a hallway conversation, because a register is something you can act against and measure later.
Days 31 to 60: create redundancy
Add secondary ownership to the highest-risk components first, and pair on those specifically. Build characterization tests wherever behavior is undocumented, write runbooks for the processes only one person can run today, start architecture decision records for the decisions that shaped the product, and write down the domain terminology a newcomer would otherwise have to absorb by osmosis. The goal of this month is that the riskiest areas each gain a real second owner.
Days 61 to 90: prove the system works without the expert
This is the phase most plans skip, and it is the only one that produces proof. Have a different engineer handle a live support case, make a change, review a change, deploy to production, and troubleshoot a real issue, with the original owner deliberately unavailable or observing in silence. State the principle plainly and hold to it: you do not know whether knowledge transfer worked until someone else performs the work successfully. Everything before this phase is preparation. This is the test.
Where AI Helps With Knowledge Extraction, and Where It Stops
Used well, AI accelerates the parts of this work that are slow and mechanical. It maps a repository quickly, drafts initial documentation, explains unfamiliar modules, locates dependencies, drafts characterization tests, summarizes years of support history, and produces candidate runbooks. That acceleration matters most on exactly the codebases where the risk is highest, because those are the ones nobody ever found time to document.
The limit is the same one that governs AI in any modernization work, and it is worth stating in the same words for consistency: AI can accelerate knowledge extraction, but it cannot independently determine whether undocumented production behavior is correct. A generated runbook is a draft, and a human has to execute it once before anyone can trust it. The machine speeds up the capture. It does not sign off on the truth.
When an External Engineering Team Makes Sense
An external team can help here, and it can also make things worse, so this deserves an honest framing rather than a pitch. Think of it as a second line of product ownership rather than a set of extra hands, because the point is to distribute knowledge, not just to add throughput. What makes it work is a specific set of conditions: client-controlled repositories, shared architecture decisions, a transparent backlog, real code review, documentation delivered as a deliverable, test automation, structured knowledge transfer, predictable staffing, and a clear exit and handover plan from the start.
The failure mode is worth naming out loud. An external team that writes code nobody inside your company understands has not reduced your key-person risk. It has moved the dependency outside your walls, which is harder to see and harder to fix than the version you started with. The conditions above are what separate a second line of ownership from a new and less visible single point of failure, and any partner worth working with will hold themselves to them.
How to Know the Dependency Has Reduced
Measure the change rather than trusting the feeling of progress. Track the percentage of critical modules with at least two capable owners, the percentage of critical workflows with tested runbooks, and the percentage of production deployments that still require one specific individual. Track the number of components without automated tests, the number of support escalations that need senior-developer intervention, the time it takes a new engineer to make a safe production change, and the number of undocumented customer-specific behaviors you have found and written down.
Take these measurements at day 0 and again at day 90, and publish the comparison internally. The delta is what tells you the work is real, and it is what justifies continuing into the next quarter when the urgency of the original near-miss has faded.
Frequently Asked Questions
What is key person risk in software development?
Key-person risk exists when critical parts of a product become difficult to change, release, or support because one individual holds the necessary knowledge. It covers code, deployment processes, customer-specific behavior, and domain rules, and it is distinct from having too few engineers. A team can be fully staffed and still carry serious key-person risk if the knowledge sits in one head.
What is a good bus factor for a software team?
A good bus factor is high enough that losing any single person does not stall the product. In practice that means at least two people who can work independently in every revenue-critical domain, including deployment and production troubleshooting, not only application code. The areas teams forget to count are operations and customer-specific behavior, which is usually where the bus factor is lowest.
Does hiring another developer reduce key person risk?
Not by itself. A new hire adds capacity, but at first it increases the load on the person who already holds the knowledge, because that person becomes the reviewer and the teacher. Risk falls only when a second person can independently perform the work, which takes deliberate pairing, tests, and runbooks rather than time alone.
How long does it take to reduce key person risk?
A focused 90-day program is realistic for a single product. Roughly 30 days to map the risk into a written register, 30 to build redundancy through pairing, characterization tests, and runbooks, and 30 to verify by having a different engineer perform the work unaided. The verification month is the one that proves the transfer happened rather than assuming it did.
