Job Opening: Principal Software Engineer - Mob (US, CAN, MX)
Hunter Industries Careers

Overtime in Software Smells Bad

Overtime smells bad

Earlier in my career as a software manager at one of my previous jobs I would get the call from my boss at 3:45 pm... "Chris, go buy sushi for the team its going to be an all nighter." If this was a one time thing this would likely be ok, however it was common and often. The team would regularly have random 14+ hour days pop into their work weeks. The fact that everyone was ok with it and expected it was just odd in my mind but no one seemed to mind or feel like it was abnormal. Reflecting on that time I should have called out a process smell much like we call out code smells today.

Sushi = Overtime

Overtime as a resource

Since then I have run into articles and discussions that propose overtime is a resource to be spent and saved up. Perhaps a better description is that people's morale is that resource. I think this behavior is also a smell. 

Overtime is quite expensive and the gains are not sustainable. It really should be reserved as a method for quickly resolving unexpected production issues. Even if an employee is salaried and the company stands to benefit from this persons extra output the risks involved often go unaddressed. 

The risk of non-essential overtime

Asking employees for overtime is a gamble every time.

For example a salaried employee is asked to work overtime for a non production issue, maybe some feature work. This person is relatively happy in their job and now the manager has asked this person to be away from family, hobbies, or duties in their personal life. This person is now more likely to look for a new job, have family problems at home, and increased stress. For a request that, to some managers, seems like as no-brainer the company is now gambling a lot on this request, increasing the risk for every new similar request made.

When is overtime appropriate?

Like I mention above, overtime is most fitting in a production bug scenario. So for a team that values zero bugs, there should be zero overtime. This results in reduced risk around the employee and an inherent incentive to write quality code. Bugs lead to overtime, so incorporate practices like Mobbing, XanPan, Unit Testing, Continuous Delivery, Continuous Integration, Clean Code, and so on...

Keep your developers happy and the bugs out.

Low to no overtime is how you keep developers happy, bugs out of the codebase, and the stability of delivery consistent.


Post a Comment