Chapter 3. Dealing with bus factors
- Bus factors and why they inhibit leadership
- How to remove bus factors
- How to avoid bus factors
Before I explore survival mode later in this book, I want to discuss one of the primary reasons for finding yourself in this mode. Bus factors are ubiquitous, and they’re a huge risk to your projects.
Bus factors
A bus factor can be defined this way: the number of people who need to get hit by a bus for the project or team to stop functioning. Therefore, a bus factor of one is the riskiest.
If you’ve worked in the software industry for any length of time, ask yourself, “Do I know a person in my project who, if they disappeared tomorrow, would leave the project or team stuck?” It’s unlikely you can provide multiple names.
These people (roles) are examples of bus factors. I had a friend who joked that “every successful software company is hiding a “Yuri” (referring to a Russian who is likely a genius) in the basement who does all the important stuff.” Joking aside, “Yuri” represents someone who knows things most people do not, and the company hangs on their word to accomplish a specific task. Many companies have multiple “Yuris.” They’re a huge risk (no matter where they were born, or what accent they have or don’t have).
Let’s break down some of the reasons they’re a risk:
- They’re a single point of failure.
- They create a bottleneck that slows things to a crawl.
- They can reduce morale and induce job insecurity.
- They discourage team growth.
A single point of failure
I once consulted at a large insurance provider. One of the projects, with about 200 developers, had only one build consultant, an outside consultant who had been working with them for several years. His job was to take care of the build and release. A release took a week. There was one release every month.
Everyone stayed out of each other’s way, and he minded his own business as well, keeping his head down in his lane.
One day he got tired of working at the same place on the same project and transferred to a different consulting gig at another place. The project (the company’s main source of revenue) was unable to release any software at all. No bug fixes to production, no new features seeing the light of day. Nothing. This meant a huge monetary loss, as the well as possible loss of new customers.
Everyone was running around like headless chickens, trying to fix this. Eventually they called the build consultant and paid him three times his usual hourly rate to sit there for a couple of weeks, while they attached a mic and screen-recording software to his machine. He did two consecutive releases (a fake one and a real one). They were lucky he was still available, but they paid a lot of money to mitigate that risk.
Lesson: The fewer people you have who know an important part of your business, the more you will pay when they move on.
A bottleneck that slows things to a crawl
One of the large projects I consulted for had a huge problem with code quality and slow release cycles. Nobody knew why the quality was so low. All they knew was that they wanted to fix it, so I paired with the developers for a few days, and things became clear.
One developer was working on a long function that was unreadable and unmaintainable. He was adding spaghetti code to spaghetti code.
When I asked him why he wouldn’t refactor his new code a little bit or extract to an external method, his reply was, “That’d be crazy. If I do that, I’m going to have to ask for a new code review for that code section, and those things take days until they’re done by an architect.”
Interesting. I went to see the architects. Turns out there were only two architects who were allowed to do code reviews, and they were usually busy writing new code, as their boss directed. They had little time to review code changes and approve them. Even getting code into a regular development source control branch could take days, which slowed the place down to a crawl.
A bottleneck like that makes it hard to keep up with fixes, add changes quickly, or even show demos and get feedback fast enough in a sprint cycle.
Note
In the language of the theory of constraints, a bus factor is a type of constraint, and everything will move as slowly as the slowest constraint.
Reducing morale and inducing job insecurity
There are negative consequences for the person who is the bus factor. Time for another true story!
I once consulted at a large software/hardware firm. The build process was managed by three people, and they were extremely defensive about teaching people how to use the build process. One of them was adamantly against showing other people how the build worked, because he felt it was his job. He was the specialist with 20 years of training on the job.
It can be said that being the only expert is a good way to have job security, but it’s a double-edged sword. An organization will (eventually) seek to reduce the bus factor risk, whether they know what to call it or not. Sometimes it takes longer to get the wheels rolling on that endeavor. A person who’s a bus factor and avoids reducing the factor will usually have to take a forceful stand against the organization, effectively holding the project or team hostage, because no one else can fill their role.
The organization is likely to try to find the first “match” to come along to replace or augment that person’s job to reduce the bus factor. The more forceful they were originally, the less chance they have of staying on if someone with the same, or better, skill set who is also a team player comes along.
In short, if you’re enjoying a monopoly, you can’t wait to jump ship the moment a merely adequate competitor comes along.
Discouraging team growth
I’ve seen many people quit their jobs because they weren’t learning anything new. They got bored doing the same work and not being challenged, and they moved on to more challenging pastures.
Bus factors are knowledge silos by definition, and knowledge silos that aren’t broken can lead to the “not my job” mentality (Google “Not my Job Award” to view other examples).
In that atmosphere, even people who want to learn and be challenged will have a hard time finding new challenges because they’re expected to stay in their own little cube (like that company with the build consultant). That, in turn, makes for a team of specialists, or, to put it more bluntly, a team of bus factors.
I have a true story that demonstrates this problem.
One of the places I consulted for had an issue: the search server was failing, and because it was set up by an external company, nobody on the team knew how to fix it. The people from the external consultancy were on a company vacation or something of that sort, and they would have taken at lease three days to fix the problem.
Here’s how it was fixed. A developer called the expert on the phone (during their vacation), and the expert told the developer exactly what to type into the terminal.
The developer blindly typed the commands into the terminal, waited, then said, “Okay, it seems to work now,” and hung up. I was there, listening, and was sad to see this.
What a huge wasted opportunity to learn something that might help solve this problem next time. Not even “Why did that command fix it?” or “Why did it fail? What can we do next time on our own to prevent this?”
This is what that mentality begets: lots of lost time, and people putting cubicles inside their minds, discouraging learning.
Removing bus factors
I’ve used several ways to remove existing bus factors in the past. Some of them are gradual but more effective in the long run. Others are faster but a bit less effective in the long run.
Pairing and coaching
Ask the bus factor to pair up for at least 30 minutes a day with one other person in the team. During that time, let the less-experienced person do most of the hands-on work, while the bus factor sits next to them, coaching and explaining what to do next.
Do this until the less-experienced person knows how to accomplish one task without the bus factor’s help, and then either move them both to a new task, or have the newly experienced person pair with some less-experienced member of the team to achieve the same goals, only this time as the coach.
The best way to learn is to teach, and by teaching, the new person grows and learns the new task in a much deeper way than by being coached by the expert.
Bus factor as teacher
Put the bus factor in charge of a project that requires multiple people to accomplish tasks relating to the bus factor’s area of knowledge. Then make sure part of that project is the bus factor teaching others how to accomplish this.
You can ask the bus factor not to work hands-on in their area of knowledge for one or two days a week, allowing others to take over. This might feel scary, but it’s a great way to get the team up and running fast.
Try assigning a full-time apprentice to that expert, and make sure they pair as much as possible.
Avoid creating bus factors
You can’t always prevent bus factors from sprouting, but you can minimize the likelihood of that happening in the following ways.
Pairing
The more pairing your team does, the less likely that only one person knows how something works.
1-1 code reviews
It’s almost as good as pairing: each code check-in gets personally reviewed locally or via remote call (for example, Skype) with at least audio. This provides learning because it involves a conversation.
Rotation (support, scrum master, build)
Set a daily, weekly, or biweekly rotation on tasks that are bus factors, or with new tasks to prevent them from becoming bus factors.
Pushing people out of their comfort zone instead of asking the veterans to do it
If a new task comes up, select the person on your team with the least skills to accomplish it (assuming it’s not high-risk). If it is high-risk, save that thought for a low-risk task (don’t tell me everything is high risk!).
Next up
In the next chapter, I’ll discuss survival mode, which, if you don’t take care of your bus factors, you can easily fall into.
Summary
- Bus factors are among the most prominent problems that can lead an organization or team into survival mode. In the theory of constraints model, a bus factor is a constraint, a bottleneck that forces a slowdown, because it can only handle a certain amount of work at a time.
- Bus factors can cause many problems including demoralization, discouraging team growth, and becoming a single point of failure that halts productivity.
- You can mitigate bus factors by having them share as much knowledge as possible through pairing, teaching, coaching, or any means that shares what’s in their heads with other people’s heads.
- Detecting, avoiding, and dismantling bus factors are huge parts of being a leader who grows their team.