Ask HN: Trying to prevent 24/7 on-call, please help

10 points by webappsecperson ↗ HN
I currently work in product development at a medium sized company where I'm routinely reminded (in paper and in action) that I can be called on to do anything, anytime, for this "24/7 organization".

Is this illegal? Is there any way that I can protect myself from this in future jobs? My official title is front-end and not SRE, but that doesn't seem to matter.

8 comments

[ 2.5 ms ] story [ 26.0 ms ] thread
In action? You mean like, they routinely call you in at any time, 24/7? If that's what you mean, leave.

In development, you get called in sometimes. It happens. At my current job, it's happened once (at 9 PM) in seven years. At previous jobs, it happened more often. I accept it as long as it's rare.

If it's all the time, it means the company is badly run - too much happens in panic mode, not enough by regular operations. That's your cue to find a company run by grownups.

If staff don't push back at PHBs then they have only themselves to blame. Voting with your feet is always an option.
I've heard of e.g. development teams of 10 where over 10 weeks each person is on-call for one week to spread the burden around. I've worked in places where a 24/7 support team would do this kind of thing (again, spreading the burden between their team) so the developers were freed from it. If you literally are on 24/7 call though I really can't think of what you could do about it except renegotiate or leave as that sounds completely unreasonable and unsustainable to me.
So to the legality question, but please understand IANAL, the short answer is no it is not illegal, at least in the US.

Regardless of whether you are a salaried worker or hourly, it is legal as long as you are compensated for the time. Are there limits, sure and they vary based on your exempt status. e.g. a Salaried worker isn't entitled to overtime, unless certain conditions are met or violations present (certain states have some varying rules too). Hourly workers it is actually easier, you are paid OT for hours exceeding your normal FT schedule, in the US that generally assumes 40 hours a week.

In the end, if the company requires it for your position you are on the hook to show up and do the work. There are some state and federal rules, but in general if you are compensated then they can ask you to do whatever. You can vote with your feet and walk, but outside of that there isn't a huge amount you can do to change it other then making sure shit doesn't break.

I ran a 24/7 shop that handled 911 calls and fire/ems dispatching, we started with 2 people (including me) and grew from there. We all shared call duties monthly, splitting it into the smallest increments that made sense. The reality is we all cared and all busted ass to make sure shit didn't break, and when it did we fixed it and took it personally. It wasn't just about the people reporting the issue, it was for our own sanity.

The bottom line is that if you don't like the work, you can always leave and find a job more suited to your expectations. I'm assuming you have discussed the issue with your management. If not, then why not start with that?

I have worked in a role where I was on call at night. Often started work at 4am or working through the night. But I still only worked 50-60 hours a week for a very good salary. The key for me was that communication was open and both ways. I worked for a boss who was technically brilliant and a great salesman too. And the team did share the unscheduled call-out work.

BTW: whey does everybody write 24/7? that's only like 3.429 in whatever units. I think people mean 24x7 which is the total number of hours in a week.

Well, even SREs need to get some quality time, what you're describing is living hell - like a startup environment not a corporate one, where you on call 24/7 but you have either premium salary or a considerable amount of stock options.
How to protect yourself in future jobs: - See if they have devops people or ops people. Pure ops is actually ideal. - Ask them about their process, both the design/development (eg: who makes issues, how is the product designed) and the backend - who supports the customers, how are customer issues fed into the development workflow.

If it's engineers supporting customers and on the spot to fix bugs, that will be a red flag.