The bus factor

When building any product or business, you want to make it as resilient as possible. You should do that from the very beginning, but sometimes this is hard, or we don’t have the time or resources to do it. As a result, we lock the key skills and competences within one person’s head. That person is most likely the founder or some key early employee, who took ownership of a specific area that no one else wants to touch with a 2-meter pole. In my case, it has always been infrastructure, or keeping the lights on. While this is a very interesting area for me to geek out on, it is boring or not as interesting for anyone else. So, specific knowledge within the company resides inside one head. That’s a Bus factor of 1. In a nutshell, if that one person gets hit by a bus, your business takes a huge hit. People don’t have to die for this to happen, they could disappear from the project for whatever reason. Could find another job, or, well, get hit by a bus. In my experience, keeping this knowledge spread out is hard in small companies I usually work for. So the bus factor is almost always equal to 1 (sometimes 2 if there is a technical founder on board). What this means is that when one crucial person disappears from the project, you will lose years of knowledge, and intricacies of how the system is set up and how it actually works.

In small companies, everyone has a more or less dedicated role they do, but everyone is pretty aware of what is happening with other parts of the company. It’s easy to have an all hands call once per week or every other week with 10–20 people on the call. And teams are much smaller than that, so the daily check-ins serve to spread the knowledge of what the team is working on. Yet, as the company grows (and they usually do), the communication paths grow, teams multiply. Then you have 50% of the people unaware of even the existence of a complex system responsible for 30% of the revenue. They usually find out about that when someone decides to change something attached to it. According to Murphy’s Law, this happens when the complexity’s “owner” is on a 3-week vacation to a place with shady internet and 12 timezones away.

Mitigating the bus factor

There are a couple of ways to avoid the above situation. One is mandatory, and that one is test coverage and documentation. While you can skip documenting every thing under the sun and only document why and how you did the complex things in the app, you should never skip tests. I’m not preaching for full-blown TDD approach here, but having the “happy path” test coverage of a certain feature is mandatory in my book. It’s easier to write some things if you have tests upfront, sometimes it’s easier to write the tests after the fact. If you arrived this far, I guess you have enough of a brain to decide which approach to use. When documenting, also try to automate as many things as possible. A person running 7 different scripts to set up a testing/production environment can make 27 different mistakes running them. If you condense everything into one script, they won’t make the mistake (or not as many at least). Also, when you document something, you have a process. If you automate this processes, the people can use their brains for creative things and not to keep order of which script comes next.

The second thing is very smart to do, but hardly doable in small companies. Having many people covering the same responsibilities is great. But if you can’t achieve that because you lack people, then rotating people’s roles around the project would also work. Let’s say you have 3 engineers on the team, each specialized in their “favorite” job. DevOps, backend or frontend. Now all these 3 people can and will do all 3 roles if necessary, they like one of them more than the others. What if next time there is a “big” task in one of those, you pair two people with different preferences to do the task. Let the less experienced person “drive” and the more experienced one “navigate”. This way both of those people will grow by teaching or learning. The knowledge will get shared between the team, and you are increasing the bus factor to the number of employees within the company.

Whatever you decide to do, please don’t do nothing about this. It doesn’t matter whether you are a small company or a big enterprise, the bus factor is relevant in all cases. This is especially important for company owners. If you document all processes, and not rely on specific people to execute them, it will increase the company value. It will also make the company more stable and resilient.