CODING TEAM THEORY: A High Bus Factor
=>Having a low bus factor is risky.
“Bus factor” is a thought experiment that asks what the consequence would be if an individual team member were hit by a bus.
Bus factor (noun): The number of team members that need to get hit by a bus before your project is doomed to fail.
Having a low bus factor is risky.
A High Bus Factor means that there is a greater distribution of knowledge and know-how about the code across the team.
When more than one engineer knows about each area of the team’s code, there’s more optionality for managers to assign tasks and more people that can provide substantial reviews, reducing the possibility of bottlenecks to a release.
For example, if three engineers know how to work in the billing system, a manager can assign a task in that domain to any of those three engineers.
Contrarily, if there are knowledge silos, or if only one engineer has experience working in the billing system, the manager will have difficulty assigning those tasks to any other engineer.
WHAT TO DO
Knowledge distribution can be achieved when team members are making small and frequent commits, and there’s a healthy level of collaboration and debate in reviews from everyone on the team.
It can be helpful to keep this in mind when providing feedback in 1:1s and when onboarding new hires to the team.