The Bus Factor: When One Person Leaving Stalls the Whole Company

Ask any leadership team a simple question and watch the room go quiet: which single person, if they resigned tomorrow, would stall a process the company depends on? Almost everyone can name someone in ten seconds. The one who really understands the month-end close. The one who holds the biggest customer. The one who is the only person left who can keep the old order system running. That instant recognition is the problem. It means the company already knows it has a single point of failure and has simply learned to live with it.

Engineers have a blunt name for this. They call it the bus factor: the minimum number of people who would have to be hit by a bus before a project is dead in the water. A bus factor of one is the worst possible score. It means everything in that area rests on a single person, the way a heavy beam can rest on a single pillar - stable until the day it is not. For most teams, in most critical areas, the honest number is uncomfortably close to one.

This piece is for the operations leader, COO or Geschaeftsfuehrer who has felt that quiet dread when a key person books a long holiday or hands in their notice. The argument is that the usual defences - wikis, SharePoint, a handover document written in someone’s last week - do not actually raise the bus factor, because they capture what was done and never the reasoning behind it. And that there is now a structural way to raise it: a living company memory that survives turnover, with AI employees that can run the concentrated person’s routine work across the systems you already use.

What the Bus Factor Actually Measures

The bus factor started as a piece of software-engineering gallows humour and turned into one of the sharpest risk metrics a company can use. It is deliberately morbid so that nobody can pretend the risk is abstract. Strip away the dark joke and it is simply a count: for any capability that matters, how many people could keep it running if the others were gone.

• It is a minimum, not an average - the bus factor is the smallest number of departures that breaks something, so one deep specialist among ten generalists still gives you a bus factor of one for their speciality.
• It measures capability, not headcount - a team of twenty can have a bus factor of one for the thing that actually matters, because only one of them can run the core process end to end.
• It applies far beyond code - the concentrated capability might be a customer relationship, a compliance filing, a pricing model, a supplier negotiation, or the tribal knowledge of a bespoke system nobody documented.
• It is about tacit knowledge, not files - Gartner estimates 70 to 80 percent of enterprise knowledge is tacit and never written down⁶. The bus factor measures exactly that undocumented layer.
• It hides in plain sight - the risk is invisible on a good day and total on a bad one, which is why companies chronically under-price it until the person is already gone.
• It is fixable and measurable - unlike vague worries about resilience, the bus factor gives you a number per capability that you can raise on purpose.

The reason the number matters is that it turns a feeling into a target. “We rely too much on Anna” is a worry. “The close has a bus factor of one and it takes nine months to replace Anna’s fluency” is a decision waiting to be made.

How Teams Drift to a Bus Factor of One

Nobody sits in a meeting and decides to make one person indispensable. A bus factor of one is not a decision; it is a sediment. It settles one reasonable choice at a time, and every single choice looks correct in the moment it is made.

1. The builder becomes the owner - whoever set up the system is the obvious person to keep running it, so knowledge of it never leaves their hands and never has to be explained to anyone else.
2. Specialisation rewards depth - it is efficient to let the person who is fastest at a task keep doing it. Depth in one head beats shallow knowledge in five, right up until that head is unavailable.
3. Relationships stick to people - the customer or supplier who trusts one account manager keeps asking for them by name, and the relationship quietly becomes the person rather than the company.
4. The expert is too busy to document - the more critical someone is, the less slack they have to write things down, so the most concentrated knowledge is the least documented.
5. Documentation that exists goes stale - the wiki describes how the process worked two reorganisations ago, so people stop trusting it and go back to asking the one person who knows.
6. Being needed feels good and pays - conscious or not, indispensability brings security and status, so there is rarely an incentive for the concentrated person to spread what they know.
7. Turnover keeps resetting the clock - average knowledge-worker tenure has fallen to under four years³, so even a second person you train is a temporary fix that walks out on their own timeline.

The result is a company that is excellent at its work and quietly brittle underneath it. The brittleness only becomes visible at the exact moment you can least afford it: a resignation letter, a long illness, a competitor poaching your one specialist. German industry has a vivid version of this, where firms with historically grown software depend on a single retired engineer who still maintains a critical system on the side - in one documented case at the age of 82⁷.

What the 2026 Data Says About Single-Person Dependency

The bus factor sounds like an anecdote, but it has been measured, and the numbers are worse than most leaders assume. Independent research from software engineering, HR and business continuity all lands in the same place: concentration in single people is the norm, not the exception.

• Three quarters of projects have a bus factor of two or fewer - a study of 133 popular GitHub applications found 46 percent had a bus factor of one and a further 28 percent a bus factor of two¹. In practice that is 74 percent one bad day from a stall².
• Most companies would be seriously disrupted by one departure - a 2026 analysis found that in 72 percent of companies, the departure of at least one individual would cause serious disruption⁴.
• Most leaders expect to lose a key person soon - in the Mercer Marsh Benefits survey, most respondents expected to lose a key person within three years and a majority predicted a high operational impact when it happened⁹.
• The knowledge that matters is unwritten - Gartner estimates 70 to 80 percent of enterprise knowledge is tacit and never captured in any retrievable form⁶, which is precisely the knowledge a bus factor of one puts at risk.
• Companies know it and still do nothing - Deloitte reports that 85 percent of C-suite leaders view the coming knowledge exodus as a moderate to mission-critical threat, yet 92 percent of organisations fail to consistently capture knowledge from soon-to-be-leavers³.
• AI is quietly becoming a new single point of failure - with nearly three quarters of organisations already automating processes with AI, CIOs warn that concentrating those workflows on a handful of vendors and models creates a fresh point of failure most companies cannot even inventory⁵.
• The demographic version is arriving at once - in a 2026 workforce study, 59 percent of over-55 employees in retail and manufacturing were set to retire within five years, and only 28 percent of operational leaders were confident organisational knowledge would survive their departure⁸.

Modelling Your Key-Person Exposure in Euros

A worried feeling does not get funded; a number does. So put a number on it. Take one concentrated role - a bus factor of one - with a fully-loaded cost of 90,000 euros a year, roughly consistent with German labour costs of 41 euros per hour worked¹¹, and cost out what happens when that single point of failure leaves.

The cost of losing one concentrated person

Two hundred thousand euros is the cost of one bus-factor-of-one role turning over once, and it is deliberately conservative - it ignores the customer you lose when the only person who knew them leaves, and the strategic decisions made worse because the context was gone.

Scaling it to the company

One departure is a shock; the real exposure is the steady-state risk you carry every year across every concentrated role. Two methods converge on the same uncomfortable range for a mid-sized company.

1. Method A - risk-adjusted per role - with tenure under four years, any given person has roughly a 25 percent chance of leaving in a year³. At ~200,000 euros per departure, that is ~50,000 euros of expected annual exposure per bus-factor-of-one role.
2. Method B - portfolio of concentrated roles - a 200-person company typically carries eight to a dozen genuine single points of failure (the close, the key account, the legacy system, the filing, and so on). At ~50,000 euros each, that is 400,000 to 600,000 euros of expected annual exposure.
3. The convergence - both routes land in the mid-six figures a year for a mid-sized business, before counting lost customers or worse decisions. The bus factor is not a soft risk. It is a line item you are already paying and never see.

Why Wikis, SharePoint and Handover Docs Never Lower It

Every company already thinks it has a defence against this. We have a wiki. We have SharePoint. We ask leavers to write a handover document. The uncomfortable truth is that none of these meaningfully raises the bus factor, because they capture the wrong layer of what the concentrated person knows.

They capture outcomes, not reasoning

• They record the what, never the why - a document says “we price this segment at minus 12 percent”; it does not say why, which cases are the exception, or when to break the rule. The reasoning is the valuable part, and it stays in the person’s head.
• They miss the exception-handling - the concentrated person is valuable precisely because they know what to do when the standard path breaks. Exceptions are, by definition, the cases nobody wrote a procedure for.
• They flatten judgement into steps - a checklist can capture a sequence but not the instinct that tells an expert something is off before the data shows it. That instinct is exactly what a bus factor of one puts at risk.

They decay from the moment they are written

• Nobody updates them - the most critical person has the least time to maintain documentation, so the wiki describes a version of the process that no longer exists.
• They are trusted less over time - once people have been burned by an out-of-date page, they stop reading the wiki and go back to asking the one person, which re-concentrates the knowledge.
• The handover doc is a panic snapshot - written in a departing employee’s final week, it is whatever they happened to remember under time pressure, which is a small and arbitrary slice of what they actually knew.

They are passive and never act

• They wait to be searched - a document does nothing until someone thinks to look for it, knows the right term, and has time. At the moment work needs doing, none of that is true.
• They cannot do the work - even a perfect wiki still needs a competent human to read it and act. It raises how fast a replacement could learn, not whether the capability survives the gap.
• They do not notice they are wrong - a stale document cannot flag its own decay, so the bus factor silently drifts back to one while everyone believes it is documented.

Raising the Bus Factor With a Company Brain

If the problem is that the reasoning behind the work lives only in one person’s head, the fix is a place where that reasoning lives instead - and that stays current on its own. That is what a Company Brain is: a living memory of how your company actually works, built from the daily work rather than from someone finding time to write a document.

• It holds the reasoning, not just the record - the why behind the pricing, the exception for this customer, the trade-off that was accepted. The layer that normally leaves with the person becomes something the company keeps.
• It is fed by the work and by corrections - it captures knowledge in use, from the email thread, the Teams message, the CRM entry and the human correction, so it reflects how the work is done now, not how a wiki described it a year ago.
• It captures the exception-handling - because it learns from real cases, it accumulates exactly the non-standard situations that a procedure never covers and that made the concentrated person irreplaceable.
• It is specific, not general - a wiki knows the policy; the Company Brain knows that this account always splits invoices by cost centre and why the last renewal nearly slipped.
• It survives turnover by design - when the person who “just knows how this works” leaves, the reasoning does not leave with them. That, precisely, is how the bus factor rises.
• It is shared, not siloed - anyone authorised, human or AI employee, can draw on the same memory, so the capability stops being one person’s private asset.

This is a different object from a knowledge base bolted onto your documents. A knowledge base indexes what was already written down - the small, outcome-only slice. A Company Brain captures what was never written: the decision-reasoning and exception-handling that a bus factor of one puts most at risk. It is the difference between a filing cabinet and a colleague who remembers.

Running the Concentrated Person’s Routine Work: AI Employees

A Company Brain holds the reasoning. Something still has to do the work. That is the job of an AI employee: not a chatbot that answers questions, but a digital colleague that runs the concentrated person’s recurring, routine tasks across the systems you already use - and escalates the genuine judgement calls to a human with context attached. This is what turns a bus factor of one into a bus factor of two without hiring, because the routine part of the capability now has a second, tireless holder.

• It runs the routine cases end to end - the standard version of the concentrated work, which is most of the volume, it completes start to finish, grounded in the Company Brain so it works the way your company works.
• It works across the real systems - it reads and writes in email, Teams, SharePoint, the CRM and the ERP, so it does the actual work rather than describing it.
• It escalates real judgement calls with context - when a case genuinely needs a human, it does not dump a bare task; it hands over the decision plus the full background, so the human decides in minutes instead of re-discovering for an hour.
• It does not resign, forget or go on holiday - the routine part of the capability is now held in something that is always available, which is the whole point of raising the bus factor.
• It closes the loop back - every case it handles, and every human correction, feeds back into the Company Brain, so the coverage gets stronger with use instead of decaying like a wiki.
• It frees the expert for the hard cases - the specialist stops being the only one who can keep the lights on and spends their judgement on the genuinely non-routine work that needs a human.

This is the difference between describing work and doing it. A dashboard can tell you a process is stuck; only something with write access to your CRM, ERP and inbox can move it. Gartner expects 40 percent of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5 percent a year earlier¹⁴, and projects that agentic AI will autonomously resolve 80 percent of common customer service issues by 2029¹⁵. The concentrated, routine work behind a bus factor of one is exactly the kind of work that shift points toward.

What this looks like at three real single points of failure

• The month-end close - the one accountant who “just knows how we close” goes on leave. The AI employee runs the recurring reconciliations, tie-outs and the reporting pack the way the Company Brain has learned they are done, and escalates only the genuine anomalies - so the close still lands on time.
• The key account - the account manager holding the biggest customer resigns. The AI employee keeps the relationship’s routine running - renewal prep, order handling, the standing weekly update - grounded in the full history in the Company Brain, so the customer never feels the gap while a successor comes up to speed.
• The legacy system operator - the sole operator of a bespoke order system is unavailable. The AI employee runs the documented routine operations and the known exception-handling captured from years of the operator’s actual work, and flags anything outside that pattern to IT with the context attached.

Not a Wiki, Not Cross-Training: Drawing the Line Clearly

Because single-person dependency sits near both knowledge management and workforce planning, it is easy to assume the fix is a tool or a habit you already have. It is not. The distinction matters, because reaching for the wrong category is how companies end up with a wiki, a cross-trained backup, and the same bus factor of one.

• A wiki is still useful - for stable, general reference it is fine. It is the wrong tool for the specific, current reasoning and exception-handling that a bus factor of one puts at risk.
• Cross-training is still worth doing - a trained backup is genuinely better than none. But it doubles the cost of the capability, transfers outcomes more than living reasoning, and decays back to one as the backup forgets, moves or leaves.
• The new thing is durable, acting memory - the combination captures the reasoning as the work happens, keeps it current, and does the routine work. No wiki and no cross-training plan does all three, which is why the bus factor has stayed at one through every previous fix.

Raise Your Bus Factor in 90 Days

You do not de-risk every role at once. You fix the single point of failure that would hurt most, prove the model, and expand. Here is the sequence that works, one concentrated role at a time.

Phase 1: Find and measure the exposure (Weeks 1-4)

1. Week 1: Run the two-week test - across your top capabilities, ask what stops if each owner is unavailable for two weeks. Rank the resulting single points of failure by damage times likelihood.
2. Week 2: Pick the worst one - choose the role where a departure is both most damaging and most likely, and where the work is routine enough to be partly held by a system. The close, a key account, or a legacy system are common winners.
3. Week 3: Baseline the exposure - put a euro figure on it with your own numbers: replacement cost, ramp time, colleague drag, process stall. This is what you will reduce, and what justifies the work.
4. Week 4: Map what the person actually knows - sit with them and document the reasoning and the exceptions, not just the steps. This becomes the seed of the Company Brain for this capability.

Phase 2: Capture and build the second holder (Weeks 5-8)

5. Week 5-6: Capture reasoning in use - connect to the email, Teams, CRM and ERP around the role so the Company Brain fills from the real work, not a form. Confirm it holds the why and the exceptions, not just the outcome.
6. Week 7: Build the AI employee - stand up an AI employee that runs the routine cases end to end from the Company Brain and escalates the rest with context. The concentrated person stays the human owner and supervisor.
7. Week 8: Test on history and edge cases - run it against past cases and the ugly exceptions from Week 4. Adjust until the routine cases pass cleanly and the escalations arrive with the right background.

Phase 3: Run it live and measure (Weeks 9-12)

9. Week 9: Run in parallel - the AI employee handles the routine work alongside the concentrated person so nothing breaks. Compare its output against theirs.
10. Week 10-11: Go live on the routine - move the recurring cases over, keep the human on the judgement calls, and let the Company Brain sharpen with every case and correction.
11. Week 12: Re-measure the bus factor - confirm the capability now survives the person’s two-week absence, and re-run the exposure number against the Week 3 baseline. Then pick the next concentrated role.

How Superkind Fits

Superkind builds custom AI employees for SMEs and enterprises, grounded in a Company Brain. The approach is process-first: we start at your riskiest concentrated role, not a generic product, and we sit on top of the systems you already run instead of adding another place knowledge can get stranded.

• Process-first exposure mapping - we run the two-week test with you and document the reasoning and exceptions behind the concentrated role, before writing any code.
• A Company Brain per capability - we capture the why, the exception-handling and the relationships that the role depends on, fed from the real work so it stays current and survives turnover.
• AI employees that hold the routine work - they run the recurring cases end to end across your CRM, ERP, email, Teams and SharePoint, escalating genuine judgement calls with the background attached.
• Sits on top of your stack - Salesforce, SAP, HubSpot, Microsoft 365 and any API-based system. No rip-and-replace, nothing new for your team to learn.
• Live in weeks, on one role - the first capability is de-risked in roughly 8 to 12 weeks, measured against a baseline exposure you set, before expanding to the next.
• Outcomes, not licenses - priced per capability against measurable exposure reduction, not per seat or per multi-year platform contract.
• Humans stay accountable - a named owner keeps the capability; the AI employee handles the routine and escalates the rest, with every action logged for audit and EU AI Act transparency¹².
• It compounds - each role you de-risk feeds the same Company Brain and reuses the same integration layer, so the second is faster than the first.

Decision Framework: Which Roles to De-Risk

Not every concentrated role needs this treatment. Here is how to tell a genuine single point of failure worth de-risking from one where a simpler fix will do.

Frequently Asked Questions

Related Articles

• Institutional Amnesia: Why Your Company Keeps Solving the Same Problem Twice
• The Retirement Cliff: Capturing Decades of Expertise Before Your Experts Walk Out the Door
• The Offboarding Interview, Automated: Capturing a Departing Employee’s Knowledge Before Their Last Day
• The Cross-Department Handoff: Where Work and Knowledge Go to Die
• The Knowledge Half-Life: Why Your Wiki Is Already Out of Date
• The Context Graph: Capturing the Reasoning Behind Every Decision

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI agents that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. He believes the Mittelstand has everything it needs to lead in AI - it just needs the right approach.