Increasing your team’s bus factor

Wikipedia defines the bus factor as the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed.  Although most discussions about the bus factor revolve around software projects, the considerations apply to any situation where important, specialised knowledge is held by a small number of people. For example, an IT department where there is little or no cross-training or cross-over in roles would have a low bus factor.

Increasing the bus factor amounts to spreading the knowledge around so that there is a degree of redundancy in skills and knowledge within a team. This ensures that work will go on even if a key person has an unfortunate encounter with a public transport vehicle. It is clear that every manager should aim to increase the bus factor for all processes that come under his or her purview. Below I outline a few suggestions on how one might do so.

1. Keep things simple: Keep processes as simple as possible (but no simpler!). This ensures that the processes are easy to maintain and hence easy to teach to others. Simplicity usually boils down to two things: a) using the right tool for the right job, and b)using the most straightforward way to achieve what’s needed. I have seen several processes that are needlessly complicated by inappropriate technologies or use of technologies. To elaborate on the latter, processes are overengineered often for no other reason than to demonstrate the cleverness of the process creator. Avoid creating such Rube Goldberg processes at all costs!
   An important, simplicity related factor (from the bus point of view) is to use technologies that are familiar to more than one person on the team. This builds in a high bus factor from the start.
2. Document, document, document: This is a no-brainer, but people still think they can get away with “doing it first and documenting it later.” Documentation done after the fact is often less than useful because the author forgets to include some (many?) small detail(s) which, of course, turn out to be critical ones in times of trouble. What should a process document contain? Enough to help someone figure out what, how, where, when –  what it does; how it’s run; where it sits (servers etc.); and when and how often it’s run. The documentation should also include some basic troubleshooting information and references to relevant sections of manuals.
   Another important point is to keep the documentation in synch with the process – i.e. to update all relevant documents whenever the process is modified. This is essential because process documentation is your only guide when the owner of a process with bus factor 1 goes under the bus instead of getting on it.
   A small word about style is perhaps in order – process documentation should adhere to the 3Cs of clarity, conciseness and comprehensibility. Yes, it is possible to write in a way that achieves all three, although this isn’t evident in my writing. 
3. Encourage people to pick up secondary skills: The first two points dealt with process and documentation. However, in the end, it is people who make things happen. Despite well-engineered and documented processes, one can still have a low bus factor if the team doesn’t have skill redundancy. Who’ll look after the databases the when the DBA goes under  (or is run over by) a bus? This question wouldn’t have to be asked if someone had been cross-trained in basic DBA tasks. As far as possible, every one on the team should have at least one secondary skill that will enable them to cover for someone else.

All this stuff is obvious. Yet I’ve seen more than a few outfits with very low bus factors (sometimes as low as zero. Yes, really!), so perhaps it isn’t taken as seriously as it should be. I therefore close with this exercise: take stock of the activities and processes that your department or team supports. Do you see any danger zones with low bus factors? If the answer’s affirmative, get moving before a bus comes around.