The bus factor of a team is a colorful illustration of the risk of having unique resources. How many team members could get hit by a bus without crippling the team? Less gruesomely, how many could be out with an illness? Or, more kindly, how many could take vacation time at once? Early in my career, I learned that if you’re irreplaceable, you’re unpromotable. And as long as I’ve managed software development, I’ve been acutely aware of the team’s bus factor. I think I also had an inkling of something that I’ve only recently put into words, perhaps a corollary of the bus factor. I’ve start thinking of these considerations in terms of three rules.
No Singletons
In a software system, a singleton is a unique resource for which you work to make sure there is only a single instance. Having a high bus factor (low risk from having a team member unavailable) means not having a singleton on the team.
Rule 1: Nothing the team does should be done by only a single member of the team.
No Specialists
What I’ve recently realized is that a singleton may also be a specialist. Not only are they the only one who does a certain task, but they may spend so much time doing it that they aren’t involved in any other work of the team. If that task is no longer relevant (technology evolves), what do you do with that person who knows your business and processes but only contributes to one narrow part of it? The answer is that you shouldn’t put people in that awkward position. If you need a specialist, hire a consultant. But if you have someone on your team with a specialty, you owe it to the team and the individual member to cross train them on other things you do.
Rule 2: No one on the team should do only one thing the team is responsible for.
No Exceptions
I’ve mostly managed small teams where I’ve been an active contributor to the code base, even if only part time. In that sense, I’m not a specialist. And when I write code, I am not exempt from our usual process: someone reviews and approves my code before it goes into production. An experienced developer can point out errors in my approach or implementation, but even a relatively new developer can ask insightful questions from a naive perspective. I am diligently humble enough to accept input from reviewers that I lead.
But if I am not a specialist, neither should I be a singleton. I could get hit by a bus. Or get sick (as happened recently). Or take some time off. In my absence, someone else can lead a team meeting or make an informed decision and work goes on. I talk to my team frequently about business requirements and other constraints not only to guide their minute-to-minute development decisions but so that the team doesn’t have a leadership singleton.
Rule 3: The first two rules apply to everything, including team leadership.