Picture this:
You're part of a fast-paced startup. Among the team, there's this one person — let's call her Aparna. Aparna is the go-to person for a lot of things, and she's been there from the start. She knows the ins and outs of the business, she knows the codebase, she knows the clients... basically, Aparna is your go-to person if you wish to get anything big done in the org.
But what happens if Aparna, quite literally, gets hit by a bus?
(Morbid, I know, but bear with me here.)
This is where you need to be wary of your Bus Factor.
The Bus Factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase “In case they get hit by a bus.” It's a rather grim term, but it's an important concept. The higher your Bus Factor, the less dependent you are on any one individual.
Here's how Wikipedia describes it:
“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.
The expression “hit by a bus” describes a person either dying or more generally disappearing suddenly from the project. It is used to describe hypothetical future disappearances in a darkly humorous way. Team members do not literally have to get “hit by a bus” for the “bus factor” to apply—any number of events could occur in which a team member could be suddenly and substantially prevented from working on the project. This could include a person taking a new job, going on parental leave, or changing lifestyle or life status.
For instance, say a team of 30 people produces bread in three necessary steps: mixing ingredients, kneading the dough, and baking. Ten people know how to mix ingredients, all 30 people know how to knead the dough, and 5 people know how to bake. If all 5 people who know how to bake disappear, then the team cannot produce bread, so the team's bus factor is 5.
There is a rare alternative definition for the bus factor, namely: the number of people who are indispensable for the project. In other words, it is the minimum number of people who are a single point of failure. If using this definition, then a high bus factor is considered a bad thing (since the loss of any person included destroys the project), and zero is considered the ideal bus factor.”
Speaking of single points of failure, I can't help but mention the Theory of Constraints.
The Theory of Constraints, formulated by Eliyahu Goldratt in his 1984 book The Goal, is a management paradigm that views any manageable system as being rate-limited by a very small number of constraints. There is always at least one constraint, and Goldratt proposes that it is the role of management to identify and either relax it, or if possible, eliminate it.
Now, if we think of a startup as a system, it's not hard to see how the Bus Factor and the Theory of Constraints are fundamentally related.
Aparna, our indispensable team member, can be seen as a constraint. The entire functioning of our startup is dependent on her. If anything were to happen to Aparna, the startup would come to a grinding halt. Aparna is our bottleneck. And her capacity to work determines the throughput of the entire system.
Now, as a founder, the worst thing you could do here is to blindly throw money at the problem.
You could make the mistake of hiring more developers, without understanding that it is Aparna who is the final constraint or rate-limiter on the work. And then even despite hiring additional resources, you wouldn't be addressing the constraint. And without fixing this constraint, there would be no change in your throughput.
What you need to do though, is increase your team's Bus Factor. You need to ensure that knowledge of the backend architecture is spread among more of the team members. This could involve comprehensive documentation, cross-training, code reviews, or a combination of these and more.
In short, you have to push Aparna to create more Aparnas within the team.
By doing this, you would be addressing the constraint (the dependence on Aparna), and as a result, would be able to improve your throughput and eliminate a single point of failure in the system. The goal here is to ensure that knowledge and skills are spread across the team, reducing the risk of a project stalling if a key member leaves.
It's a simple concept, but understanding it can sometimes be the difference between success and failure at a fledgling startup.
So, the next time you're kneading the dough, remember to keep an eye on who's baking the bread.
