In Inside RAD, Kerr and Hunter chronicle the day-to-day activities of a rapid-development project (Kerr and Hunter 1994). At the end of their client company's first successful RAD project, top management met with the development team to figure out how to repeat the project's success. The team made many recommendations, most of which were accepted. Among other things, the team recommended establishing an awards program and listed a variety of possible rewards—recognition dinners with company executives, cash bonuses, vacation-time bonuses, gifts of appreciation (theater tickets or dinners for two), and award ceremonies. Kerr and Hunter reported that the awards-program proposal was clearly management's least-favorite recommendation, and at the time Inside RAD was published, nothing had been done to implement that recommendation.

When you take a step back from Kerr and Hunter's story, you see something incredible. Kerr and Hunter describe a project that was successful enough to write a book about, but the company that received the benefit of this exceptional project balked at rewarding its developers. When the development team actually asked to be rewarded, the company responded by pocket-vetoing any reward. How many more successful rapid-development projects do you think that company will get from that team?

Developers grow tired of working for unappreciative companies, and rewards are therefore important to long-term motivation. But monetary rewards have to be handled carefully. Developers are good at math, and they can figure out when a reward is not commensurate with the sacrifice they've made. In "Improving Software Productivity," Barry Boehm reported that poor reward systems are systems in which an organization gives its top performers 6-percent raises and its mediocre performers 5-percent raises. Eventually the top performers get frustrated and leave (Boehm 1987a).

It's also important to present any reward purely as a gesture of appreciation rather than an incentive. At least two-dozen studies over the last 30 years have shown conclusively that people who expect to receive a reward for doing their jobs successfully don't perform as well as those who expect no reward at all (Kohn 1993). The work itself is the greatest motivator, and the more a manager stresses an external reward, the less interested the developer becomes in the work itself, and the more potential motivation is lost.

Here are some possible gestures of appreciation that are often appropriate:

In In Search of Excellence, Peters and Waterman (1982) report that the companies that manage to stay in the top halves of their industries over 20-year periods make extensive use of nonmonetary incentives. They put it this way:

As with any show of appreciation, it's the thought that counts. Be sure that your rewards say "appreciation" rather than "incentive" or "manipulation."

In one of the most famous experiments in motivation and productivity, Elton Mayo and his associates ran a series of tests on worker productivity from 1927 to 1932 at the Hawthorne Works of the Western Electric Company in Chicago. Their aim was to determine the effect of lighting on productivity. First they tried turning the lights up, and productivity went up. Then they tried turning the lights down, and productivity went up again. They tried holding the lights constant, and productivity went up yet again (Boehm 1981).

After many more experiments, Mayo drew a conclusion that had nothing to do with lighting levels. He concluded that the simple act of conducting the experiments had increased productivity.

Figure 11-1. The well-appreciated software developer.

The "Hawthorne effect" (as it has come to be known) has been confounding productivity experiments and software metrics programs for decades. If you are a scientist, you would like to eliminate the Hawthorne effect because it interferes with your ability to determine whether the introduction of a new technology really improves productivity or whether the improvement is merely an example of the Hawthorne effect. But if you're a technical lead or manager, the Hawthorne effect is pure gold. If you're in the business of producing software, it doesn't matter whether the improvement in productivity comes from the new technology or the Hawthorne effect. If your experimental results are skewed, they'll be skewed on the high side, which is what you were after anyway.

The implication for software projects is clear. Run every software project as an experiment, as a pilot project. Try out some new methodology or new technology on each new project, and be sure that your team knows that the project is a pilot project. If you gather conclusive data on the effectiveness of the new methodology or new technology, great! You can use that data as a basis for spreading the methodology or technology to other projects in your organization. If the data you gather is inconclusive, you still get the benefit of the Hawthorne effect. As with rewards, remember that there is a fine line between motivation and manipulation. Don't manipulate.

Proper execution of a performance review significantly increases motivation, and improper execution of a performance review significantly decreases motivation. Andrew Grove, president of Intel, says that a performance review "is the single most important form of task-relevant feedback we as supervisors can provide" (Grove 1982). He goes on to say that, "The review will influence a subordinate's performance—positively or negatively—for a long time, which makes the appraisal one of the manager's highest-leverage activities."

W. Edwards Deming once stated the point a little differently when he said that most American reviews are conducted poorly, and it takes the average manager half a year to recuperate from his or her performance review (Peters 1988). He said that the American propensity for negative performance appraisals is our number-one management problem.

If your organization conducts performance reviews once or twice a year, take advantage of this high-leverage activity. Be sure that the reviews you're involved with increase rather than reduce motivation.