What is your bus-factor?
Bus-Factor conveys a very important message, however, in a very morbid manner. I admit, there are other ways to emphasize on the same goal, and I have heard a few different explanation of the same topic. But this one stood out, for obvious reasons.
The first time that I heard the term “bus-factor” it was from the CTO of the department that I was working in. He was saying that instead of focusing on increasing the number of rock-stars in your team, you should be focusing on increasing your bus-factor.
He explained that the bus-factor is the number of people that should leave your team simultaneously (as on a single bus1) before the entire project comes into halt or becomes impossible to continue.
If your project comes to a stop by just one person leaving the team, that is a very low bus-factor. But if 75% of the team needs to leave at the same time, before your project comes to complete stop, that’s is a much better situation.
Let’s examine bus-factor in more detail
Why low bus-factor is bad?
One, of course, is the obvious reason why low bus-factor is bad? Let’s say your bus-factor is one, meaning if that person leaves your projects comes to a halt; You would need to delay all your deliveries, until the rest of the team catches up. That is risky. Even thinking about this situation makes me to shiver.
But the CTO went on and explained that this is not his main concern for the low bus fact. His main concern is that, if you have a low bus-factor your team becomes a one-man-opinion team; In political system that is known as dictatorship.
He was saying the damage caused by delaying deliveries because the rest of the team needs to on-board is far less than the long lasting damages caused by having a one-man-opinion team. He mentioned that he had managed a lot of successful software team and products and anytime that one-person was the only voice in the team, no matter how good the were on the technical side of the software of the team, the team eventually came to halt, the team had to be dismantled, and eventually everyone only remembered the bad things and not the product. Essentially the product was tainted and no body wanted to join that team and work on it anymore. Eventually, they had to break up the team and rebrand the project, although this was internally.
The thing is that if your bus-factor is low, that one person could easily threat the project that it is his way or highway. That one person becomes the sole decider of what path will the team take. If an opinion from a team member is contrasting that one person’s opinion it would be crushed. It would fall on deaf ear. People quickly learn that they need to shut up and just do as they are told! If they don’t like it, well, “US is a free country! You are free to leave.”.
With low bus-factor the work environment becomes so hostile, and innovation drops to bare minimum, your team breaks up into factions, those that are with the one or against the one. Ultimately your product will grow to the capability limit of just one person. Yes, that might be still a very good product because that one person is very talented on the technical side of the stuff, but your competitors also have good person on their team. No matter how good you are, one opinion is still one opinion. Collectively, you can always do much better.
When that CTO was mentioning these things, I was in my very early stage of career in industry. I hadn’t yet experienced what he was saying. But he had. He had managed many software teams. He had started from scratch, grow a team, turned into a company, and sold it for millions of dollars. At the time, I did understood what he is saying; and what he was saying made sense. But I hadn’t experienced it myself. There is a difference between knowing about something and knowing something. Like truly experienced it. I have to say, now that I have experienced working in couple of companies, big or small, and I have enough sampling, I truly know what that CTO meant and how correct he was.
How to increase bus-factor?
Listen to a diverse opinion
There are multiple way to increase your bus-factor. I like the Amazon’s Leadership Principal (LP) that talks about “leaders are right a lot!”. At the face value of that sentence, you might think that means leaders are know it all. But when you dig into the explanation you find out that they are “right a lot” not because they know it all, but because they listen to a wide variety of opinion, analyze them, give chance to the team to speak their mind, and once they have heard all the opinions they decide what to do. In fact, leaders are “right a lot” because they rely on the collective knowledge of their team to make decision. If one person misses an edge case, another person may notice it. If both of these persons overlook an issue that could be a problem, a third person might catch it. Leaders who listen to the opinion of all people in their team, have a lower chance of being wrong rather than if you decide solely by the opinion of one person, bus-factor of 1.
Transfer of knowledge
The transfer of knowledge could happen in different way. Passive or Active.
In passive transfer of knowledge, your team are asked to make documentation. The documentation should be self explanatory enough that without any prior knowledge of internal procedure (anything that is specific to that team and can’t be googled or looked up in stack-overflow), if any person joins that team they should be able to accomplish the task.
This is easier said than done. Many teams fall behind their documentation for various reasons, some valid, some, well, they were just too lazy. Hopefully not intentionally.
The biggest mistake that people make regarding the documentation is that they think it is one time deal. Maintaining the documentation is by itself not a simple task. Software is fluent. Procedures are fluent. Things changes. Do you keep your documentation to reflect the latest changes? What was the last time that you came up with a documentation and you followed it, only to find out certain things has changed and isn’t the way that is explained in that document anymore? What did you do? Did you just cursed that nothing is documented? When you figured out what is the correct procedure, did you updated the document to reflect the correct and updated approach?
Another method of knowledge transfer is active method. In the active method, essentially you pair the person who has just joined a team with someone who has been on the team for a longer time. When they work together, the person who has been longer on the team could train the other person about the team’s specific knowledge. It is important to focus on the things that is specific to the team and project. Don’t talk about how they should use data structure to write a better algorithm. You can talk about it if you have time, but those are information that you can google for it or find it on stack-overflow. If you are talking about a data structure, talk about why that structure was chosen? What sort of queries is your software receiving, that lead to choosing these data structure and model? What are your requirements on testing? Do you need specialized hardware? how to access that hardware? Who should they contact to find out they are testing for the latest requirements? Many of these information are not something that you can google for. If you can find them on google, talk to your companies security. Someone is leaking information. I remember that we needed to test our code on a actual hardware. To get to that hardware, either you needed to go to the lab and directly connect to the hardware or connect to a Raspberry Pi board remotely and access the hardware through that Raspberry Pi. When I joined the team, a team member told me how I don’t know how to connect to Raspberry Pi. He was posing it as if I don’t know how to SSH, and my response was that, where the hell was I supposed to know that beside physical access there is a Raspberry Pi to begin with if you don’t tell me?
Wrapping Up
Ask yourself, what is the bus-factor in your team? If you have been on multiple projects and teams, compare their bus-factors. The teams/projects that you enjoyed, what was their bus-factor? What was the bus-factor for the teams and/or projects that you were counting days to leave.
There are multiple ways of increasing the bus-factor. Think about how you can increase bus-factor on your current team.
- Yes; it was implying that morbid image that you have in mind. But I don’t think we need to say it explicitly. You get it. ↩︎