Join our startup, we’ll cut your pay by 40%!
Have you ever thought to yourself, “I need to get paid far far less than I’m worth?” Me neither. And yet some companies not only pay less, they’re proud of it. Allow me to explain—
I recently encountered a job posting from one such startup. My usual response would be to roll my eyeballs and move on, but this particular posting was so egregious that had I done so I would’ve ended up looking at the back of my skull.
So in an effort to avoid the pain of over-rolled eyeballs, and more importantly to help you avoid the pain of working for this kind of company, let me share the key sentence from the job posting:
“It’s not unusual to see some team members in the office late into the evening; many of us routinely work and study 70+ hours a week.”
In this post I will work through the implications of that sentence. I made sure not to drink anything while writing it, because if I had I’d be spitting my drink out every time I reread that sentence. The short version is that should you join such a company, you’d be working for people who are:
- Exploiting you by massively underpaying you.
- Destroying your productivity.
- Awful at project management.
Cutting your salary by 40%
Let’s start with your salary. The standard workweek in the US is 40 hours a week. If you’re going to be working 70 hours a week that means you’re working 75% more hours than usual. Or, to put it another way, the company is offering to pay you 40% less than market rate for your time.
Instead of hiring more engineers, they’re trying to get their engineers to do far more for the same amount of money. This is exploitation, and there’s no reason you should put up with it.
It’s not that hard to find companies where you can work a normal 40 hour workweek. I’ve done so at the past five companies I’ve worked at, ranging from tiny startups to Google. Sometimes you need to push back, it’s true, but it’s certainly possible. And even if you can’t find such a job, there are many more companies where you can work 45 hours, or 50 hours. Even an awful workweek of 60 hours is better than 70.
When programming is your hobby
Now, it may be that you love programming so much that you’re thinking, “I’d be coding 70 hours a week anyway, why not do it at work?” As I’ll mention below, I don’t think working 70 hours a week is going to produce much, but even if it did you still shouldn’t do it on your employer’s behalf.
Let’s imagine you’re coding 70 hours a week. You could work 70 hours for your employer, getting paid nothing extra for your time, or you could stick to 40 hours and use those remaining 30 hours to:
- Work on a personal project, just for fun: you could learn new skills that you choose, or build something frivolous because you enjoy it.
- Work on an open source project, helping others as well.
- Take on consulting work, getting paid more.
- Start your own startup, so you get a more significant upside from success.
And you’d also have some optional slack time, which is useful when life gets in the way of programming.
“Work not just smart, but also hard”
Encouraging 70 hour workweeks is an extraordinary level of exploitation, but sadly it’s also a rather common form of stupidity. The problem is encapsulated in another statement from the job posting:
“[We] work not just smart, but also hard.”
If your starting point is exploitation, if you’re setting out to extract as much work as possible from your employees, you lose sight of the purpose of work. Work has no inherent value: what matters is the results. The problems solved, the value created, this is what you’re trying to maximize.
And is turns out there’s decades of research showing that consistently working more than 40 hours a week results in less output. But presumably the people running this startup don’t believe that, or they wouldn’t be pushing for it. And maybe you don’t believe that either. But even if we assume 70 hours of work produce 75% more output than 40 hours of work, it’s still a fundamentally bad idea for the company.
When an organization tries to maximize inputs, rather than outputs, the result is a whole series of bad judgments. Hiring, for example, as you can see from this job ad. A junior programmer working 70 hours a week will produce far less valuable output than an experienced programmer working 40 hours a week. But a company that wants to maximize exploitation, to maximize work, will write job ads that ensure the latter will never apply.
Emergencies: when long hours are necessary.
Beyond reduced output, and beyond a confused hiring policy, encouraging long hours also implies a lack of project management skills. Long work hours are both a cause and a symptom of this particular failure.
70 hours a week means 7 days a week, from 9AM to 7PM. That doesn’t leave much slack time for life, and it also leaves no slack time for the project. Sooner or later every project has an emergency. If a production server crashes, someone is going to have to bring it back up. And more broadly, extra work comes up: a customer asks for more features, or a seemingly simple task turns out to be far more difficult than expected.
To help deal with these situations you need some advance planning. Scheduling everything down to the minute won’t help, and pushing everyone to work at the absolute limit won’t help. The problem is unexpected work, after all. What you need is planned slack time, time that hasn’t been budgeted, that’s available for all the inevitable unexpected problems.
But a manager that is pushing you to work 70 hours a week isn’t a manager who plans ahead for unexpected work. No, this is a manager who solves problem by telling you to work harder and longer. So when the unexpected happens, when an emergency happens, your manager will be saying “who coulda knowed? ¯\_(ツ)_/¯” and before you know it you’re working 80 hours a week.
Maybe that will fix things. But I doubt it. More plausibly you’ll eventually burn out and quit, taking your business knowledge with you.
“Strong willingness to help junior engineers”
The job posting that led to this post also suggested that a “strong willingness to help junior engineers” would be helpful, though not required. So here’s my advice to all you junior engineers out there: avoid companies that want you to work crazy hours.
- It’s bad for you.
- It’s bad for the company.
- And you don’t want to work for a manager who isn’t competent enough to realize what’s bad for the company.
And if you are stuck working for such a company, you might want to read my book, The Programmer’s Guide to a Sane Workweek.