Working “Crunch” Overtime Might Not Help a Team Deliver

The deadline is approaching. Your project is a mess. Your team doesn’t know if delivering on time is going to be possible. Your director has a genius idea. Everyone work overtime with no plan in mind! Have you ever been in such a situation? It’s quite common if you work in IT or software engineer. For some reason, management thinks that everyone working more hours is directly proportional to more productivity.

There’s a problem with that. The common 40 hour workweek was created from evidence-based research. For nearly all professions and activities, the productivity, efficiency, and general output of a worker drops off dramatically after a certain number of hours in a day. It’s easy to simply say, “Work more hours!” It’s a lot more difficult to use a logical approach and discover the root of what’s causing delays in the project.

It’s disheartening when your director or boss says something like, “We signed up for this profession. We knew what to expect when joining this company. Every project has a “crunch” time for people to work overtime. That’s the industry!” I’m sorry, but I don’t buy that reasoning. If projects are consistently late or require “crunch”, then something has been fundamentally wrong with the project planning from the beginning each and every time.

Look, I get it. Really, I do. People want to solve problems. In an engineering profession, people have a genuine interest in producing solutions to problems. Unfortunately, a lot of the solutions attempt to fix the wrong problem. Projects are behind or off track for a lot of reasons, none of which are solved by simply throwing more person-hours at it.

  • The initial product requirements were not well documented
  • The schedule is poorly planned, maintained, or enforced for the life of the project
  • Constant employee turnover due to poor working conditions, culture, or mentoring
  • Little to no documentation of features and development
  • Little to no knowledge transfer between new and outgoing employees
  • Little to no interest from leadership and veterans to mentor employees
  • Little to no enforcement of working standards from leadership and veterans
  • Little to no involvement from the business and users

That’s not even a comprehensive list. That’s just from the top of my end due to personal experience. Ask yourself which of those could even begin to be solved by working overtime during a “crunch” period. If you guessed zero, then you just won a prize. Most of the solutions to the above list can only be solved by changing the culture of the company and hiring people with an express interest in the time-honored tradition of steady, cautious, and logical construction.

Make sure you ask the right questions during your interview: “Is there a lot of employee turnover? Are project standards established and enforced? Do you have good documentation? How do you gather requirements? Is the business involved in your project?” Run quickly if any of these throw up your red flag. You’ll thank me and your sanity.