Dependency on a Single Engineer as Organizational Debt

Bus factor is the minimum number of team members whose departure would put a project in serious trouble. A bus factor of 1 doesn't mean one person is doing the work. It means one person is holding the knowledge that lets the work continue. Everyone else could be present, employed, motivated. Even so, it wouldn't matter.

The term got popular in the 1990s, in conversations about project risk. Some people flip it and call it the "lottery factor," same math, friendlier premise. The earliest documented reference sits in the 1994 PLoP conference proceedings (published the following year), where it appears as "truck number," and an even earlier mention occurs in a 1994 Python mailing-list post. What's changed is how often it occurs in practice.

What does a bus factor of 1 look like on the ground? It's the only person who can run the release process. The only person who understands the billing pipeline. The only person who knows why the legacy authentication system behaves the way it does. Maybe it's the only person who understands how the company's ERP talks to production, or how some custom application that grew organically actually fits together. None of these are exotic scenarios. They're common enough that most engineering leads could name one right now, sitting in their own org chart.

This is really about concentration. The team can look completely fine, shipping, hitting deadlines, functioning, right up until the moment that one person is unreachable. Then the dependency that was always there becomes visible all at once, usually at the worst possible time. What makes this especially hard to catch early is that the person at the center of it is often the team's best engineer, reliable, fast, trusted with the hard stuff. Their competence hides the fragility building underneath it, because the team's most reliable, fastest, most trusted engineer is usually the same person whose absence would be most damaging.

So why does this pattern form in the first place? It's rarely negligence. It's usually reward.

How the "hero engineer" culture manufactures the problem it celebrates

Consider the engineer everyone calls a 10x performer Bus factor in technical departments in 2025 | TechMiners. Celebrating that person feels natural, even earned. But celebrating individual output, specifically, creates a feedback loop: it rewards isolation, solo ownership of the hardest problems, and skipping the collaborative steps that would otherwise slow the hero down Bus factor in technical departments in 2025 | TechMiners.

Which raises an obvious question: what exactly gets skipped? Usually it's pair programming, code review, documentation, the unglamorous practices that actually raise bus factor. Under hero culture, those get reframed as friction, as things that slow down the person who's clearly capable of doing it alone anyway. The result is that knowledge hoarding gets implicitly rewarded over knowledge sharing, even though nobody would describe it that way out loud Bus factor in technical departments in 2025 | TechMiners. The engineer isn't hoarding knowledge out of malice. The system around them just never asked them to share it.

AI coding tools have made this sharper, not softer. A single developer with the right tools can now prototype in days what used to take a small team weeks. That's genuinely useful, and it's also a trap: it makes single-engineer dependency feel more rational in the short term while it deepens the structural risk that dependency creates. There's a new variant, sometimes called the "AI Code Wrangler," the one person who actually understands the tangle of human-written and AI-generated code sitting in the repo. Tribal knowledge used to build up over years. Now it can build up in weeks, in a codebase nobody else has time to fully read.

None of this is really about one person's habits. It's a system producing a predictable output, and that output behaves like debt.

Why this is organizational debt, not just a staffing gap

If this were just a staffing gap, the fix would be simple: hire more engineers. Headcount doesn't touch knowledge concentration. Only knowledge distribution does.

What actually piles up, quietly, month over month? Architecture decisions that were never written down. Deployment steps that live only in someone's memory. Integration logic nobody else has touched since it was built. Documentation debt is the clearest symptom: the plan is always to write it up "later," and later has a way of never arriving, which then makes onboarding slower and knowledge sharing harder for everyone downstream.

This behaves exactly like financial debt. The principal, the size of the knowledge gap, grows silently while the team keeps shipping features and closing sprints. The interest gets paid later, in slower incident response, in more cautious change management, in onboarding that takes twice as long as it should. McKinsey estimates the hidden drag from technical debt adds 10 to 20% to every project budget, and Deloitte's 2026 Global Technology Leadership Study puts technical debt at 21 to 40% of a typical organization's total IT spending Bus factor in technical departments in 2025 | TechMiners. Single-engineer dependency is one of the main generators feeding that number Bus factor in technical departments in 2025 | TechMiners.

There's a scaling angle too. New hires can't meaningfully contribute to systems they can't access, conceptually or structurally Bus factor in technical departments in 2025 | TechMiners. So scaling a team without first addressing where knowledge is concentrated turns out to be expensive and slow, exactly the opposite of what scaling is supposed to buy. Once the debt framing lands, the real question isn't whether the organization has this problem. Almost every organization does, to some degree. The question is how large the balance has grown, and what event is going to trigger the bill.

When the debt comes due: the moments that expose the dependency

The dependency doesn't reveal itself gradually. It appears all at once. The team looks fine, the roadmap looks fine, right up until the exact moment it doesn't.

What actually triggers it? The engineer resigns, and the roadmap stalls while someone tries to reconstruct a mental model that took years to build. An extended illness or parental leave hits, and the team discovers, mid-sprint, that it can't safely deploy without that one person in the room. A promotion or reassignment moves the engineer sideways, and the system they used to own goes quietly frozen, nobody touching it, nobody quite able to. Or a production incident lands directly on the one system only they understand, and response time, which should be measured in minutes, stretches into hours.

This isn't just anecdotal risk. Organizations carrying high technical debt see outage rates two to three times higher than those that don't gainhq.com. Southwest Airlines is the sobering real-world case here: its failure to address technical debt in crew scheduling software led to losses exceeding $1 billion. That's a real risk built into ordinary systems, not a hypothetical about some engineer quitting. That's what happens when a system nobody fully understands anymore finally gets tested under real pressure.

There's a quieter version of this failure mode too: companies repeatedly call back a former employee or contractor because that person remains the only one who understands a given system, and this arrangement tends to recur. Premium day rates get paid for knowledge that should have lived inside the company all along, and every additional engagement deepens the dependency instead of resolving it.

This is visible financially, in ways that get formalized. Acquiring a company whose core product runs on a bus factor of 1 means the acquirer's investment is really a bet on specific individuals choosing to stay. That's exactly why bus factor gets checked during technology due diligence, to surface concentrated knowledge risk before it affects scalability, maintenance, or valuation. Discovering that kind of dependency mid-diligence can derail a funding round entirely, forcing renegotiation or killing the deal outright, and investors routinely discount valuations where key-person risk runs high.

Two contexts make this pattern almost structurally guaranteed rather than incidental: products moving from MVP to production, and nonprofit organizations. Each stands on its own terms.

How the MVP-to-production transition locks in the dependency

Early on, this setup is the point. A small team moves fast precisely because nearly everyone understands the whole product end to end, and the same engineer might handle onboarding in the morning, infrastructure in the afternoon, and a production fire before the day's done. That flexibility is appropriate at that stage, arguably the only way an MVP gets built at all.

But what happens once the product actually has paying customers, enterprise contracts, several live integrations, and a roadmap that can't afford to pause? Of those, the freelancer path is specifically where single-engineer dependency tends to crystallize earliest, for the obvious reason: one person, one contract, one mental model of the whole system.

AI builder tools have their own version of this trap. Past that point, any complex application needs a handoff to traditional development, and the "savings" that made the tool attractive in the first place disappear entirely, because the context gap has become total chronoinnovation.com.

Mature organizations look almost the opposite. Google Cloud's 2025 DORA research found that 90% of surveyed organizations had adopted internal platforms and 76% had dedicated platform teams. That's deliberate knowledge distribution at scale: reusable infrastructure, clearer ownership boundaries, environments where more engineers can contribute without a coordination tax on every change. The solo MVP build sits at the far end of that spectrum, the steepest possible knowledge cliff, maximum context loss the moment the original builder steps away.

"Good enough" is a moving target here. Getting a product to launch and keeping it reliably live are two different standards entirely. Once real users depend on the thing, the solo-engineer assumption that worked fine during the build phase becomes a live production risk. So what should a founder actually do about it? Not necessarily rush to hire a full internal team. The more useful goal is making sure the product and its systems are legible to more than one person, and that whoever owns engineering is accountable for that legibility over time, not just at the moment of launch. A long-term technical partner who rebuilds on solid foundations and stays through the maintenance years offers a structural answer here, ongoing shared ownership rather than a one-time handoff that just relocates the risk.

Why nonprofits are the highest-risk cohort for this pattern

If MVPs create this condition through speed, nonprofits create it through scarcity, and the two produce a strikingly similar result gainhq.com.

Start with the baseline: many nonprofits have no full-time IT staff member at all. Technology responsibilities tend to land on whichever staffer or volunteer happens to be "tech-savvy," usually without any IT roadmap guiding the decisions being made. Layer onto that the typical systems profile: infrastructure cobbled together over years out of donated hardware, grant-funded software, and licenses nobody quite remembers renewing. That's close to the ideal environment for maximum single-engineer dependency to take hold, because the constraints leave little room for anything else.

Volunteers make the picture more fragile still. Most are giving the cause a slice of a day already split between a full-time job and everything else in their life. Burnout, in this context, is itself a bus-factor event: the volunteer leaves, and whatever they understood about the system leaves with them. There's rarely a handoff period. There's rarely even a warning.

Compliance raises the stakes further. Nonprofits increasingly have to meet standards like HIPAA, PCI-DSS, and various state data protection laws, often because donors, grantmakers, and partners expect it. If the one person who understands how donor data actually moves through the system disappears, compliance doesn't degrade slowly. It breaks immediately.

There is a structural response. Develop for Good runs on a model where volunteers have contributed to more than 320 nonprofit software projects, building apps and websites for nonprofits around the world. What makes the model interesting is the distribution: engineering knowledge gets spread across rotating student cohorts instead of concentrating in one long-term hire, a direct answer to the exact fragility described above. Any real solution for this cohort has to work inside limited budgets, mission-first priorities, and staff already wearing three or four hats, which means engineering choices that stay legible and maintainable without assuming a dedicated technical team will ever exist.

Both contexts, MVPs racing to launch and nonprofits stretched thin, arrive at the same place from opposite directions. Which raises the real question: what does fixing this actually take? Having named the problem and its two sharpest contexts, the piece can now address what deliberate mitigation actually looks like.

What reducing the dependency requires

The goal is making sure critical knowledge is reusable, reviewable, and transferable, so no single absence takes down a system.

A few practical measures do most of the work, without adding heavy process. Documentation matters most when it's written for the person who wasn't in the room: runbooks, architecture decision records, onboarding checklists that assume zero prior context. Shared code ownership, through pair programming, rotation of responsibilities, and regular code review, isn't overhead so much as the actual mechanism by which knowledge spreads across a team instead of pooling in one person. Automated operations (CI/CD pipelines, infrastructure as code, credential vaults) turn deployment and recovery into something process-driven rather than person-dependent. And having more than one person who can safely perform the critical administrative or deployment actions closes the most acute version of the gap.

This risk doesn't stop at the edge of a company's own codebase. A 2016 study looked at 25 popular open-source projects and found that 10 of them carried a bus factor of 1 Bus factor in technical departments in 2025 | TechMiners. Any team building on those libraries inherits that fragility whether it realizes it or not Bus factor in technical departments in 2025 | TechMiners.

The instinct to treat this as an individual failing (some engineer who just didn't document enough) misses what's actually going on. Most of what generates technical debt comes from organizational choices, not individual mistakes, and that's exactly why it can be deliberately changed rather than just tolerated. Companies in the bottom quintile for tech debt severity are 40% more likely to have IT modernization efforts that go incomplete or get canceled outright, compared to companies in the top quintile.

None of this means every system needs the same level of redundancy. Fit-for-purpose resilience means critical systems and release paths earn a higher bus factor than low-stakes experimental code sitting in a side branch. The point is fit-for-purpose coverage, focused where it matters most, making sure the systems where a single person's absence would be genuinely catastrophic get the attention first.

For a founder, this often comes down to trust rather than headcount: not needing to own engineering personally, but needing confidence that engineering is owned, documented, and survivable without any one individual holding it all together. A long-term technical partner who stays on, rather than handing off and disappearing, offers exactly that kind of structural answer. What matters most, in the end, is recognizing single-engineer dependency for what it actually is: not a personnel quirk, not a temporary phase a team will grow out of, but organizational debt, accumulating on a clock, whether anyone's watching it or not.