Overtime is misused more often than it's used effectively, so keep the following guidelines in mind if you want to get more than 40 productive hours per week out of your team members.

Use a developer-pull approach rather than a leader-push approach. Trying to motivate developers can be like trying to push on a rope—you'd be better off pulling on the other end. Gerald Weinberg points out that one of the best known results of motivation research is that increasing the driving force first increases performance to a maximum—and then drives it to zero (Weinberg 1971). He says that the rapid falloff in performance is especially observable in complex tasks such as software development: "Pressing the programmer for rapid elimination of a bug may turn out to be the worst possible strategy—but it is by far the most common."

When motivation is low, it also doesn't matter how much time people spend at the office. You won't get 40 hours of work out of them. They'll put in time just to keep up appearances or to avoid feeling bad about not meeting their deadlines.

As Figure 43-1 suggests, developer motivation with average schedule pressure is already high. A nudge is all you need to achieve maximum performance. Additional pressure causes a falloff in performance.

Figure 43-1. Optimum zone for schedule pressure. A nudge is all that's needed to achieve the highest possible motivation. Source: Adapted from Applied Software Measurement (Jones 1991).

It's OK to ask for a little overtime; just don't ask very hard.

Developers are naturally self-motivated, so the key to getting them to work overtime is to tap into their naturally high self-motivation. Create conditions that will make them want to work extra instead of forcing them to. Generally speaking, the top five ways to motivate developers are:

One of the most effective ways to motivate developers is to infuse the entire development team with excitement. Set a clear vision for what the team is supposed to achieve. Help the team develop a sense of team identity. And let the team know that results count more than hard work.

The importance of a results focus is one of the main reasons that leader-push overtime doesn't work. A focus on the number of hours a person spends at the office puts the emphasis on style rather than substance. On a rapid-development project, you need to focus on how much work is getting done. If people are meeting their deadlines and motivation is high, it doesn't matter whether they're in the office 50 hours or 25.

Don't require overtime; it will produce less total output. Here is one of the possible objections to Figure 43-1:

To understand the flaw in this argument, understand these three points:

The problem with pressing for more overtime than developers want to work is that when motivation begins to drop, it doesn't just affect the 10 or 20 overtime hours: it affects the 10 or 20 overtime hours plus the 40 regular hours. When you press for overtime, you lose productivity in motivation faster than you gain it in overtime. Figure 43-2 shows the relationship between schedule pressure/hours worked, total output, and developer motivation.

Figure 43-2. Relationship between schedule pressure/hours worked, total output, and developer motivation. If you apply more than a hint of overtime pressure, motivation will drop sharply. Because you lose output faster in motivation than you gain it in extra hours, total output drops too.

As the figure shows, the total output peaks at the same number of hours per week as developer motivation. Because motivation is the strongest influence on productivity, as motivation drops off, total output drops off too. It doesn't drop off as sharply because the drop in motivation is partially offset by the increased number of hours worked.

The implication of Figure 43-2 is startling: Beyond the number of hours that the average developer will work voluntarily, you will reduce total output if you push for more overtime. It doesn't matter what your reasons are or how good they are unless your developers find them as persuasive as you do. If they don't buy your reasons, their motivation will drop and more overtime will result in less progress.

We all know of circumstances in which managers push so hard for overtime that developers work 60 hours a week or more, and sometimes in those circumstances more hours truly does result in more output. The reason for this is that once motivation hits rock bottom, it becomes possible to improve total output by demanding more overtime. The motivation can't get any worse and the hours go up, so the developers produce more total output.

In Figure 43-2, that would be a part of the graph that's not shown, the area to the right of very high schedule pressure. The problem with that practice is that it's penny-wise and pound-foolish. The overzealous manager who insists on that much overtime would gain far more by backing off a lot than by pushing for a little more.

Don't ask a developer to work more overtime than he or she wants to work. Developers are like cats. If you push them in one direction, you can't predict which way they'll go except that they won't go in the direction they're pushed. If you need to get more done, come up with a different solution.

The specific number of hours per week that's correlated with maximum output varies among projects. Some highly motivated developers hit their maximum output in a 35-hour workweek. A few might be able to work as many as 80. Typical developers in the U.S. probably achieve maximum output between 44 and 48 hours. Because it's difficult to know how many hours worked result in optimal output for a specific developer, the key to maximum output is to aim for the highest possible motivation regardless of how much or how little overtime that implies.

Don't use overtime to try to bring a project under control. When a project is perceived to be out of control, requiring developers to work more overtime is one of the most common things managers and team leads do to bring the project under control. But overtime is, in itself, a sign that a project is out of control. Projects that are under control do not require developers to work overtime. Some developers might work overtime because they are highly interested in their project, but they do not need to work overtime to meet their deadlines.

Ask for an amount of overtime that you can actually get. Opinions vary about how much time programmers can spend working. John Boddie, author of Crunch Mode, says that once the project gets rolling, you should expect members of the team to be putting in at least 60 hours a week and up to 100 hours a week for a few weeks at a time (Boddie 1987). On the other hand, Microsoft veteran Steve Maguire argues that people who work that many hours tend to sandwich personal tasks into their workdays. They take longer lunches, exercise, run errands, pay bills, read computer magazines—in other words, they do a lot of things at work that they would do on their own time if they were working only 8 hours a day. Maguire concludes that people who spend 12 hours a day at the office rarely actually work more than 8 hours, although he acknowledges that a self-motivated person will occasionally work more (Maguire 1994). Other experts have also concluded that you can't expect to average much more than 8 hours per day (Metzger 1981, Mills in Metzger 1981, DeMarco and Lister 1987, Brady and DeMarco 1994).

I don't know what effect schedule pressure has on the amount of time people spend working. I have often seen what Maguire describes. I have seen people work 50 hours per week for months at a time. I have occasionally seen people work as much as Boddie describes, although only for a week or two at a time.

If you're asking developers to work voluntary overtime, watch how much time they actually spend working. If lunches start to drag on and people start to arrive late at meetings because they have been running errands, you have asked for more overtime than the developers are willing to give you. Back off. You're driving developer motivation out of Figure 43-1's optimum zone.

An alternative to simply backing off is allowing the developers to cut back to 40 hours per week while you insist that they actually work each and every one of those 40 hours. That position is inherently fair and reasonable on a rapid-development project, and I think it often produces more real work hours than asking for overtime does.

Beware of too much overtime, regardless of the reason. By far the greatest problem associated with moderate overtime is its tendency to drift into excessive overtime. That's a systemic problem with any kind of overtime, voluntary or mandatory. It doesn't seem to matter whether the pressure to work massive overtime comes from within or without, excessive overtime and the excessive schedule pressure that accompanies it lead to the following schedule problems:

Help developers pace themselves. Even if no one is forcing developers to work too much overtime, they can sometimes force themselves to work too much. When that pressure comes from within, it doesn't have a motivational penalty, but it will likely have an effectiveness penalty.

Have you ever watched sprinters run the 100-meter dash? When they're done, their chests heave, their skin is blotchy, and sometimes they're even sick. If runners were to begin a marathon at that pace, they wouldn't finish.

In track and field events, distance runners pay an average-speed penalty for top performance over longer distances. As Figure 43-3 shows, the world-record holder in the marathon runs only about half as fast as the world-record holder in the 100-meter run.

Figure 43-3. Average speed of world-record holders in running events of various distances. As with running events, software developers should pace themselves differently on long and short projects.

Likewise, sprinting for a few weeks is not an effective way to begin a major software-development project. Developers working on a 100,000-lines-of-code project are not as fast as developers working on a 5,000-lines-of-code project. There is more interaction with other developers because there are more people on the team, and there is much more integration work. The effect is that per-developer productivity on projects of different sizes varies similarly to runner's speeds at different distances, even when you have world-class developers.

You might be able to plan on 6- or 7-day weeks if you can sprint to a deadline a few weeks away. But if the deadline is 6 months away, you'd better be on the verge of discovering a cure for cancer or protecting the Earth from attack by space aliens to ask for that kind of sacrifice. Otherwise, that kind of sprint will just be a prelude to burnout, high turnover, and a longer schedule.