The Bus Factor measures how many people would need to suddenly become unavailable before a project could no longer continue because critical knowledge disappeared with them. If the answer is one, you don’t have a team – you have a single point of failure.

In software, UX, and product development, the Bus Factor exposes how much knowledge, context, and responsibility are concentrated in particular individuals. It’s a measurement of risk; the lower the number, the more fragile the team.

ORIGIN

The Bus Factor comes from a deliberately grim thought experiment: How many people could be hit by a bus before the project was in serious trouble?

An early example of the idea appeared in the Python community. In 1994, Michael McLay raised the question of what would happen to Python if its creator, Guido van Rossum, were suddenly “hit by a bus.”

The hypothetical bus isn’t particularly important. Nobody needs to be run over. Someone can change jobs, take parental leave, become ill, miss a flight, win the lottery, or simply go on vacation somewhere with enthusiastically poor Wi-Fi.

WHEN

You’ve encountered a low Bus Factor when:

• “Only they know how this works.”
  A remarkably concise description of organizational risk.

• Work stops when someone is away
  The project is apparently compatible with business hours but not vacations.

• One person attends every important meeting
  Not because they enjoy meetings. Because nobody else has the context.

• Documentation exists mostly in people’s heads
  Fast, flexible, and unfortunately difficult to search after they leave.

• The same expert becomes the bottleneck for everything
  Every question, review, approval, and decision eventually finds its way to them.

• Onboarding requires oral history
  Understanding the product involves several hours with someone saying, “Okay, there’s a reason we did this…”

WHY

A low Bus Factor develops when knowledge and responsibility become concentrated instead of distributed or include any combination of the following:

• Knowledge gets trapped
  Important context lives in someone’s memory rather than somewhere the team can access it.

• Doing is faster than teaching
  Under deadline pressure, “I’ll just do it” is considerably quicker than explaining it. Repeat for three years.

• Ownership becomes dependency
  Clear ownership is useful. Exclusive understanding is not.

• Decisions lose their history
  Teams document what was built but forget why it was built that way. The only person that knew left.

• Systems accumulate complexity
  As products grow, undocumented exceptions, dependencies, and historical decisions turn expertise into archaeology.

HOW

The Bus Factor can be reduced by making knowledge shared, visible, and replaceable. In UX and in product teams, this means moving from individual ownership to collective understanding. To prevent this, organize teams and processes by applying the following advice:

• Document decisions, not just deliverables
  Capture why something exists, which alternatives were considered, and what constraints shaped the decision.

• Work in the open
  Make designs, research, technical context, decisions, and work-in-progress accessible instead of keeping them in personal files and private conversations.

• Cross-train intentionally
  Make sure at least one other person understands every critical area well enough to step in.

• Rotate ownership occasionally
  Let different people work with important systems rather than permanently assigning one expert to each kingdom.

• Share research context
  Insights shouldn’t disappear because the researcher who conducted the study changed teams.

• Make systems understandable
  Clear naming, consistent patterns, sensible organization, and good documentation reduce the amount of tribal knowledge required to work safely.

PRO TIP

Strong teams don’t rely on heroes. They rely on shared context. Vacations can be surprisingly useful resilience tests. If everything collapses while someone is away for two weeks, you’ve discovered a dependency without even requiring the actual bus.

EXAMPLES

• Only one designer understands the complete logic behind a critical workflow.
• A feature can’t ship because the only engineer familiar with it is unavailable.
• A design system is extensively documented, but only one person understands when and why to use its patterns.
• Years of research exist, but the historical context lives primarily in one researcher’s memory.
• A PM is the only person who remembers why major product decisions were made.
• A new team member discovers that onboarding consists mostly of finding the right people to ask.

CONCLUSION

The Bus Factor reveals hidden fragility in systems or processes. Dependencies on certain individuals should be minimized to avoid failure when people leave and their knowledge leaves with them.

A strong product must not be defined by how well one person understands it but rather by how easily others can step in. Distribute context, document decisions, cross-train people, and create systems that others can understand without summoning the original creator. In other words, get everyone on the bus instead of being hit by it.