Join our startup, we’ll cut your pay by 40%!

Authored by codewithoutrules.com and submitted by itamarst

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.

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.

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.

firefalcon on September 18th, 2017 at 14:29 UTC »

Personal productivity varies. So in our company we have a rule "work as much as you like, usually we expect no less than 30 hours, but it is OK to do 50. Anything beyond these ranges is odd"

UniqueConstraint on September 18th, 2017 at 13:27 UTC »

This perfectly explains the current working environment at IBM. They routinely understaff projects to boost their margins. Partners and Associate Partners get paid bonuses based on their ability to staff projects that meet or exceed their margin goals. Not successful delivery of client projects. No. Profitability. Understaffed projects mean that fewer people are there to do the work which means 70+ hours per week. I left a few years ago after working 100+ hours for 9 straight weeks. And don't DARE criticize the IBM offshore teams for shoddy work. The management layer LOVES them because they're so cheap.

C-TAP on September 18th, 2017 at 12:25 UTC »

“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.”

Huhhhhhh... Euuugghhhhhhh...

P.S. - For the readers, the author of the article is criticizing the company, not putting out one of the dumbest job posts on r/programming ever.