Mousetrap Company
As published in Corp! Magazine
Remember the classic kid’s game, Mousetrap? In this historic tribute to the legendary Rube Goldberg, players have to assemble an exceedingly convoluted and baroque mechanism that will supposedly catch a mouse. As I have young kids, I recently had a refresher course in the game. What was interesting was the debate about which part of the trap is the most important: the crank turn at the beginning? The shoe that kicks the bucket, the ball bouncing down the stairs, the diver that flies into the washtub or the trap itself falling down the pole? In the end, most of the kids decided that it must be the trap, since without that you can’t actually catch the mouse.
Listening to the debate, I had the rather disturbing experience of being reminded of a certain software company. A similar debate occurred there as well: the engineers who were supposedly designing and implementing the software were being raked over the coals because they hadn’t successfully produced a workable product by the deadline. At first glance, it was clearly their responsibility to build the product, and their failure was costly indeed to the company.
The first glance is not, however, always the most accurate one.
In the game of Mousetrap, a number of things have to happen correctly in order for that all important trap to fall. If the shoe doesn’t kick the bucket, the ball won’t go bouncing down the stairs. If the crank doesn’t turn, the gears won’t rotate and the shoe won’t move. Indeed, while a failure at any point in this wonderfully elegant mechanism will derail the whole thing, failure at the start means that it won’t even get going.
At this software company, the process for getting a release out the door was, unfortunately, even more elaborate than the mousetrap. The biggest problem, though, was the crank at the top. The company had several products, and competition for resources was fierce. What the CEO seemed to be paying attention to was what received the time and energy of the engineers. Although the CEO kept saying that this particular release was critical to the future of the company, he made no effort to organize the company around that release, nor did he delegate that task to anyone else. Thus, the assumption from the top down was that this release couldn’t really be as important as all that.
By the time engineering got involved, the engineers were focused on multiple tasks. Without any direction from above, they took their best guess on which direction to go. Being engineers, that meant that they pursued the interesting technical problems, not the serious business priorities: when not given direction, most people will do the thing they are best at doing, whether or not that is the thing that really needs to be done at that moment.
When it came time to ship the product, the best that could be said about it was that it didn’t crash too often. The customer was not pleased.
What happened here was that there was no logical flow of control or means of prioritizing tasks. Superficially, an unhappy customer was the fault of the engineers; certainly, they took the blame. However, was that really accurate? The engineering team did their job as best they could with the information they had available. The real failure was in the leadership: when no one is leading, people follow the path of least resistance. That may not get you where you want to go. Although the failure did not manifest until the very end, the seeds of that failure were sown long before the engineers ever started working on that particular product.
Fundamentally, it is the job of the leader to set the direction for the company and keep people moving in the right direction.
It is the job of the leader to build the team so that the employees will follow him in that direction. It is the job of the leader to build up his management team so that he does not become the bottleneck. It is the job of the leader to make sure that the technical problems and the business problems are in alignment and that the biggest contracts are the ones that get priority. This seems obvious, but for something obvious, it certainly fails to happen in far too many situations.
In this particular situation, the company’s mousetrap didn’t work very well. The trap didn’t fall. The rod didn’t move. The diver didn’t dive. The crank might have turned, but it didn’t turn particularly well. Indeed, the company really only got one part of the mousetrap process to work well.
They did manage to kick the bucket.
Stephen Balzac is a consultant and professional speaker. He is president of 7 Steps Ahead (www.7stepsahead.com), an organizational development firm focused on helping businesses to increase revenue and build their client base. Steve is a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play,” and the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill. Contact him at steve@7stepsahead.com.
