The bus factor is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel. It measures how fragile a system is. If the answer is one, you don’t have a team – you have a single point of failure.

In software and product development, this concept measures the risk based on how knowledge and responsibility are distributed. The higher the number, the safer the system.

ORIGIN

The Bus Factor comes from a dark but practical thought experiment: What if key people were suddenly unavailable, such as hit by a bus, missed a flight, quit, fired, or simply didn’t show up?

An early instance of this sort of query was when in 1994 Michael McLay publicly asked, what would happen to the Python language if Guido van Rossum, a Dutch programmer known as the creator of the Python programming language, were to be hit by a bus.

WHEN

You’ve encountered a low Bus Factor when:

• Only one person understands a critical feature or system
• Documentation is missing, outdated, or nonexistent
• A project stalls when someone is out
• You hear: “Only they know how this works”
• Onboarding takes longer than it should

If work pauses when one person disappears, the bus factor is low.

WHY

The Bus Factor emerges from concentration and may include any combination of the following:

• Knowledge gets trapped: Critical information lives in one person’s head.
• Ownership becomes isolation: One person becomes the expert and therefore the bottleneck.
• Speed is prioritized over sharing: It’s faster to do by yourself than to teach to others.
• Systems grow without structure: Context isn’t captured, only remembered.

As a result, the system, team, or product appears stable… until it isn’t.

HOW

The Bus Factor is reduced by making knowledge shared, visible, and replaceable.

In UX and in product teams, this means moving from individual ownership to collective understanding:

• A designer shouldn’t be the only one who understands a complex flow
• A researcher shouldn’t be the only one holding past insights
• A PM shouldn’t be the only one who knows why decisions were made
• A design system shouldn’t live in one person’s head

To prevent this, organize teams and processes by applying the following advice:

• Document decisions, not just deliverables: Explain why something exists, not just what was built.
• Design and work in the open: Make artefacts, creative thinking, and research findings accessible to the team.
• Cross-train intentionally: Ensure more than one person can step into critical areas.
• Rotate ownership: Shared exposure builds resilience over time.
• Lower the cost of understanding: Clear structure, naming, and systems reduce dependency on individuals.

PRO TIP

Strong teams don’t rely on heroes. They rely on shared context.

EXAMPLES

Exemplary indicators of low bus factor include the following:

• A critical flow breaks – but only one designer knows how it works
• A feature can’t ship because the original engineer is unavailable
• A design system exists, but only one person understands how to apply it
• A research repository exists, but insights are hidden or not accessible
• A roadmap stalls because context lives in one person’s head

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. Get everyone on the bus instead of being hit by it.

Also known as: Truck factor • Circus factor • Lottery factor