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's creative and outside the box, exactly the type of innovative idea they've been begging for in engineering meetings for the last six months. You're excited enough to craft an email and send it out to the team. Everyone responds with great enthusiasm, and it looks like the idea is going to move forward. But then someone kills it by invoking the "bus test":

“I don't think that passes the bus test.”

"What?"

"Well, that solution will be unique in the organization. You'll gain specialized knowledge. No one else will know what you did. What if you get hit by a bus? Then what will we do?"

"Of course it's unique. That's the point! What we do right now doesn't work. We need a novel solution."

"I would rather we try to solve this using our approved methods."

And your idea is left for dead. It was watertight and demonstrably able to solve the problem at hand, but since it failed the bus test, nothing else mattered. What is so important about the bus test? Why does it often trump all other considerations, 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.

To be fair, the original intention of this thought experiment addresses a valid concern. If someone suddenly leaves an organization or is temporarily unavailable, systems still need to be serviced and administered. Access keys, permissions, and tokens should be available to others in the organization so running systems don't suddenly become inoperable. This would inarguably be a big problem. Software organizations should never put themselves in that situation. But the bus test has gone far beyond these initial considerations.

The bus test has now become a mechanism for furthering the paradigm of a corporation as a machine. Each individual is a cog in the 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. The bus test, when used to make people interchangeable, only serves to cripple anyone who makes what could be considered a unique contribution, for fear of suffering too much inconvenience if that person leaves.

The truth is actually the opposite of what the bus test implies. If you lose an employee and you don’t feel the impact 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 their company, and making them feel replaceable will only make them want to leave. Furthermore, you need their unique contributions to gain 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 will.

Let unique ideas be celebrated and proliferated. Let their champions be mentors for others in the organization. Unique competencies should be taught, not shunned in favor of excessive standardization efforts¹.

So PLEASE stop asking if ideas pass the bus test and start valuing and rewarding people who make themselves indispensable.

1. Standardization efforts in today’s software organizations sadly encompass virtually all aspects of the work. Frameworks, languages, deployment operating systems, and cloud service providers are all mandated. Wrappers are written for pre-approved libraries. CI/CD tools and pipelines are centrally developed and administered. Adherence to exhaustive coding standards is enforced for all code submissions. Is there any room for innovation in these arrangements?