Your senior engineer goes on parental leave. First time in three years. And then you realize, quietly, at 11pm, staring at a production bug nobody else can fix, that literally no one on your team knows how the billing system works. Just her.

That's your bus factor. And if it made your stomach drop, good. It should.

The bus factor is a measure of how many people your company can't afford to lose. If one person getting hit by a bus (or winning the lottery, or just quitting on a Tuesday) would cripple your team, your bus factor is 1. That's not a people problem. That's a structural problem you built.

Most founders don't want to admit this: you're often the bus factor. And the further you go from acknowledging it, the harder it gets to fix. This post is about how to audit your bus factor, what the number means, and, most importantly, what to do about it.

‍

What Is the Bus Factor (And Why Startups Should Care)

The term comes from software engineering. It's sometimes called the "truck factor" or the "lottery factor", the idea being that if a key person unexpectedly vanished, how badly would operations break down?

A bus factor of 1 means: one person walks out, and you're in trouble.

A bus factor of 3 means: any three people could leave tomorrow and the team could still function.

The goal isn't to make everyone replaceable, it's to make your systems resilient. High-performing teams don't depend on heroes. They depend on documented processes, clear ownership, and distributed knowledge. That's what the Founder Operating System is built on.

In the early days of a startup, a bus factor of 1 is almost inevitable. Everyone is wearing five hats. You're moving fast. Documentation is a luxury. But somewhere between 20 and 100 employees, a low bus factor stops being a startup reality and starts being a leadership failure.

‍

The cost of ignoring it

When a high-bus-factor company loses a key person, the fallout is predictable:

• Organizational knowledge disappears overnight
• Projects stall for weeks while someone rebuilds context
• Other team members burn out covering the gap
• Customers feel the difference before you do
• The remaining team quietly starts asking themselves: if this place can't function without her, what does that say about how it's actually run? And what happens to me if I'm next?

And it doesn't take a bus. A better offer. Burnout. Family circumstances. A disagreement with leadership. People leave for a hundred reasons, and the ones you least expect to leave are often the ones your systems depend on most.

‍

How to Run a Bus Factor Audit

This isn't a complicated exercise. You can run it in a team meeting or as a solo founder reflection. The goal is to get honest about where your real risks live.

‍

Step 1: Map your critical functions

List every function that keeps your company running. Not job titles, functions. Billing. Deployment. Customer onboarding. Sales handoffs. Investor reporting. Legal agreements. CRM hygiene. Whatever keeps the engine turning.

‍

Step 2: Assign a person count per function

For each function, answer this question: if I needed to complete this task tonight without the usual person, who else could do it?

If the answer is "nobody", bus factor is 1.

If the answer is "two other people could handle it", bus factor is 3.

Be honest. "Technically the instructions are in Notion" doesn't count if nobody's read them. "Our CTO knows the basics" doesn't count if the CTO has never done it without hand-holding.

‍

Step 3: Flag your red zones

Any function with a bus factor of 1 is a red zone. Any critical function where the answer is "only the founder knows" is a five-alarm fire. Write these down. Don't soften them.

‍

Step 4: Prioritize by impact and probability

Not all red zones are equal. A bus factor of 1 on your internal Confluence page management is annoying. A bus factor of 1 on your entire deployment pipeline is existential. Score each red zone on two dimensions:

• Impact if the person were gone tomorrow (1 to 5). How much breaks? For how long?
• Probability they could leave in the next 12 months (1 to 5). Tenure, engagement, market demand for their skills, life circumstances you know about.

Add the two scores. Anything above an 8 combined score gets fixed first.

‍

What to Do About a Low Bus Factor

Naming the problem is the easy part. Fixing it is what most founders skip.

Document to transfer, not to archive. Most teams create documentation that's never read. The reason is the intent: documentation written to "cover yourself" is different from documentation written to actually transfer knowledge. Write documentation as if you're explaining it to your smartest new hire on their first day. Include the why, not just the how. "We do it this way because we got burned in 2023 when X happened" is infinitely more useful than a bare process list.

Cross-train deliberately. Pick your top five red zones. Assign a shadow for each. The shadow doesn't just observe, they run the process once a quarter, with the primary person on standby. This creates a real backup, not a theoretical one.

This is also where the transition from founder mode to CEO mode gets real. Staying in "founder mode" often means you're the shadow for everything, which doesn't create resilience, it just moves the bus factor from your team to you.

Build decision rights, not just playbooks. The deeper issue isn't knowledge, it's authority. When only one person knows how, but only one person is also allowed to, you've created a bottleneck that documents can't fix.

The solution is clear decision rights. Who can approve a refund over $1,000? Who can escalate a bug to production? Who can commit to a new scope in a client call? The mastering delegation guide covers this in depth. The short version: start delegating decisions, not just tasks.

Consider the Chief of Staff question. At a certain scale, a bus factor audit reveals that the founder is the single largest risk. That's when some companies bring in a Chief of Staff or a COO to carry organizational memory, run cross-functional coordination, and build the kind of redundancy the founder simply can't build while also running the company. If you're weighing that decision, the Chief of Staff vs. COO breakdown is worth reading before you post the job.

‍

The Organizational Link: Bus Factor and Team Level

Research from Gallup shows that managers account for at least 70% of the variance in employee engagement, not strategy, perks, or pay. A bus factor of 1 on your management team is as dangerous as a bus factor of 1 on your tech stack. Both bring things to a halt.

The standard engineering definition misses something important. The bus factor concept applies just as much to culture as it does to process.

When your team's psychological safety lives inside the relationship with one manager, and that manager leaves, you watch the team regress in real time. When your company culture is carried by the founder's personal energy and presence rather than embedded in how the team works day to day, any significant founder absence (travel, illness, burnout) reveals how shallow the culture actually was.

This is why the Six Levels of High-Performing Teams framework treats Empowerment as the second level after Psychological Safety. Empowerment means building a system where people operate with autonomy, not because you trust them in theory, but because the system has been deliberately designed to function without you in the room.

A strong bus factor isn't about what happens when you're present. It's about what happens when you're not.

‍

Your OKR System and Bus Factor

One pattern worth naming: companies that have done OKR setup well tend to have naturally higher bus factors. Why? Because OKRs force the organization to get explicit about what matters, who owns it, and how we'll know we're succeeding. That clarity distributes knowledge and authority in a way that ad-hoc organizations never achieve.

If your bus factor audit reveals that nobody really knows who owns what, the OKR problem and the bus factor problem have the same root cause: unclear ownership.

‍

A Note for Founders Who Are the Bus Factor

If you ran the audit and your name showed up in half the red zones, that's data, not judgment.

Every founder I've worked with has been the bus factor at some point. The ones who stay stuck there aren't doing it because they don't care. They're doing it because building the system to replace yourself feels slower and riskier than just doing the thing. It almost always is, in the short term.

The question isn't whether you're the bottleneck. The question is what you're going to do about it this quarter.

The Founder Operating System is designed specifically for this: building the leadership infrastructure that lets you stop being the only person who can do the most important things in your company.

‍

Run the Audit This Week

Pick one function. One red zone. Run the four-step audit on it.

Not the whole company at once, that's a weekend project that never gets done. One function, this week. Find the knowledge holder. Write the playbook. Assign the shadow. Check the decision rights.

If the audit reveals something uncomfortable, that's the point.

Ready to stop being the bottleneck? Book a Founder Call or take the FOS Diagnostic.

‍

Frequently Asked Questions