The most dangerous person in your engineering organisation is not the underperformer. It is the person everyone depends on — the one who knows how the payment gateway was wired together in 2022, who holds the undocumented SSH key for the production legacy system, who wrote the authentication layer in a sprint and never had time to explain it to anyone.
When that person leaves, resigns in frustration, takes a medical leave, or accepts the offer you could not match — you do not lose a headcount. You lose a system you cannot operate.
The Bus Factor Is a Risk Metric, Not a Compliment
"Bus factor" is the number of people who would have to be hit by a bus before a project is dead. A bus factor of one is a systems failure masquerading as a personnel success.
The tragedy is that high-bus-factor engineers usually became that way through a combination of ambition, competence, and organisational neglect. They ran fast when the company needed speed. Nobody enforced documentation standards. Their pull requests were never reviewed because nobody else could review them. Their domain grew until they owned it entirely — and the company rewarded the output while ignoring the concentration of risk it created.
The 10x engineer is real. The problem is that most "10x engineers" are operating as a 10x engineer and a 10x liability simultaneously, and organisations track only the first number.
The hidden premium you're paying
When a hero engineer exits mid-project, the downstream costs compound fast: emergency contractor fees (often 2–3× the employee rate), delayed customer commitments, engineering team overtime, leadership attention diverted from strategy to triage. I have seen a single unplanned senior departure cost a 30-person engineering org north of six months of runway-equivalent impact. It rarely appears on the post-mortem.
Why Engineering Organisations Tolerate This
Before you can fix the problem, you need to be honest about why it persists.
The short-term incentive is misaligned. A hero engineer is useful. They unblock things. When the database is falling over at 2am, you call them. When the enterprise client needs a bespoke integration in two weeks, they deliver. Every individual interaction signals value. The systemic risk is invisible until it is not.
Documentation has no immediate P&L impact. It is genuinely hard to measure the value of a system someone else can understand. Nobody gets a promotion for writing a runbook. The incentive structure in most engineering teams rewards shipping, not knowledge transfer.
Engineering managers avoid the conversation. Telling your best engineer that their knowledge-hoarding is a risk is uncomfortable — especially when that engineer is also delivering. The easier path is to defer the conversation. The deferral compounds the risk.
Boards and investors rarely ask. Most technical due diligence focuses on architecture, security, and scaling — not knowledge distribution. Bus factor risk does not appear on a balance sheet until it causes a write-down.
How to Identify Your SPOFs
Before you can remediate, you need to be specific. "We depend too much on Marcus" is not an engineering risk assessment — it is gossip. Make it rigorous.
Run this analysis quarterly:
| Risk Indicator | How to Measure | Red Flag Threshold |
|---|---|---|
| Code authorship concentration | git log ownership analysis per module | 1 author owns more than 60% of a critical path |
| PR review bottleneck | Who reviews the majority of PRs that ship to prod | 1 reviewer on more than 50% of prod-critical merges |
| On-call escalation pattern | Who gets paged or messaged when on-call is stuck | Same person escalated more than 3× per month |
| Documentation absence | Wiki pages, ADRs, runbooks authored by role | Entire subsystem with 0 documentation not written by its author |
| Deployment gate | Who can actually release the system | Fewer than 2 people with production deployment access |
| Institutional knowledge | Who do new hires ask when they are stuck | Same name coming up repeatedly in onboarding feedback |
If the same name appears in three or more of these columns, you have a SPOF. If that person is also your highest performer, you have an urgent governance problem.
The Four Failure Modes
Not all SPOFs fail the same way. Knowing the mode helps you price the risk correctly.
The four paths look like this:
Mode 1: Voluntary departure. The engineer accepts a better offer or burns out. You get two weeks of notice and a handoff that covers 40% of what you actually need to know. The rest surfaces as incidents over the following six months.
Mode 2: Involuntary event. Medical leave, family emergency, unexpected termination. No notice, no handoff, no documentation. The system has to be reverse-engineered under pressure, usually during an outage.
Mode 3: Leverage. The engineer — consciously or not — recognises that their indispensability is a form of job security. They become slower to document, slower to mentor, resistant to pairing. The knowledge moat deepens.
Mode 4: Zombie ownership. The engineer has moved into a management or strategic role, but their old system has no real successor. They are still the escalation point, still the only person who understands the legacy module, still getting paged — now in addition to their new responsibilities. Velocity on both fronts degrades.
Mode 3 is the most underdiagnosed
Knowledge concentration sometimes becomes a deliberate career strategy. Engineers who have been made redundant before — or who have seen peers laid off while "non-essential" contributors were retained — sometimes protect their moat consciously. Addressing this requires organisational trust, not just process change. If engineers do not believe knowledge-sharing is safe, they will not do it.
What to Actually Do About It
The remediation is not "make the 10x engineer document everything." That never works. The person who built the system in their head will write documentation that only they can fully interpret, because they are missing the context of what they take for granted.
Fix this structurally:
Establish a minimum bus factor policy
Define a number — I typically recommend 2 for anything in the critical path, 3 for production deployment capability — and treat it as a non-negotiable engineering standard, not a best practice. Review it in your quarterly engineering health check.
Make pairing mandatory on critical systems
Not pair programming on every line of code. Targeted pairing: any change to a system where bus factor is 1 must have a second engineer actively involved, not just reviewing the diff. The goal is knowledge transfer, not code quality.
Require runbooks before on-call rotations
If an engineer cannot write a runbook that another engineer can follow independently, they are not ready to hand off on-call responsibility. The runbook requirement forces knowledge externalisation in a format that is immediately useful.
Use Architecture Decision Records
ADRs document not just what was built but why — the constraints, the alternatives considered, the trade-offs accepted. An ADR library is the institutional memory that persists after people leave. Most teams do not have one. Start one for every new system decision and backfill the three or four most critical existing decisions.
Rotate on-call ownership aggressively
If the same person is always on call for a system, no one else learns it under pressure. Rotate deliberately, with a shadow rotation first: the SPOF is on call with a learning engineer who takes the first action on every incident. After two rotations, the shadow runs lead.
Decouple access from identity
Production access should not live in one person's head or personal device. Shared vault-managed credentials, documented runbooks, and access policies that do not require calling a specific person at 2am are engineering infrastructure, not a nice-to-have.
The Manager's Responsibility
If you lead an engineering team and you have a SPOF, it is not the engineer's fault — it is yours. The org chart created the conditions. You are accountable for fixing them.
That does not mean penalising the hero engineer. It means changing the system:
- Explicitly reward documentation and knowledge transfer in performance reviews
- Block promotion to senior levels without demonstrated knowledge-sharing behaviour
- Make bus factor visible in engineering metrics dashboards, not hidden in one-on-ones
- Give SPOF engineers the time and mandate to close the gap — do not ask them to "find time" alongside a full delivery load
Make the SPOF engineer the bus-factor champion
The most effective remediation I have run: make the hero engineer responsible for closing their own bus factor, with a 90-day target and explicit recognition when they hit it. Most senior engineers, when given the mandate and the time, want this solved. They are usually more aware of the risk than leadership is. The blocker is rarely motivation — it is permission and capacity.
The Takeaway
A 10x engineer who is also a single point of failure is not an asset — they are a concentration of risk that compounds with every quarter of organisational neglect. Treating knowledge distribution as a governance issue, not a cultural nicety, is what separates engineering organisations that scale from those that hit a wall when one person walks out the door.
The bus factor audit takes a day. The remediation takes a quarter. The cost of doing neither shows up as an emergency you did not see coming.
If your engineering organisation has inherited this pattern and you want an outside perspective on what to fix first, let's talk — book a 30-minute discovery call and we will start with the system that is keeping you up at night.