Get our video course, "Improv Your Agile or Scrum Stand-up", for free when you subscribe to our mailing list!

The Problem with Working Overtime

Share/Bookmark Subscribe’s an old programmer quote that goes something like this,

Some people, when confronted with a problem, think
“I know, I’ll use regular expressions.”   Now they have two problems.

I feel the same way about teams working overtime.  In fact, I would phrase it like this,

Some people, when confronted with a problem, think “I know, we’ll just work some overtime.”  Now they have two problems. [click to tweet]

They still have their original problem and have now added one more problem to the pile.

So what’s the second problem?

The problem is that overtime has been proven time and again to be detrimental to both teams and organizations.  Overtime leads to,

  • Fatigue
  • Undertime
  • A Demotivated team
  • Turnover, which in turn results in a loss of tacit knowledge to the organization
  • A reduction in quality
  • Lack of predictability and increased variance

Let’s explore these items.

When workers work overtime they get fatigued, this should be obvious.  It should also be obvious that when people are spending more time working, they’re spending less time resting and getting things done in their personal lives.  This means they will be less focused and productive on the job. On top of that, they may have to start taking care of personal business at work and there may be an increase in absenteeism, sick days, and work from home time.  The combination of all these factors is often referred to as “undertime”.  This is inevitable and not something that can be easily managed away.

It also demotivates the team.  Who wants to work on a death march project?  Who wants to be told again and again, that while their “concerns are valid and failure seems inevitable, we must continue to pour in more hours in the hopes that we can get something somewhat passable out the door by the deadline”?  That doesn’t sound like an organization I’d want to work at for very long.

Eventually, the people who can find other jobs, do find other jobs.  This leads to a loss of tacit knowledge that can never be recovered by the organization.  This will make any future projects even more difficult and painful since all the people who understood how things worked in the organization, no longer work there.

Of course, with fatigue and tight time lines, quality is usually the first thing to go.  That’s ok, since we know all about technical debt, and we can take some on as long as we’re willing to pay it off later, right? 

Well, organizations that view overtime as a solution often never end up paying off their technical debt.  This means more bugs and live issues to deal with.  It also becomes harder and takes longer to develop new features since you have to wade through more poor/hacked code.

This means there is now more variance in your system.  More variance, means more unpredictable things that could pop up and derail you in the middle of your next project.  Also, since the number of hours worked is varying, you can’t really get a handle on how productive the team is on a more regular schedule. 

In turn, this makes it harder to put together a reliable schedule for your future projects. But don’t worry, you can just work some more overtime to catch up on… oh, wait…

Oh, and if that wasn’t enough.  It looks like overtime is also bad for your health.

So let’s update our original statement a bit,

Some people, when confronted with a problem, think “I know, we’ll just work some overtime.”  Now they have a large number of unpredictable problems that will reveal themselves in the future when you least expect it.

Still sound appealing?  Let’s continue.

Who’s making the commitment for the team to work overtime in your organization? [click to tweet]

In most organizations, it’s usually management coming to the team and either asking or mandating that they work overtime.  From the perspective of the team, it looks like the team is being asked to make sacrifices to get management out of a bind they created by being unable to properly plan a project or stand up to clients. 

No wonder they lose motivation.

This perception is at least partially true.  As we’ve seen above, it becomes difficult for any team caught in this cycle to perform at a predictable pace and it’s left to the poor manager to try and pick a random number that’s not too offensive to the client and still looks somewhat plausible to the team.  So I’ll give most managers in this situation a pass on that one.

However, the team is correct in assuming that this is not a development team problem.  While the team may be able to provide ideas on technical solutions or changes to approaches that might assist with the scheduling problem, at the core, this is a business problem.  Things have gone awry for one reason or another and now we have to adjust our plan.  Typically you’d expect to hear things about a triangle of scope, cost, and schedule.  I don’t see overtime in that list…

So why isn’t the problem being taken to the business/client?  Because that’s a hard conversation to have, and most people, including managers, fear hard conversations and will avoid them at all costs. [click to tweet]  Sometimes it’s just easier to say, “Just do it”, to the team than it is to say, “We can’t do it”, to the client.

Failure to have this conversation with the client is a failure to respect the client.  That may seem counter-intuitive, but it’s true.  Good client relationships are based on trust and trust means being open with the client when things have gone bad.

If you keep aggressively pushing and pushing and continue to fail to deliver quality software, you will lose the confidence of the client.  On the other hand, if you give them adequate notice and treat them with respect, they may be disappointed, and unhappy, but they will at least respect you for your honesty.  Without respect, there is no trust.  A relationship without trust cannot last long.

It’s also important to note, that it doesn’t matter whose fault it is.  The conversation required here is not about blame, it is simply about discussing the reality of the current situation and adjusting accordingly.  There will be a time for discussing where things can be improved, but that conversation must be a separate discussion from any discussion involving overtime as the two are unrelated.

What if the client insists that you work overtime?  Well, here’s where managers earn their money.  It’s up to management to explain to the client exactly what the possible side effects are to the situation and what the team can and cannot be accountable for if they accept the overtime request. 

In addition, the client must be willing to accept any additional financial costs, recovery hours, as well as scheduled time to pay off any technical debt accrued during this time.  The preference should always be given to avoiding overtime work.  The costs far out weigh the benefits.  Good managers are able to convince clients that overtime is not the path to go down.

So based on this, let’s update our statement again,

Managers, when confronted with a scheduling problem, think “I know, instead of having a valuable business discussion with the client, I’ll just make the team work some overtime.”  Now they have a large number of unpredictable problems that will reveal themselves in the future when you least expect it and result in an unhappy client who does not trust the team.

Who’s up for some overtime?

Today’s image by tm-tm

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!

blog comments powered by Disqus


  1. hardwinder reblogged this from planningforfailure
  2. jmora reblogged this from planningforfailure
  3. planningforfailure posted this