When it comes time to ensure that there is redundancy in your organization, how do you refer to that necessary redundancy? I recently came across an example that quite honestly, made my skin crawl…
Having “name” as single point of failure should be addressed.
See the key word in there? Failure. To make matters even stickier, the person this sentence was referring to was on the email. How would you feel being referenced in an email by your boss as a point of failure? This is demoralizing. I don’t care how much I know that I may be the only person in the company who can do a certain job, but I’d rather not be referred to as a point of failure. Personally, I’ll tell you that I’m not a failure, I’m a specialized expert who needs a back up.
So what do you call that singularity of expertise that needs a back up?
I had a manager once who referred to it as the Bus Factor. Yes, Bus Factor, as in, how many employees need to unexpectedly be hit by a bus before this function can no longer be performed? A bit morbid perhaps? Well, a little… But think about it. Nobody knows if they’re going to get hit by a bus. Nobody wakes up in the morning planning on stepping in to the street right in the path of a moving bus. Some people like to call this the Lottery Factor, but winning the lottery (or leaving because you found another job, which can sometimes feel like winning the lottery ) takes effort and planning. Getting hit by a bus is unexpected. The upside is that it’s not even terminal. You could just be laid up in the hospital for several weeks recovering. That’s still long enough that you would need a back up for your tasks.
Bus Factor 1
This is where there is no back up. Only one person needs to be “hit by a bus” to cause problems in the company. This is the “single point of failure” mentioned in the snippet of email by the one manager up above. As a manager, you don’t want to have this scenario longer than is required to identify and train a back up. That training may just be having documentation and a process in place to grant the appropriate access to anyone else on the team if the need arises. Still, avoid Bus Factors of 1.
Bus Factor 2
Great, you’ve got a back up in place. Two people are capable of performing the specific task. Is this enough? Well, now it’s up to you to decide. But you have a plan in place and someone who is capable of performing the the task in case the primary person is hit by a bus. So you’re at least in a stable place.
Bus Factor 3 (or greater)
Obviously the more people who can perform a given task or have the knowledge to do it, the better. At this point you have solid documentation over tasks and roles, and with a little training you could start swapping people between teams with minimal risk.
Bus Factor 0
Oh dear. You’ve identified a need in your organization. Maybe it’s because the single individual who performed the task has actually won the lottery and just turned in their notice. Maybe you’ve identified a hole in your processes where it turns out there never was anyone who did something and the team has stated that someone needs to be accountable. Regardless, if you ever find yourself in a Bus Factor of 0, do yourself and your team a favor and plan for a Bus Factor of 2. You never know when someone is going to get hit by the Lottery Bus…
I know, Bus Factor sounds a little cheesy and a little morbid, but it’s still better than “single point of failure.” Having a Bus Factor (or even a Lottery Factor) makes the personnel back up issue sound like a process statistic. It’s something that you can fix, and your singularity of expertise is still great at their job. There’s nothing demoralizing about a process statistic. Calling someone a point of failure implies that they just don’t do their job correctly, not that they are the only person who knows how to do their job.
Oh, you thought I’d just leave it at that? Sorry. You know I had to look up the origins of the term “Hit by a bus” while I was at it. To find the origin we have to go back quite a bit, to the 1907 novel The Secret Agent, by Joseph Conrad.
But just try to understand that it was a pure accident; as much an accident as if he had been run over by a bus while crossing the street.
But don’t take my word. Feel free to read it for yourself…
Either term/phrase is an approach from the negative. Although aspirational, I prefer to cast this as a need to broaden skill sets through culture change… T-shaping.
The goal itself provokes agile mindset and practices to emerge.
I’ll agree that both have negative connotations, although swapping out “getting hit by a bus” with “winning the lottery” is at least a little more positive for the person involved. Regardless of terms though, it does highlight the need for solid agile practices, particularly around documentation and other such artifacts to ensure continuity.
T-Shaping is a new term to me, thank you for bringing it to light. I’ll be researching it and may write on it at a later date.