Anyone who has worked in a team that I’ve managed knows that I’m categorically against the idea of overtime.

Most engineers have been there. Those times when your company really relies on your good nature and willingness to put in the extra hours and have a product ship on time. You put in the effort and your product stakeholders are happy, but are you? The answer may initially be “yes” because you’ve pleased the product owners and your boss, but over a long period of time working in this way can become poisonous to both teams and organisations.

Before I continue I want to clarify that when I refer to overtime I mean overtime that is institutionalised in the organisation. Overtime that is used a crutch to deliver projects on time when management has failed. There are times when working extra hours can be beneficial, but expecting a team to work 10+ additional hours every week is categorically a bad idea. If you’re approaching a team and asking that they work X amount of hours extra over any period of time, then this is institutionalised overtime.

Why overtime is harmful

Most engineers will feel that they’re “going over and above” or being “heroic” by accepting to work additional hours over long periods of time. I have seen this in situations where product delivery was promised but the product’s backlog was far bigger than the team’s resource availability within the timeline. Whilst engineers may be happy to work the overtime (maybe they want the extra cash - if the organisation is kind enough to pay for the additional hours) there are several problems that will arise and ultimately destroy the team:

• It sets unrealistic expectations in the organisation. If you are happy to work overtime “for just this one product” then undoubtedly you are setting the expectation that it is ok for the organisation to rely on overtime again in the future. If an organisation contemplates using overtime then it’s a big enough part of their culture for it to happen again. These organisations are afraid or unable to do the job of correctly managing stakeholder expectations and are willing to burden their employees instead. In most agile software teams overtime is an absolute non-option, because it plays havoc with your velocity and sets unrealistic expectations for the remaining iterations.

• Not all members of the team are able to work the same amount of hours. One example of this is that some people have children or dependents and cannot stay beyond the regular working hours. Initially the rest of the team come together and “cover” the workload of those who cannot work over and above. The problem is that over a long period of time resentment will set in. Those who are working all of the additional hours are the ones who will feel the biggest pressure whilst those who are unable to work overtime will be unaffected. This can vary team to team. Some teams can be made up of young engineers who don’t have any family commitments, but this is an extremely rare scenario.

• Not all members of the team want to work additional hours. You cannot expect that every member of a team is happy to work an additional 10 hours a week. The real problem that this introduces is pressure to comply with the rest of the team. Those who don’t want to work extra hours also don’t want to “let the team down”, and so they work the hours anyway. This brings in resentment and an ultimate dissatisfaction for those team members working on the product.

• It leads to burn out and reduced quality. I wanted to list these as two separate problems, but they are closely related. Working more than 35 hours per week over long periods of time has been shown that it can cause significant damage to your productivity. Not only this but you become fatigued and ultimately more stressed. As engineers we probably only spend about 30 hours a week writing code, so let’s say we can add at most 5 hours of additional work per week. In organisations where individuals are required to work 10+ hours extra per iteration they will see those individuals begin to burn out over time. Burnout unquestionably leads to poor output quality which actually increases the workload on the team in the long term. Agile experts such as James Shore highlight that having your team “work sensible hours” will reduce the number of defects in your product.

• Job dissatisfaction and eventual resignation. Most engineers I meet love what they do. I have met very few engineers who are happy to ship code that is poor quality and badly designed. Based on my previous point this means that over time engineers start to lose sight of what matters to them about programming. They may be happy with the short term rewards like peer recognition, a pat on the back from the boss or even monetary rewards, but eventually they will realise that they do not take pride in their work anymore. The only thing that matters in organisations that advocate and use overtime as a delivery tool is delivering products on time at absolutely any cost, even if that cost is losing your best team members. I have seen many great engineers leave companies because they are not happy with their workload. This will absolutely affect any organisation that is happy to load hours onto a team over a long period of time. In the long term losing team members is far more costly to a business than missing a deadline, and even the product stakeholders lose out by having to suffer the decreased productivity whilst someone else is brought on board.

What to do instead of overtime

When you are considering overtime as a solution, the damage has already been done. Whether you have promised an unrealistic deadline or failed to establish an MVP, overtime is a last resort that should never be used in my opinion. Here’s what I believe should happen instead:

• Focus on an MVP. The MVP (Minimum Viable Product) is a term used to loosely define which features are required in order to have a shippable version of the product. In organisations I have worked in during my past I have found that without an MVP you end up with a huge product backlog that cannot be delivered when presented with an unrealistic deadline. This ultimately means the team is asked to work overtime to meet the deadline. Focus on an MVP and work with your stakeholders to deliver just that. After you have shipped your first release you can continue to deliver value every iteration, this is called continuous delivery.

• Scale your team. This sounds obvious but I have seen organisations continuously pressure members of a team for 60 hour weeks for months on end. The easy solution is just to scale up your team and spread the workload evenly.

• Outsource your workload to trusted contractors. This is probably a last resort. The problem with outsourcing is that you lose some control over your quality. Even if you code review it’s sometimes difficult to have a contractor come into a team and adapt to their processes and standards quickly enough to be productive. This is usually a good option for organisations that cannot commit to hiring someone full time because they know the increased demand for resource is relatively short-term.

• Accept that you will not hit the deadline. This one is a tough pill to swallow. I think I’ve already explained why this is better than forcing your team to work additional hours, so I won’t repeat myself here.

If your product stakeholders are unwilling to accept any of these solutions then it’s probably a good time to ask yourself what you value more, losing great engineers or hitting an unrealistic deadline.

Stop using overtime as a crutch

Hopefully I’ve put forward a convincing enough argument that overtime is bad for all involved. Organisations, team members and stakeholders all lose out by accepting that overtime is a valid tool for product delivery. Some organisations are even unable to tell when people are working 80+ hour weeks because they’re that bad for productivity.

Just stop and think about your team.