I recently stumbled upon a book by Thomas Craughwell about urban legends [1]. While reading Craughwell's book, I realized that I have been the victim of urban legends at work. Someone (sometimes me) has taken a legend as truth, acted on it, and had it end badly. Understanding what is legend and what is truth can help when managing IT and other work.

Here are three urban legends I've encountered at work and how they either backfired on me or caused me grief when trying to manage projects.

1. The Legend of the Private and the General

On the eve of a great battle, an 18-year-old private sneaks into the tent of the commanding general. The general wants earnestly to know what the privates in his army are thinking and feeling, so they have a long conversation. The information the private relays is treasured by the general, used to win the battle, and the private is rewarded.

My True Story

On several occasions when I was in a position similar to that of the private, I quietly arranged a meeting with a senior manager in a position similar to that of the general. We talked awhile and I returned to my office. The next day, I was chastised by several managers sitting in positions between the senior manager and me. How dare I skip all levels of management. What was I thinking?

The Moral of the Story

Middle managers want to become senior managers. They do so by having "face time" with senior managers and they don't like it when underlings get that face time instead. If you cannot abide with such rules of hierarchical organizations, don't get a job in one.

2. The Legend of the Feature that Cost Nothing

An engineer has an idea for a feature to be added to a system. He pitches the idea, but managers reject it. The engineer slips the feature into the system anyways "at no cost." When the system hits the marketplace, the feature becomes visible, customers love it, and the company makes a fortune from it. The engineer is rewarded handsomely.

My True Story

I don't have space to write about all the instances where a lone engineer or programmer sneaked a little feature into a system. The little feature broke the system because it collided with an interrupt or a section of memory or a bus address or something else.

The Moral of the Story

Encourage people to experiment and insert new features into a system. Have them do this in a fork of the system baseline off to the side created especially for such experiments. Hold code and design reviews so that people can discover any attempts to sneak features into the system. The disappointing fact is the more features there are in a system the greater chance that something will
break the system.

3. The Legend of the Skunk Works

A group of engineers, scientists, and others is set off to the side of the big, slow (stupid) company. Unfettered by bureaucracy, they create an amazing system that solves one of the world's great problems and makes a fortune for the company.

My True Story

I worked in a digital signal processing laboratory for four years. I was responsible for all the software modifications in the lab. A group of people constantly cited the legend of the Skunk Works as a reason for avoiding the bureaucracy that I was imposing. The definition of what bureaucracy was changed to reflect whatever it was they didn't want to do on any particular day. Their constant desire to avoid whatever they didn't want to do cost us untold resources and produced nothing in return.

The Moral of the Story

This one is tough for people to accept. The legend is based on the Lockheed Skunk Works begun in the 1940s (it even has its own logo -- see Wikipedia). The Lockheed Skunk Works had a record of remarkable accomplishments. The Skunk Works did not, however, build a worldwide fleet of SR-71s without design drawings, design reviews, configuration management, quality control, and other such practices that are common when building systems that involve human safety. People practice such things because they work, not because they frustrate creative people.

Most urban legends have some shred of truth in them. A shred of truth is not full truth. I advise that you distinguish urban legend from practice and have everyone in your organization know the difference.

I would like to hear of other urban legends at work. Please send them to me at comments@cutter.com.


REFERENCE

1. Craughwell, Thomas J. Urban Legends, 666 Absolutely True Stories That Happened to a Friend of a Friend of a Friend . Black Dog and Leventhal Publishers, 2002.