Proper Use of Overtime by Bruce Nielson
It seems to me that “overtime” is a much talked about subject, both in literature and just around the water cooler, but that people tend to take one of two extreme views on it.
The first view is that overtime is immoral unless the development team screwed up. This point of view says, “if I made a mistake, I’ll make good, but otherwise, I expect to never have to work overtime. So long as I’m giving it my best, overtime – particularly unpaid overtime – is immoral to ask me for.”
The second point of view is that “it’s part of the job.” From this point of view overtime is just part of doing your job and no developer should think otherwise. Those that do think otherwise should seek other employment.
Now it seems to me that people don’t usually stick with one point of view on this. We tend to swing about, based on our current situation, as to whether or not overtime is “part of the job” or “an immoral practice.” Particularly, we tend to think of it as “part of the job” when it’s someone else and “an immoral practice” when too much of it is asked of us personally.
I propose that neither point of view is true.
I think overtime is a legitimate tool in the toolbox to get a job done. But if it’s your only tool – or worse yet, only remaining tool -- you’ve probably already lost the battle.
In a past post I pointed out that software estimates tend to be pretty bad. And elsewhere, I pointed out that the need for upfront estimates is a ‘water breather’ i.e. the need for them is so significant that lack of ability to make good estimates isn’t reason enough to not make them.
I think the rest is obvious. In business, we rely on estimates that we often can’t accurately make. Even if we “do it right” when making an estimates it’s just not always enough for the estimate to be accurate. So when estimates fail, we must face hard choices. These include:
1. Cutting scope
2. Working overtime
3. Delaying the due date
Now it’s easy to say “Well, just cut scope or delay the due date, because it’s wrong to ask me to work overtime for something that isn’t my fault. I had no way of knowing that X was going to happen and delay the project.”
But I think this is an unrealistic view. If a project estimate goes south, typically it goes far south, so there is often a need to do all three of the above to rectify the situation.
But of course the inverse point of view must also be seen as valid. If your team is working overtime to make up a bad schedule, but you aren’t also cutting scope and/or delaying the due date as far as possible, then you might as well admit that you aren’t serious about your schedule and you’re really just punishing the team.
Oh, and expect your team to be aware of this.
So what’s the proper use of overtime? I’d say it’s one tool in the box to deal with bad estimates, that it shouldn’t be used without using other means as well (such as cutting back on scope), and that you should be careful to not do it more often than is necessary.