“Quit factor”, or How the industry lulls itself to sleep with “bus factor”

Back in the day there was a company in the business of recycling printer cartridges. Their market was thriving and you could find their ads everywhere: in magazines, newspapers and on the public transport, especially in buses. There was a cute dead bird in their logo, like a sparrow. Some time later I read an interview with the company’s CEO. He explained that they wanted to visually express this idea of a “dead printer cartridge”. They did research and found out that a small dead bird is basically the only visual that represents the idea of death but almost lacks negative connotations and so could safely be used in advertising.

> The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase “in case they get hit by a bus”. (Source: Wikipedia)

Weird choice of a vehicle to get hit by, isn’t it? Buses are slow, they drive in their own lane, they drive much more safely. Basically, buses are the least dangerous traffic participant by a large margin, next to drum rollers. Quick googling shows that the yearly number of people getting hit by a bus is at least two orders of magnitude less than people getting hit by a car.

It’s almost as if we, as an industry, collectively decided to agree on the cutest symbolic representation for a certain project risk. Maybe to avoid thinking about it too much?

You can go on and say that road accidents are just one of the causes of death or injury, and not the biggest, but we don’t really want to get all gruesome and depressed: that would be just another misdirection. Let’s forget about death for a moment.

Suppose that your project actually has a bus factor of 1. The most important thing that we could probably say about this person’s situation is that they’re stuck. The project depends on them, and they cannot move, they have no breathing space.

Why would people really disappear from your project?

First, they could quit. They could go to a different company with better engineering practices. They could go to a bigger company. They could just go to a different company, to escape that long-term pressure of being a bottleneck.

Second, they could burn out. They would stay on the project, they would come to the office, but they just won’t be there.

(If you’re personally in a burnout situation: prioritize getting professional help. Your assessment of the situation and options available is most probably distorted, and this is not your fault.)

Third, and this I think is an interesting case: being stuck could be a self-inflicted situation. They could actually think that they personally are the linchpin here. This tends to happen to more senior developers: sometimes they don’t trust people around them. They may consider others not competent enough, not careful enough. Initially this may feel great for them: they built something that no one else could, they are important because only they can handle this system, they have job security.

But suddenly they get stuck. As time goes by this gets tiring. In the end, how much fun is left in a system that was built and maintained mostly by a single person, without fresh ideas, after say five years? At some point they really would have liked to move on, to build another project, but they are stuck in this contraption of their own design.

There may also be a big opportunity cost here. One especially disappointing scenario for them could be “there is this new initiative here, you could have been the perfect tech lead for it, but we know that you’re sooo busy with that project of yours”. Oh.

Wake up

None of those scenarios are desirable, and they are not necessary. For example, instead of quitting they could, you know, continue working in your company.

Also, they don’t really need to be burned out.

Also, instead of getting stuck in an important project they could go on and build another project in the same company. In the end, there was a reason why the first one was assigned to them back then. And for someone else to work on that important project could even be a welcome step in their career.

We, as an industry, lull ourselves to sleep with the idea of “bus factor”, with the choice of words. Maybe we could choose something more relevant, something that returns us the agency and responsibility.

“Burnout factor”? “Quit factor”? “Stuck factor”?

I hope that this reframing may help someone to realize that they are stuck in one of the described situations. Next question would be: how to manage ourselves out of this? But that’s a topic for some other time.