The “Bus Test” Considered Harmful

Perhaps it has happened to you. You have a great idea, one that will fix a difficult problem at work. It is creative and outside the box — exactly the type of innovative idea that they have been begging for in engineering meetings for the last six months. You are excited enough to craft an email and send it out to the team. Everyone responds with great excitement, and it looks like it is going to go forward. But then one person, frequently your manager or the team lead, responds with that dreaded complaint: “Sounds good, but it doesn’t pass the bus test”. And that stops the momentum. Your idea slowly dies over the next few weeks as you argue as hard as you can but finally give up. Your idea was water tight and demonstrably able to solve the problem at hand, but since it failed the bus test nothing else mattered. What was so important about the bus test? Why did it trump all other reasons? Why is it preventing so many good ideas from being implemented?

A good description of the bus test can be found in the Urban Dictionary:

A thought experiment which explores the impact of losing a person: If a particularly empowered individual in an organization is hit by a bus, will the organization suffer greatly? If yes, fail. If no, pass.

http://www.urbandictionary.com/define.php?term=bus%20test

I believe the initial intention of this thought experiment actually addressed a very valid concern. If someone were to suddenly leave an organization or were temporarily unavailable could a running system still be serviced or administered? Are access keys, permissions, and tokens available to others in the organization, or will the running system suddenly become impenetrable? Clearly this would be a big problem, and any software organization would do well to not put themselves in that situation. Unfortunately, however, the bus test has gone far beyond this initial purpose.

The bus test has since become a mechanism for furthering the paradigm of a corporation as a machine, where each individual is a cog in that machine and can be replaced with little cost or effort. Basically, if one day you disappear, Jimmy from the 3rd floor will come down and do your job, no problem.

This paradigm is particularly ill suited for the software engineering world. In the end, the bus test only really serves to cripple anyone that is making what could be considered a unique contribution — under the banner of not having to suffer too much inconvenience in the event that he leaves the company.

The truth is actually the opposite of what the bus test implies. If you lose an employee and you don’t hurt for at least a few weeks while the organization realigns itself to manage the loss, then that employee was likely not worth having around in the first place. It should hurt to lose them. The better they are, the more it should hurt.

Most importantly, every engineer yearns to make new, innovative, unique contributions to his company. And it is precisely these unique contributions that will yield more advantageous market positions in the future. When engineers are solving problems in ways that no one else at your company can, it is likely that no one at your competitor’s company can either. Cogs in a machine will not give you that advantage, only motivated individuals. So stop asking if ideas pass the bus test and start valuing and rewarding people who make themselves indispensable.