A kick in the pants is a particularly bad form of motivation. As Frederick Herzberg points out, a kick in the pants doesn't produce motivation; it just produces movement (Herzberg 1987). To tap into the "10" of that 10-to-1 difference in individual performance, you have to go beyond movement and tap into developers' internal motivations.
Excite your developers. Create an environment in which they can satisfy their internal drives. When people are excited, they will put in long hours and enjoy it. You can generate a sense of excitement by focusing on the five factors that most influence developer motivation: achievement, possibility for growth, work itself, personal life, and technical-supervision opportunity. The following sections take up these five factors in detail.
Software developers like to work. The best way to motivate developers is to provide an environment that makes it easy for them to focus on what they like doing most, which is developing software.
Ownership—"buy-in"— is one key to achievement motivation. People will work harder to achieve their own goals than to achieve someone else's. Microsoft's Chris Peters points out that if you let developers create their own schedules, they take ownership of their schedules, and you get their buy-in. You don't have to worry about long schedules because the schedules that developers generate are always ambitious (Cusumano and Selby 1995). You might have to worry about some of the problems associated with overly optimistic schedules or developers voluntarily working too much overtime, but those aren't motivation problems.
CROSS-REFERENCE
For details on problems associated with ownership, see Managing the Risks of Signing Up, Managing the Risks of Signing Up. For details on the hazards of too much voluntary overtime, see Chapter 43, Chapter 43.
Goal setting is another key to achievement motivation. Explicitly setting development-speed objectives is a simple, obvious step in achieving accelerated software development, and it's easy to overlook. You might wonder, if you set a development-time objective, do developers actually work to achieve it? The answer is yes, if they know how that objective fits in with other objectives and if the set of objectives taken as a whole is reasonable. Developers can't respond to objectives that change daily or that are collectively impossible to meet.
Gerald Weinberg and Edward Schulman conducted a fascinating experiment to investigate the effect of objectives on developer performance (Weinberg and Schulman 1974). They gave five teams of developers the assignment of working on five versions of the same program. They gave the same five objectives to each of the five teams; however, they told each team to maximize a different objective. They told one team to minimize memory required, another to produce the clearest possible output, another to make the most readable program, another to use the minimum number of statements, and the last group to complete the program in the least amount of time. The results are shown in Table 11-2 on the next page.
Table 11-2. Team Performance Ranked Against Objectives That Teams Were Told to Optimize
Team Ranking on Each Objective | |||||
|---|---|---|---|---|---|
Objective that Team was Told to Optimize | Memory Use | Output Readability | Program Readability | Minimum Statements | Minimum Programming Time |
Source: "Goals and Performance in Computer Programming" (Weinberg and Schulman 1974). | |||||
Memory use | 1 | 4 | 4 | 2 | 5 |
Output readability | 5 | 1 | 1 | 5 | 3 |
Program readability | 3 | 2 | 2 | 3 | 4 |
Minimum statements | 2 | 5 | 3 | 1 | 3 |
Minimum programming time | 4 | 3 | 5 | 4 | 1 |
The results of this study were remarkable. Four of the five teams finished first in the objective they were told to optimize; one team finished second in its objective. They also gave each team a secondary objective, and, on those, three of the teams finished second in their secondary objective, one team finished first, and one team finished last. None of the teams did consistently well in all objectives.
The implication of this study is that developers do what you ask them to do. They have high achievement motivation: they will work to the objectives you specify, but you have to tell them what those objectives are. If you want your team to develop a program in the minimum time, tell them! You can also tell them you want to minimize risk or maximize progress visibility. Depending on your situation, any of those goals could be the most important contributor to "rapid development."
Successful projects use goal setting to their advantage. Boeing captured its design goals and objectives for the 747 in a book titled Design Objectives and Criteria. If you think that goal setting isn't critical to the success of a project, consider that Boeing turned down an offer of $100 million from the Soviet government for a copy of that book (Larson and LaFasto 1989).
Be aware that it is possible to go too far in goal setting. If you give a team several objectives at once, it's often not possible for them to do well on all of them. None of the teams in the Weinberg and Schulman study did well on all criteria. A study at ITT found that productivity dropped sharply when multiple goals were present (Vosburgh et al. 1984).
CROSS-REFERENCE
Goals should be clear, but they don't necessarily have to be simple to work. For a different angle on goal setting, see Shared, Elevating Vision or Goal in Creating a High-Performance Team.
Setting too many goals at once is a common problem. A review of 32 management teams found that, in response to the question, "What does the leader do that keeps the team from functioning more effectively?" the most common response was that the leader diluted the team's efforts with too many priorities (Larson and LaFasto 1989). The researchers identified this as a major leadership blind spot because most team leaders gave themselves high ratings in the area of setting priorities. For best results, select one objective and make it clear that it is the most important one.
One of the most exciting aspects of being a software developer is working in a field that is constantly changing. You have to learn something every day just to stay current, and half of what you need to know to do your job today will be out of date 3 years from now. Considering the nature of the industry developers have chosen to work in, it isn't surprising that they are motivated by possibilities for growth.
An organization can tap into that motivation by providing developers with opportunities to grow on their projects. This requires aligning the growth goals of the organization with the growth goals of the individual. Barry Boehm (1981) puts it this way:
The principle of career progression indicates that it is in an organization's best interest to help people determine how they wish to grow professionally, and to provide them with career development opportunities in those directions. This may seem like a somewhat obvious principle, but in practice there are many software organizations which follow strongly opposing principles.
The boss in Case Study: A Disheartening Lunch with the Boss undercut the team's possibility for growth by canceling the advanced C++ classes, thereby undercutting the team's motivation at the same time.
An organization can show interest in its developers' professional growth in any of these ways:
By providing tuition reimbursement for professional-development classes
By giving time off to attend classes or to study
By providing reimbursement for purchase of professional books
By assigning developers to projects that will expand their skill sets
By assigning a mentor to each new developer (which shows both the mentor and the new developer that the organization is dedicated to professional growth)
By avoiding excessive schedule pressure (which tells developers that the real, top priority is getting the next product out the door regardless of the personal cost)
How much should you spend? There really is no upper limit. In Thriving on Chaos, Tom Peters reports that Nissan budgeted $30,000 per person in start-up training costs when they opened their plant in Smyrna, Tennessee (Peters 1987). Companies that are in the top 10 percent of their industries in quality and productivity typically provide 2 weeks of training per year for software developers and 3 weeks for software managers (Jones 1994).
A focus on personal growth can have both short-term and long-term impacts on your organization's productivity. In the short term, it will increase your team's motivation, causing them to work harder. In the long term, your organization will improve its ability to attract and keep people from the top of the talent pool. As John Naisbitt and Patricia Aburdene say in Reinventing the Corporation, "The best and brightest people will gravitate toward those corporations that foster personal growth" (Naisbitt and Aburdene 1985). In other words, support for professional development is vital to the health of any corporation—and especially so in the software field.
Richard Hackman and Greg Oldham argue that, generally, people's internal motivation comes from three sources: They must experience meaning in their work; they must experience responsibility for the outcome of their work; and they must know the actual results of their work activities (Hackman and Oldham 1980).
Hackman and Oldham identified five dimensions of the work itself that contribute to these sources of motivation. The first three of these job characteristics contribute to how meaningful people find their work to be:
Skill variety is the degree to which your work requires you to exercise a variety of skills so that you can avoid boredom and fatigue. People find meaning in jobs that offer variety, even in work that is not very significant or important in any absolute sense.
Task identity is the degree to which your job requires you to complete a whole, identifiable piece of work. People care more about their work when they have a whole job to do and when they feel that their contribution matters.
Task significance is the degree to which your work affects other people and contributes to social welfare. People need to feel that the final product has value. As Hackman and Oldham point out, people who tighten nuts on airplanes will feel that their work is more important and meaningful than people who tighten nuts on decorative mirrors. Likewise, developers who are allowed to meet customers and understand the big picture within which they do their work are likely to feel more motivated by their work than developers who are kept in the dark (Zawacki 1993).
The fourth job characteristic contributes to a person's feeling of responsibility for the outcome of the work:
Autonomy is the degree to which you have control over the means and methods you use to perform your work—the sense of being your own boss, and the amount of elbow room you have. The more autonomy people have, the greater sense of personal responsibility they tend to feel for the outcome of their work.
The fifth and final job characteristic contributes to how much people know about the actual results of their work activities:
Job feedback is the degree to which carrying out the job itself provides you with direct and clear information about how effective you are. (This is different from receiving feedback from a supervisor or coworker.) Software development provides great job feedback because the work itself—the program—provides the feedback: you can see immediately whether the program works when you run it.
One key to motivation is to control these five dimensions to create meaningful work and then match up that work with people who have a high desire to achieve. Robert Zawacki reported that his 15 years of research indicate that about 60 percent of a developer's motivation comes from the matchup between the job and the developer (Zawacki 1993).
The importance of the work itself is one reason that quality is usually more motivating to software developers than schedule. Creating something on the leading edge is a rush to a technically oriented person. It provides a level of motivation that's hard to create outside of a project team that's pushing the state of the art in some way or other.
CROSS-REFERENCE
For a practice that pushes this kind of motivation to the extreme, see Chapter 34, Chapter 34.
Another motivational aspect of the work itself is the degree to which the environment allows a developer to focus on the work itself compared to how much it requires the developer to focus on related concerns.
In most of the organizations I have been associated with, I have spent a significant portion of my time each day on trivial administrative tasks that broke the day into a series of distractions that didn't contribute to the project I was working on. In one organization, to get a pad of paper I had to walk from the fifth floor to the second floor, pick up the pad of paper in the supply room, and sign for it with my name and project account number. If I couldn't remember my project account number, I had to call someone back on the fifth floor to get it (and interrupt them) or I had to walk back up to my desk, look up the account number, and then walk back down to the second floor and start over.
In another organization, to make more than 10 photocopies I had to walk several buildings away, leave the copies overnight, and pick them up the next morning. When I have had problems with my computer, the most common organizational response has been to have me try to fix it myself. If that fails, the organization will bring in a professional computer technician a day or two later. In the meantime, the typical response is something along the lines of, "You don't absolutely need a computer to do your work, do you?"
Procuring anything unusual—bookcases, whiteboards, corkboards, an extra monitor for debugging, and so on—has taken anywhere from weeks to months. For a software developer who wants nothing more than to develop software, it can be incredibly frustrating (and demotivating) to have to spend time filling out a form just to get a notepad.
Aside from not eliminating administrative hassles, some traditional corporations inadvertently divert attention from the work itself by placing an emphasis on nonwork aspects of their environments. Enforcing a dress code suggests that the work itself, while important, is not of utmost importance. Enforcing strict work hours suggests the same thing. In some organizations, such policies are beneficial to the organization's image, but every organization should be sure to understand the message those non-work-itself policies convey to developers. Ask whether the image is important enough to justify the loss in motivation and productivity.
Achievement, possibility for growth, and work itself are in the top five motivators for both developers and managers (although they prioritize the factors differently). Those factors present a significant opportunity for developers and managers to understand what makes the other tick. But personal life is fourth for developers, fifteenth for managers. Thus, the motivational impact of a developer's personal life is likely to be the hardest motivational factor for a manager to understand. A close second is probably responsibility, which is ranked first for managers and tenth for developers.
One upshot of this disparity is that managers sometimes reward their best developers by assigning them to their highest-profile, highest-pressure projects. To the manager, the extra responsibility would be a treat, and the diminished personal life wouldn't matter much. To a developer, the extra responsibility is more trick than treat, and the diminished personal life is a keen loss. The developer interprets the manager's "reward" as punishment.
Fortunately, a manager doesn't have to understand in detail why developers' personal lives are important to them. A company can't do much to use personal lives as motivators except to schedule projects realistically so that developers have time for personal lives, to respect vacations and holidays, and to be sensitive to occasional requests for time off during the workday.
Managers are less motivated by opportunity for technical supervision than are developers. The easiest way to understand this is to recognize the connection between technical-supervision opportunity and achievement. For a developer, a technical-supervision opportunity represents an achievement. An opportunity to supervise technical work implies that the developer has achieved a level of technical expertise sufficient to direct others. For a manager, a technical-supervision opportunity would probably represent a step backwards; the manager is already supervising others and is quite happy not to be supervising technical details. So it's really not surprising that developers are more motivated by technical-supervision opportunity than managers are.
Technical-supervision opportunities are not limited to assigning one person to be the technical lead on a project. You can use this motivator more broadly:
Assign each person on a project to be the technical lead for a particular product area—user-interface design, database operations, printing, graphics, report formatting, analytics, networking, interfacing with other applications, installation, data conversion, and so on.
Assign each person to be the technical lead for a particular process area—technical reviews, reuse, integration, tool evaluation, performance evaluation, system testing, and so on.
Assign all but the most junior developers to be mentors. You can assign second-level mentors to work with the first-level mentors. The second-level mentors can help with the mentoring activity itself, or they might provide more technically-experienced advice to the first-level mentors.