Eight to Late

Sensemaking and Analytics for Organizations

Increasing your team’s bus factor

with 5 comments

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.

Written by K

September 3, 2008 at 9:16 pm

5 Responses

Subscribe to comments with RSS.

  1. Great post! And such a good point about documentation. It’s always too easy to say you’ll write it later and then never get back to it. In one of our last project launches while one person was working on file migration and the rest of us were waiting to test or fix things, I told the programmers to just sit there and write everything they need about everything they did for those 2 hrs. Ideally they would have been documenting all along, but I guess its better than nothing!


    Dina Garfinkel

    September 4, 2008 at 1:56 pm

  2. Dina,

    Thanks for your comments. I like your idea of using unscheduled idle time to work on documentation. I’m sure I’ll have opportunities to put it to work in future projects.





    September 4, 2008 at 10:01 pm

  3. Belive it or not my friend got hit by a bus.

    He says it was just as he was going to hand over a document with all his proceses and knowledge for all his specialist tasks.

    I guess they found the docs, because he didn’t work for quite a while.

    Apparently a bus packs quite a punch.


    craig brown

    September 5, 2008 at 10:46 pm

  4. Craig,

    That’s as apposite an example as I’ve ever heard! I do hope your friend has recovered well.

    It is a good reminder to us all that unfortunate things do happen, and the best way to handle them is to be prepared for such eventualities.





    September 6, 2008 at 3:32 pm

  5. […] Ensure key roles have a backup: I’ve discussed this at length in an earlier post. […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: