Kyle Nazario

When I first got into software after leaving journalism, I had no idea about software development processes. I don’t want to name names, but some early experiences taught me something valuable.

Unpaid overtime is one of the most dangerous things you can give a manager.

Treat that stuff like a controlled substance. Dole it out in the smallest possible dose, as little as you can. If you do, make sure everyone understands it’s a short-term fix for an acute problem. Above all, do not get your manager used to it.

I’ve seen the damage unpaid overtime causes. It is bad for workers and the company.

Unpaid overtime hurts you

To a certain kind of manager, unpaid overtime makes every problem… disappear.

• Is it hard to pick which feature to build? Make all of them.
• Is it tough to hire and train new people? Have one developer do the job of two (or more!).
• Did the business plan poorly and not make proper user stories ahead of time? Slack a developer mid-sprint. They’ll stay late.

If you have any control over your work environment, avoid doing unpaid overtime at all costs. If it’s too freely given, it becomes the first tool management reaches for. Over time it’ll become the only way anything gets done.

As a developer, you should not want this. Obviously. It will burn you out and hurt your personal life and cause you to do bad work. That bad work will take even more time to fix.

Unpaid overtime hurts your company

It’s self-evident why unpaid overtime is bad for developers. However, it actually hurts your company too, because unpaid overtime lets managers avoid hard choices.

That is deadly to an organization! In a startup, your managers need to be laser-focused on the company’s goals. They need to think, “Okay, we have limited time. What are the three things we absolutely need to get done this sprint?” It forces them to prioritize the essentials and throw away the rest.

Having just 40 hours a week (or less) per person is a wonderful thing for an organization. It makes employees focus on the most critical goals.

Taking away that constraint profoundly hurts a company. I’ve seen it happen. Managers lose the ability to prioritize. Requests from $200-a-month customers get treated equally as those from $20,000-a-month enterprises (why wouldn’t they? So-and-so can stay late). The product doesn’t improve for bug customers who actually pay the bills. The code gets filled with half-grown ideas and vestigial features.

Avoid giving unpaid overtime when you can

I admit my perspective is limited. I’ve only worked at medium to large companies in the United States. Readers from countries with more civilized labor laws are probably horrified at the idea of doing any unpaid overtime at all. Take this advice with a grain of salt.

And look, I get it. Sometimes unpaid overtime is necessary, like at an early-stage startup. Some ideas may be too much work to fit into a 40-hour week. Maybe your startup’s server goes down at midnight and no one else is free. Also, some people are in job situations where they can’t say no to unpaid overtime. If that’s the case, then yeah, I understand.

But.

If you are in a situation where you have a little leverage- if you are in a place where you can say no- then do it. Say no to unpaid overtime unless there is absolutely no other choice. It helps everyone in the long run.