The Bus Factor

How many of your Engineers could you risk being run over by a bus?

The Bus Factor is the number of people in a team who would need to be hit by a bus in order to cause serious consequences to your Software Platform or Project. The higher the Bus Factor the better.

A one-man-band would have a Bus Factor of 1, a single point of failure. Gareth Southgate's England team during the recent Euro 2020 Championships had relatively high Bus Factor - he had a balanced squad, resilience across the team, and no 'Rockstars' who were absolutely depended upon, if someone was injured or taken out by Covid constraints there was minimal impact.

“Working in a low Bus Factor environment is miserable and stressful…”

A People First Engineering department would have a high Bus Factor, with resilience built in to minimise worry and anxiety. Working in a low Bus Factor environment is miserable and stressful.

Software Engineering departments can increase their Bus Factor in the following ways:

1. Avoiding knowledge silos - ensure multiple people are contributing to a project with collective ownership and peer reviews. Ensure that communications and knowledge shares happen - do follow-ups to verify that information is effectively distributed.
2. Standardisation of programming principles - Follow industry standards so that even a new contractor would be able to get up to speed quickly.
3. Keep your technology and protocols up to date, avoid legacy tech that no one wants to work on. Upgrades and modernisation should be planned in and part of the culture.
4. Ensure good documentation - preferably within the codebase itself. Well-structured code doesn't need heavy documentation, the code makes sense because it has high readability, but complexity creeps in over time and you risk ending up with just one person who knows all the quirks.
5. Automate your processes - Reduce TOIL and the risks of relying on key people to perform processes through automation.
6. Ensure your people feel appreciated and appropriately rewarded to avoid attrition and thus to maintain redundancy in the ecosystem - and it's not just remuneration, people need to feel supported in other areas, they need to feel they are learning, growing, doing worthwhile work, and have a future with you.
7. Create a convivial knowledge-sharing culture with high psychological safety where single points of failure and knowledge silos can be called out without risk, supported with strong communications.
8. Invest towards having a high Bus Factor by allowing time and resources for the above - Software Engineers can't achieve a high Bus Factor under continually high pressure to deliver features. Make it OK for people to ask for time or training to reduce the Bus Factor.
9. Watch out for people who deliberately hold onto knowledge, politically motivated to make themselves indispensable. Or even ‘command and control’ management styles where critical information resides in a manager’s head. Create mechanisms for people to be able to safely call out these behaviours.
10. Create and maintain a domain knowledge matrix, looking at a Software ecosystem from functional and component perspectives and providing the means for people to be graded on their knowledge and expertise to make concentrated domain knowledge visible to all.
11. Minimise unnecessary complexity in architectural design, code implementation, and your Software Development LifeCycle (SDLC) processes.
12. Encourage team transparency. A team may be so focused or specialised that they struggle to share what’s going on. Encourage regular updates and invite questions from outsiders.
13. Promote a People First attitude towards monitoring and improving your Bus Factor. A People First culture strives to increase Engineer joy by considering how they are impacted by the Engineering ecosystem.

“A low Bus Factor leads to apathy and burn-out.”

You know you have a low Bus Factor when you keep having to ask the same people to do overtime, or the same people keep getting inundated with 'how do I do this?' questions. A low Bus Factor leads to apathy and burn-out.

In reality, it’s highly unlikely that a bunch of your Engineers will be run over by a bus, but key people do need holidays, and it’s much more likely that they will leave for a different environment that better considers their needs.

Of course, we live in the real world and some projects at certain points in time may have an inherently low Bus Factor. Pragmatism over fanaticism is advised. Realise that there will be variability in your Bus Factor while you strive for an improving trend.

People First leaders should be curious about the Bus Factor in their Engineering departments and consciously invested in creating the conditions for the Bus Factor to increase.

Connect with People First Engineering at:
LinkedIn
Substack
Instagram