Long ago, I worked in a shop that I feel did it the right way: allow techs to sign up for pager duty a week at a time, and each week would pay a bonus of a few hundred bucks. It was always voluntary, and people were eager to take as many shifts as they could sign up for. We'd round-robin it between all the people who wanted it. If your plans changed, there was always someone happy to pick up an extra bonus on short notice.

Let's go over that again: People liked being on pager duty, and all it took was a few hundred bucks a week.

Of course, this was in a pretty competent company. The pager would only go off a couple times a week, it was usually easy to fix, and there was a well-documented escalation path if you couldn't handle it on your own. So we weren't losing sleep.

If the pager started being painful, fewer people would sign up, giving a signal to management that there was a problem. They could then either increase the bonus, or fix the root problems.

I have no idea why other places don't handle it this way. It worked well for everyone involved.

Germany has laws around this. A German coworker of mine gets almost $800/week that he is on call.

Do you have paragraphs at hand to share? I would like to see if company I work for is compliant with those laws

Courts ruled that when you are on-call, they have to pay at least minimum wage for every hour you are on-call. Additionally, you get tax benefits for working night and Sunday, which your employer has to declare.

That's why you earn so much more during on-call in Germany

That depends on the exact arrangements of your oncall duties. Typical developer oncall where you can be wherever you want as long as you can reach your laptop with an internet connection within x minutes does not fall under these laws.

No, it does. Because whenever you have to be "ready" for work, it counts as work.

>Bereitschaftsdienst Beschäftigte im Bereitschaftsdienst halten sich in der Regel im Unternehmen oder in unmittelbarer Nähe auf, damit sie die Arbeit bei Bedarf sofort bzw. zumindest zeitnah aufnehmen können. Ein typisches Beispiel sind Feuerwehrangestellte, die auf der Wache die Nacht verbringen, aber dort schlafen können. Bereitschaftsdienst gilt in vollem Umfang als Arbeitszeit und muss daher bei der täglichen und wöchentlichen Arbeitszeit voll berücksichtigt werden. Die Vergütung des Bereitschaftsdienstes richtet sich nach dem jeweiligen Arbeitsvertrag, beziehungsweise gültigem Tarifvertrag oder Betriebs/Dienstvereinbarung.

>Arbeitsbereitschaft Bei der Arbeitsbereitschaft sind die betreffenden Beschäftigten im Zustand „wacher Achtsamkeit im Zustande der Entspannung“ am Arbeitsplatz anwesend. Sie sind jederzeit einsatzbereit. Ein Beispiel könnte eine Beschäftigte in einem Elektrizitätswerk sein, die beim Piepsen eines Überwachungsmonitors sofort aktiv werden muss, über längere Phasen aber keine Aufgaben zu erledigen hat. Arbeitsbereitschaft ist Arbeitszeit und muss im vollen Umfang auf die tägliche und wöchentliche Arbeitszeit angerechnet werden.

>Die Vergütung richtet sich auch hier nach dem jeweiligen Arbeitsvertrag, beziehungsweise gültigem Tarifvertrag oder Betriebs/Dienstvereinbarung.

To add to this: If your boss calls you when you are on vacation, you get that full vacation day back. If your boss asks you to be ready in case he might call during your vacation, you also get those vacation days back.

The law distinguishes between Bereitschaftsdienst and Rufbereitschaft. The latter does not count as working hours and is defined by being able to freely choose where you are and what you do during that time (until you get paged of course). That fits the typical developer oncall where you don't have to be on site or close by during your oncall shift.

> is defined by being able to freely choose where you are and what you do during that time

So… not being able to: go on a long run without the phone, go watch a movie, have a big nap, go on a hike without a laptop on you.

Doesn’t sound free to me. My last on call wasn’t bad. But I still didn’t like being bound to my laptop and phone.

If your employer chooses Rufbereitschaft as their on-call mode, then that means it all adds to your working time, and you can't exceed 10hours a day. Having a 2hour incident means no more overtime allowed. Additionally, they need to clock your work during each incident. Lastly, if you have an incident outside of working hours, you are not allowed to pick up work again for another 11 hours, unless it's another incident.

I think if most shops after some incremental bonus for overnight on-call, just nobody would sign up. Salaries are high enough without it.

On-call is just fine as long as:

1. There is a rotation.

2. There are few pages, preferably the median should be 0 per week.

3. Spurious / non-actionable alerts get fixed right away (with very high priority)

4. You're not up more than 1 week per 1-1.5 month.

5. You subtract middle of the night pages from your next working day, with bad nights resulting in a day off. Being on-call doesn't mean working overtime.

6. It's either opt-in or stated as a requirement on interview.

Nobody should be coerced into on-call within a role that did not explicitly require it on joining.

I've upvoted you, but I disagree. Extra work should mean extra pay. Even just having to be ready to work should result in extra pay. You are providing a benefit to the company, and they should compensate you appropriately.

Rolling it into the contract isn't appropriate because anything that is "free" will get abused, eventually. Even if it's fine right now, it won't be eventually. And there's no way to stipulate that the "median should be 0 per week" in the contract, so that'll go out the window as soon as the company needs it to.

I upvoted you because it's obvious you've thought about a lot of the problems with this and I feel you're on the right track. You just didn't go far enough.

> On-call is a way for bad businesses to steal money from their workers by expecting them to work 24/7 without paying them 4.2x their salary.

This is not entirely true. I think the fact that companies don't have to hire separate support/SRE staff is priced into the exorbitant salaries that devs are paid these days. When I started my career around a decade back, there used to be at least 2-3 levels of escalation engineers/support staff between the customer and the developer. Today it's usually zero, and part of those salaries paid to dev instead.

I may be in the minority, but frankly, I'll easily take a pay cut not to have to go through the on-call sh*t every few weeks.

How many developers actually have exorbitant salaries?

Is 54k for 60 hours per week considered exorbitant 10 years ago? Because that’s how much I was paid while being expected to be available 24/7. My cheap apartment was a 3rd of my pay. I was fortunate to have no debt and get a car from my parents.

I was up to 90k about five years later. Which is decent in the Midwest but I wouldn’t consider it exorbitant.

I doubt I’ll see anything near $200k for a long time. By then, it’ll be less than 90k considering inflation.

Show me where that's spelled out in anyone's employment posting or negotiated by any sort of employee rep. It's clearly a grab back by employers trying to save a dime and being stupid about the long term effects.

Uh? My data points are in operations, not dev, and are from working in Europe, so that may be an entirely different reality, but I've always been paid for being on call, plus for every time I was actually called and had to work - either remotely or on-prem, depending on what broke and what access was possible.

My manager once realized that I was sometimes even called by the other oncall engineers if they were stumped, and retroactively compensated me for a "2nd level oncall".

Not even once have I ever felt exploited - it was always sufficiently flexible for my personal life, usually 1 week/month, and always reasonably compensated.

On-call is a stop-gap for when you don't yet have a fully staffed 24/7 SRE team yet, and you need to be pretty big before you can afford something like that. Plus your software needs a big round of professionalization, because it shouldn't break overnight.

I believe the SRE book mentions this; if you want your software to go from on-call engineers to being managed by SRE's, your software needs to be stable, have certain logging requirements, documentation, etc. And, if it breaks more than X times in a row, or causes an SRE to be paged too many times, the pager will be handed back - fix your shit.

That may be the idea, but in practice, companies don't even hire SREs and just have engineers do on-call rotations instead.

My previous employer tried to offer me a "promotion" that among much more accountability for systems also included being on-call. There were no clearly defined parameters, and the real kicker was that this glorious promotion included a $0 pay rise.

They were flabbergasted when I declined, and tried for weeks to get me to accept with "It will be good for your career", etc.

That is a VERY hard no from me.

This take that on-call must require you to be compensated at 100% of your normal pay is rediculous. If I got paid 50% of my salary to be on call (noting that I get paid OT if I actually work) I would consider myself to be robbing the company blind.

The idea there is no middle ground, with

This varies a lot by pages per shift. If you get paged less than once per shift on average, it would be a worse outcome for everyone if you shifted to follow the sun. If you get paged 70 times per shift, yes, that needs some rethinking. The trick is how to move from 70 per shift to less than 1 per shift. I am not sure your approach would lead to that outcome.

Being on call -at-all- just ruins your ability to go socialize. 70 is that same as 1.

How so?

Want to meet with somebody: take your laptop with you in a backpack. Just make sure you have mobile connectivity wherever you're going.

Want to party: just ask somebody to take over the pager for the evening.

If you have <=1 page per rotation, then it's really not annoying.

Where I work it seems quite decent. There's 24/7 operations staff and other overnight staff to handle minor issues. If there's anything that is affecting the site that would get us in legal trouble without a fix or is losing a lot of money, then people will get called out.

The rotation is like a week every 2 months. You get paid a substantial amount extra for that week, and you get paid on top of that if you get a call out. Even if it takes you 10 minutes to resolve or there's no issue, you get paid a minimum of a few hours at 2x pay.

It's insane to me that there's places with multiple call outs a day and people don't get paid extra.

For me, being on call is pay rise for the week. It just means I can't venture too far away from home without my laptop. It's so rare to get called out.

Thats amazing. During my corporate career, the places I worked had no additional pay for getting call outs. Would have loved some extra cash back then (was unmarried - happy to do extra hours)

on-call is brutal, i basically agree with you except on the last point; i think people should be allowed to decide for themselves if they want to do it assuming they are paid handsomely

That doesn’t work. It results in emotional blackmail “don’t be the person letting the team down by refusing to be on call”, “share the burden with your team”, “everyone else has no problems going on call”, “I got a call out on my kids birthday in the park at a party, here’s a photo of me sat in the corner on a laptop, it wasn’t so bad”, “take one for the team, we give you free softdrinks and deli bar”

Y’all need to reevaluate who you’re giving your time to, these reactions are clearly the result of some serious trauma that’s got nothing to do with the concept of being “on call”…

orgs that have on-call engineers that aren't part of the operations and infrastructure come with all the other associated management and strategy problems; seeing how effective orgs work, how they test, how they release, how they manage faults, how they grow and what instruments and strategy are successful is so simple and straightforward it's mind blowing the general pattern of on-call exists; until you see the people making those decisions then the strangeness becomes how did that person end up in their decision making role given how inconceivably misguided all their strategic comments becomes. I once asked the head of engineering how to get teams to work together and he didn't have an answer--and he also had on-call. It's really strange working in technology, you'd think there were actually intelligent people leading this space. Instead it's more a simile to religion, politics.

Unless you own the service in isolation, chances are something will break at some point beyond your control. If you own the service in isolation, then you may be on-call 24/7 indefinitely.

I build high scale systems for a living, but I also hike, ski, and have a family. I can't guarantee 20 minute response times 24/7 365 days per year. I generally won't join a team with an on-call more frequent than once per 6 weeks.

Anecdotally, companies fall into a trap where individual engineer's own services that they must be paged for. These engineers don't get the time to make the service reliable, and they also don't want to admit that the service is a tire fire. This works for the company as long as they can continuously pull in new engineers to feed the on-call fire.

> Anecdotally, companies fall into a trap where individual engineer's own services that they must be paged for. These engineers don't get the time to make the service reliable

I think that’s where I’d draw the line if I was in such a situation. If I’m on the hook for dealing with any outages, then I won’t be working on anything else until the service is reliable.

There really is no end to this though, a service can always be made more robust. The reputational damage of missing a page is extremely high. The risk to the company of missing a page can be high (although hopefully not to high if its a solo engineer project).

People need breaks.

> a service can always be made more robust

It can, but I don't think it's too hard to make it robust enough that pages become a rare occurrence. At my company (a small startup with <5 developers - so we're not exactly flush with development capacity) we've managed to reduce outages in a previously quite buggy app to almost nothing over about 18 months (while also developing new features). I don't think we've had an outage in the last year which wasn't due to either:

- An outage at our underling hosting provider (which we can't do anything about anyway)

- A code deploy (which we can plan and control the timing of)