By Arjun Mehta

Bus Factor = 1: Stop Your Team's Knowledge Walking Out the Door

Your team has a bus factor of 1.

That means: if one person gets hit by a bus (quits, gets sick, leaves abruptly), critical knowledge disappears and your team is in crisis.

Bus factor is a measure of resilience. A team with bus factor 3+ is healthy. They can lose someone and still function.

A team with bus factor 1 is at risk. They're one departure away from catastrophe.

Why Bus Factor Matters

1. Knowledge Loss is Expensive

When someone leaves without transferring knowledge:

• New person can't be productive for weeks or months
• Old systems aren't understood, so they're treated as "don't touch"
• Bugs in those systems take longer to fix
• Changes to those systems are risky
• Eventually you hire someone to "take over that system," but they're slower than the original person was

A senior engineer with deep knowledge of your payment system leaves. You lose 3-6 months of productivity. That's $100K+ in lost output.

2. Risk Concentrates on One Person

That one person knows the system. If they:

• Get sick (can't work for weeks)
• Get an offer from a competitor (quit)
• Have a family emergency (leave suddenly)
• Burnout (stop caring)

Your critical system is at risk.

You can't give them a raise to keep them (what if you can't afford it?). You can't control their life. You can only build redundancy.

3. That Person Becomes a Bottleneck

Since they're the only one who understands the system, everything goes through them:

• Code reviews of changes to that system
• Questions about how it works
• Decisions about architecture

They're overloaded. The team is bottlenecked. Velocity suffers.

4. You Can't Scale

If your payment system is understood by one person, you can't add a second team to work on it. You can't parallelize work. You're limited by that person's capacity.

Scaling becomes impossible.

Common High Bus-Factor Systems

• Database layer. One architect knows the schema and why it's designed that way
• Authentication. One engineer built it. Only they know the security considerations
• Infrastructure. One DevOps person knows how everything is deployed
• Payment processing. One person integrated with multiple payment processors
• Critical integrations. That complex third-party API? One person knows it
• Legacy code. Old systems that only the original builder understands

How to Measure Bus Factor

Ask these questions:

1. For each critical system, how many people truly understand it?

"Truly understand" means:

• Could debug a critical bug in 15 minutes (not 3 hours)
• Could explain the architecture to a new person
• Could modify it without introducing regressions
• Could answer questions about why it's structured that way

1. For each critical system, would the team fail if that person left?

If yes, bus factor is 1. If maybe (would be very hard for a few weeks), bus factor is 1-2. If no (would be hard but manageable), bus factor is 2+.

1. What's your minimum acceptable bus factor?

For critical systems: 3 minimum. Less than that is risky. For less critical systems: 2 is acceptable.

How to Increase Bus Factor

1. Pair Programming

When the system expert is working on the critical system, pair them with someone else.

The expert works. The partner learns. Both benefit.

Over time, the partner becomes knowledgeable enough to maintain the system.

2. Code Review With Explanation

When code review happens, explain:

• "I suggested this pattern because..."
• "This is important because..."
• "Watch out for this edge case because..."

Review becomes teaching. Knowledge transfers.

3. Rotate Assignments

After someone maintains a system for 6 months, rotate them to a different system.

Someone new takes over. The expert remains available for questions but hands off maintenance.

Now two people know the system. Bus factor increases.

4. Documentation With Narrative

Don't just document the what. Document the why.

"We chose this approach because..." "The alternative was..." "We prefer this because..."

Why matters more than what. Why explains the reasoning. If someone new needs to make a decision, they need to understand the reasoning.

5. Regular Knowledge Transfer Sessions

The expert schedules a weekly or bi-weekly session:

• "Today I'm explaining how authentication works"
• "Today I'm debugging a payment issue"
• "Today I'm planning the database refactor"

Anyone can attend. It's required for some people (backups). Optional for others.

Knowledge transfers to the group.

6. Reduce System Complexity

Complex systems have high bus factors because fewer people can understand them.

Refactor to reduce complexity:

• Break the system into smaller, understandable pieces
• Document the interfaces
• Make the code clear

Simpler systems are easier to learn. Bus factor increases.

The Measurement Tool

Glue can measure bus factor by analyzing your codebase:

• Which systems have the fewest contributors?
• Which systems are most complex (hardest to learn)?
• Which systems have the least documentation?
• Which systems are most critical?

Now you know which systems have bus factors of 1.

You can prioritize knowledge transfer efforts on the riskiest systems first.

The Business Case

Investing in bus factor reduction is ROI-positive:

• Prevents catastrophic knowledge loss. If that person leaves, you don't crash.
• Enables scaling. Multiple people can work on critical systems in parallel.
• Reduces bottlenecks. The expert isn't the gatekeeper for every decision.
• Improves morale. The expert isn't burned out. The team is more balanced.
• Increases resilience. Your team can handle unexpected events.

The cost: time spent on knowledge transfer (a few hours a week). The benefit: avoiding $100K+ loss if someone unexpectedly leaves.

The math is clear.

Red Flags

If you observe these, you have bus factor problems:

1. "We can't do X because Person Y is on vacation." Bus factor is 1.

2. "Person Z is the only one who understands the database." Bus factor is 1.

3. "If we lose Person Q, we're in trouble." Bus factor is 1 or 2.

4. "I'm afraid to change that code because only Person X understands it." Bus factor is 1.

5. "New people take 3-4 months to learn the system." Bus factor is low (nobody else knows the system well enough to teach)

Starting the Fix

1. Map your systems. What are your top 10 critical systems?

2. Assess bus factor. For each, how many people truly understand it?

3. Prioritize. Which have the highest risk (bus factor 1 + critical)?

4. Assign knowledge transfer. Pair the expert with someone who will learn.

5. Measure progress. "Person A is now 50% comfortable with the system. By Q4, 80%."

6. Celebrate completion. "We've distributed knowledge of the payment system. Bus factor is now 3. We're safer."

Bus factor of 1 is a catastrophic liability. Address it now before someone leaves.

---

Frequently Asked Questions

What's the ideal bus factor? For critical systems: 3+. That means you can lose someone and still function. For less critical systems: 2 is fine.

Doesn't increasing bus factor slow down development? Initially, yes. Pair programming and knowledge transfer take time. But long-term, it increases velocity because people aren't bottlenecked and the system is easier to understand.

What if the expert doesn't want to share? Then you have a trust/culture problem. Address it. Make it clear: distributed knowledge is non-negotiable. It's for the team's resilience, not to diminish the expert's value.