.the bus factor

You are a small company and your CTO who designed all product road map gets hit by a bus. Now what?

There is this thought experiment around risk called the bus factor (or a bus number). A high bus factor means that there are many individuals who know enough to successfully complete a project if an adverse event (an imaginary bus hitting and killing that person) were to occur; such as a colleague resigning, falling ill, or as the name suggests – being hit by the bus.

Why Antoni Gaudí’s Sagrada Família still isn’t finished

There are not many people who haven’t seen or heard of the Spanish architect Gaudí and his famous creations; Sagrada Familia, Park Güell or Casa Milà. While Gaudí was not the Sagrada Família’s original architect, when plans for the basilica were first laid out, Gaudí was in his early twenties and just starting out his career. Over the years, Sagrada became his main baby, a project he devoted majority of his time, but was unable to complete it within his lifetime. At 73 years old, in 1926, he was struck by a tram. Back then, Spain was going through turbulent times with military coups and anarchist labor unions. Churches and other religious buildings were among the most popular targets in the celebratory violence that followed, and the Sagrada Família became one of the targets.
On July 20th, members of the Federación Anarquista Ibérica (FAI) torched the temple’s provisional school and destroyed Gaudí’s former studio and its countless drawings, photographs, plans and other papers. They also smashed the construction site’s model and sculpture studios, and set fire to the crypt.

Why does the bus factor matter?

A low bus factor is detrimental to project’s success and can cause operations to cease in the blink of an eye. Admittedly, Sagrada did not have a bus factor of one, but as we see now years later, with the building still unfinished, its intellectual property and know-how have not been protected and distributed well enough.

Adopting a low bus factor is incredibly risky for businesses that provide software services or have business models centered around their development teams. It’s also make it or break it for startup’s success. If a small company has a bus factor of one and that developer leaves as the company grows, the team may have to start over entirely. Or worse yet, they might not be able to fill the gap that a key person left behind and have to pivot or kill the project altogether.

We all know terror corporate stories of backbone architecture written in 80s-90s in a language that nobody uses anymore, so nobody dares to change anything in it. Instead, people just apply patches praying that nothing will crash in the middle of the night.

You never want to be dependant on selected few just like you never want to put the eggs in one basket when investing. So how to ensure better contingency plan?

Document everything.

What’s the best way to structure and store your tribal knowledge and know-how? Writing it down. While documentation might feel daunting, especially when drafting it for the first time, it’s a significant benefit for retaining valuable information and transferring it to new team members. Creating and disseminating knowledge enhance human development and helps ensure the free flow of ideas.

“None of us is as smart as all of us.”

Ken Blanchard

A well-documented key processes serve to reduce duplicative efforts, improve quality and process control, speed up onboarding, and provide a single source of truth…at least in theory.
Establishing a method for creating documentation and pointing people responsible for keeping everything up to date is an incredibly complex and challenging task. As much as companies try to enforce well structured documentation, in reality, people don’t live or work that way. Humans are messy. Creativity and innovation are born in chaos, by trying and mixing different concepts, until something moulds. We often struggle to structure our thoughts, organise our findings and data, even when we work alone. When you add layers of hierarchy to teams, and teams working with different departments, all producing tons of data and information – you end up with a decision paralysis at best. 
Current systems and technology designed require people to fit into them, not the other way round. You need to work with what you’ve got, but me and my team at Untrite believe there should be a better way of accessing knowledge.
Our grand vision is to use newest tech – AI – to provide a one place for holistic knowledge within a company – think your best colleague who always knows where a relevant information is or who knows all relevant information to what you’re working on now. He can give you actionable insights, suggest what worked in the past, what hasn’t etc.

Designate backups for each role.

One of the biggest mistakes you can make, even when your team is still small and the communication is fairly tight, is forgoing designating backups for each role on the team. You don’t want to have anyone as a bottleneck preventing project from progressing. Backups and backlogs are necessary for instances where a team member falls ill or suddenly resigns, and a gap exists between the resignation and backfill. A good practice is building backups into your job descriptions tasks and ensure that team members have time to serve as a backup, if needed. 

Cross-train.

In a startup, you usually want to have a lot of generalists, people who can wear many hats and can take up a task outside of their usual role, when needed. As company grows, it needs more specialised, area focused employees. Having specialised rock stars who can tackle common issues can speed up turnaround times when issues with product arise. But, it can also cause knowledge gaps and silos. 

To close these gaps, a good idea is to cross train your teams, encouraging knowledge sharing and group problem-solving. One way to achieve this is through an agile pair programming (yes, you can even do pair programming remotely). It fosters teamwork, supports innovation, and provides a space for teammates to learn from one another. Another way to cross-train employees is by hosting regular knowledge-sharing sessions. Have developers sign up to present various topics to the development team.

Strive for simplicity over complexity.

Simplicity is a powerful strategy for combating a low bus factor. In the early stages of a company, when there is no clear product market fit, teams are testing many scenarios and designs, inadvertently making things complicated. That’s why, as a leader and decision maker, you need to ensure all the processes and designs are constantly simplified. The more specific and niche the product or a code gets, the longer it takes for a new team member to catch up and become comfortable with it.

Exchange vital information during daily standups

I’m a big advocate for agile style of working with daily standups, where people can ask questions and get help from one another in a group setting. Such meetings provide opportunities for the team to connect and exchange mission-critical information. If your team doesn’t conduct daily standups, make sure there are other recurring team meetings and opportunities to connect and share project information in a seamless and meaningful way. Asynchronous communication methods with an easy access, like project-specific Slack channels or repos like GitHub, can also be a great source of information sharing. 

Make everyone – especially yourself – replaceable

Your mission as a founder should be to make yourself replaceable – company progress should not depend on you being present. Even if you identify yourself through a startup you’re building and call it your baby, babies at some point grow up and become independent. Or at least, for everyone’s well-being, you should ensure a smooth transition. No parent wants to end up with a 40+ year old “kid” living under their roof. Hard to part ways, but even harder to live together.
This is a whole separate topic on delegation, micromanagement and knowledge sharing, that I hope one day to cover in more detail.

Same goes for the any person that you’re building this company with. People’s priorities and goals change. Even today your team members are completely vested in the project, it may change in the future. Make sure you plan for it.

Even if the term bus factor is rooted in the software world, this can be widely used for business management. The key to the success of any business is to share knowledge in an easy, accessible way, so that new person can back-up if somebody else is failing.