15 ms·

Oncall Compensation for Software Engineers

• JJMcJ 4y ago
  There are companies that offer zero compensation for oncall, expect a full week's work during oncall rotation, and expect the oncall developer to maintain normal work hours. Obviously bad places to work, but there are many of them.
• yewenjie 4y ago
  Why is part 1 of this article paywalled and not this?
• teeray 4y ago
  Keep the extra cash for on-call. If I wanted to trade my nights and weekends for more money (and weren’t contractually forbidden from it), I would moonlight. I really want a delayed start for any night incidents to catch up on sleep, and extra vacation.
• dvtrn 4y ago
  Some companies hire dedicated tech people whose only job is to be oncall, handle alerts, and improve the oncall infrastructure. This role is called ‘DevOps Engineer’ at some companies, SRE (Site Reliability Engineer) at others, and may also be called ‘Operations Engineer.’ Someone finally said the quiet part out loud about ‘Devops Engineer’ as a job title. Only a matter of time before we wise up about SRE as well, I suppose.
  • no_wizard 4y ago
    If I understand you correctly you mean that they are really Operations Engineers right?
    • dvtrn 4y ago
      I don’t know anymore, and honestly I don’t care anymore. If the job wants to call me an SRE fine, if they want to call me Devops, sure. I’m more focused nowadays on “what problems are you hiring me to solve?” since it feels more and more like the Venn diagram of the three job titles has nearly completely coalesced into a perfect circle. Difference for me is I’m scrutinizing far more intentionally in job interviews about why an org is hiring for SRE/Devops before accepting any offers. Too often orgs are hiring for this talent and turning them into kitchen sinks for anything and everything the SWEs aren’t doing. Compliance? Send to Devops. Upcoming audit and need a pen test done in 3 days? Send to Devops. Did a bad job prioritizing bug fixes and now shits crashing? Devops. Etc. once you go through that a few times you start to figure out the right questions to ask in an interview and figure out if you’re about to join a company with Devops practitioners or pretenders.
      • scottyah 4y ago
        I’ve experienced similar. What are some of the questions you ask?
        • dvtrn 4y ago
          Take what works you, ignore what doesn't, good luck. - Why are you hiring Devops/SRE? - What is a Devops/SRE going to bring that isn't/can't being done by engineers presently? - Why isn't it being done presently? What have you tried so far? - How many other SREs/Devops do you have? When will I get to interview with them (if applicable) - Who is responsible for platform? Infrastructure? Deployments? How are they involved? When are they involved? etc. As mentioned in my last comment, a lot of it comes through the baptism of working at a lot of really crummy shops to know the kind of bullshit you don't want to put up with. You gotta deal with some of it no matter where you go, but you sure ain't gotta deal with it all. This is a lot of boilerplate stuff, sometimes you're lucky and these questions get answered before you can ask them, sometimes they're in the job description. So let me talk about that for a minute. You really want to take your interviewing to the next step? Learn how to inquisitively, but tactfully challenge what you're reading in job descriptions. The answers I've gotten have been far more revealing than "what will I be doing day to day?" if you ask for more details about a bullet point or two and why those bullet points matter, or who they matter to. That includes, yep, on-call. Most of my other questions are very probing questions about things in the job description; not necessarily because I'm looking for a specific answer, I want to see how the hiring managers and others describe those topics. Can they actually talk about why they're looking for someone to do x, y and z? Can they have a meaningful dialogue about what those responsibilities mean for the team or are they just parroting back what the job description says, like someone in a zoom call just reading words off a powerpoint slide? Here's an example: Job says they want a Devops to come in and also be responsible for security, risk and compliance in the infrastructure? Okay, here's my counter-inquiry about that: if Devops has the responsibility for security, risk and compliance, talk to me about the authority Devops has to recommend or deny certain actions in the platform if it is assessed to be too risky or costly to maintain a compliant and secure posture were we to do it anyway (if you've ever been in that unenviable position, you probably know exactly what I'm getting at with this question). Interviews are two way streets, and in my thirties with a family where "family time" has no fungible cost, I'm driving very defensively on my side of the street.
    • wpietri 4y ago
      That's certainly what I've seen! I think the DevOps paradigm was a possible revolution in how we worked. But pretty quickly a lot of places just slapped the new label on the old sour wine.
  • notesinthefield 4y ago
    And suddenly I understand why the worst tech job ive ever had as an Ops engineer was so bad. We really only existed to improve alerting, pipeline and wake up other engineers at 3am.
    • dilyevsky 4y ago
      Majority of companies i talk to are really poorly run wrt to software operations. Case in point - misusing devops term to mean sysadmins/operators
    • lmarcos 4y ago
      A sincere thanks. As a software engineer I couldn't care less about what happens to my company's services/products outside the 9-5 time range. Don't get me wrong, I give myself 100% at my job, keep myself educated regularly and I'm rather on the "boring and stable stuff" side of things (instead of the "shiny/trendy and unstable" side). I have commitments outside work and no amount of money is going to make me give more than the (already exhausting) 40h/week my contract states. The "you build it, you run it" may work for people on their 20s (they usually are excited to earn "easy money" by being oncall). For people on their 30s and above the extra oncall money is not worth at all.
      • wpietri 4y ago
        I certainly believe that's true for you. But in the case where engineers choose not to ever run what they build, how do you reconnect the feedback loop? Put differently, I think one of the ways somebody goes from the "shiny/trendy and unstable" side to the "boring and stable stuff" side is by experiencing the operational pain of their choices. If the pain falls on others, will they still learn? Of course, the way you talk about your job makes me wonder if you are already experiencing so many systemic/managerial issues that there the feedback loops are already pretty broken, so this one may not make a ton of practical difference.
        • trombone5000 4y ago
          Engineers can run what they build during normal working hours. Oncall is a scourge not because of the experience of technical problems, but because people already working full time have to arrange their lives outside of work around a second "oncall job". A job which occurs after hours, one out of every X weeks. A dedicated, pure "Ops" night shift (perhaps in another time zone) would be more humane.
  • dijit 4y ago
    Sysadmins. Those people are sysadmins. I don’t know why we need to have a job title treadmill for this; I hate not knowing what your definition of “devops” or “SRE” is when interviewing. (Both as a person who interviews others and is interviewed by others). Before anyone says it: Sysadmins could code (not to the same level as feature folk), shitty operators pretending to be sysadmins couldn’t.
    • BurritoAlPastor 4y ago
      We didn’t make software engineer money when we didn’t have “engineer” in our titles. I would be perfectly happy to be a “senior systems administrator” or similar if it didn’t impact my earnings potential.
      • dijit 4y ago
        That’s not my experience. The feature folks used to come to sysadmin because the money was better.
      • analog31 4y ago
        Oddly enough traditional engineers (electrical, mechanical, etc.) don't make software engineering money.
    • Aperocky 4y ago
      So.. what do you call feature folks that also do sysadmin work?
      • LegitShady 4y ago
        Underpaid?
      • Jach 4y ago
        Amazon-style full-ownership software engineer teams?
        • babyshake 4y ago
  • babyshake 4y ago
    No you have it all wrong. Regular mid-level software engineers need to have expertise in dozens of different deep subject matter areas, but they get a "flexible" vacation policy and a $50 monthly gym stipend so they're actually getting a pretty sweet deal.
  • kodah 4y ago
    I disagree. DevOps Engineer, as much as I hate that title, is really a sysadmin who can do orchestration code (like ansible or terraform). They're not supposed to be responsible for any application code. In a lot of ways they're more like systems integrators these days, but most of them carry some pretty fine OS and distributed system chops. SRE-SE and SRE-SWE's are responsible for application code and often embed on application teams to bolster either code or system performance or both. Please do not take companies bastardizing these practices as truth to what they are. There are companies who do this right and we should champion them above the garbage.
• Lukas_Skywalker 4y ago
  In chapter 3, the table labelled as „Companies paying 600-1,000 USD/EUR/GBP per week.“ includes German KfW Bank which apparently pays €875 per _day_. Is this a typo (they are in reality paying this amount per week) or are the engineers on call only one day per week (making the amounts per day and per week the same)?
  • ju-st 4y ago
    It is probably 875€/week normal salary for an IT operations job at a German bank.
• deleted 4y ago
  [deleted]
• wpietri 4y ago
  I feel weirdly split on this. With my founder/leader hat on and thinking about my own on-call time, I think of myself as always on call. I also think it's my job to make it so that on-call incidents are very rare. But when I think about arbitrary companies and people having regular jobs, I think that of course people should be compensated. It's labor and we pay people for that. And especially when it's more than just a few people, having on-call time and incidents be uncompensated means a broken feedback loop. The company should have strong incentives to make sure that on-call people don't suffer for the sloppiness of others. Part of that is small vs big, or startup vs established. But there's some part of me that seems too reluctant to insist on proper compensation for my own on-call time. Clearly something I need to chew on before I next take a job at someplace larger than a few people.
  • WFHRenaissance 4y ago
    My thinking is that if you're giving someone equity in a company, they have a market incentive to ensure that the product and company succeed. This extends to on-call. Handcuffs.
    • almost_usual 4y ago
      As someone who has played this game the equity is probably worthless unless it’s a public company. I’ll grind for hundreds of thousands annually in RSUs, nothing less.
• WFHRenaissance 4y ago
  I actually love being on-call, especially as a part of a "you build it, you run it" kind of team. You essentially get a week to find bugs, fortify the application, and make it so that the next person has an easier on-call. If everyone goes into it with this mindset, eventually on-call becomes a quasi-freebie week where you can either work on "fun stuff", or it becomes invisible. Not to mention that no product can survive without love and support from its devs.
  • mehphp 4y ago
    I don’t understand, is on-call not in addition to your normal duties where you work? I don’t understand how it could tuen into extra time to work on fun stuff.
    • dilyevsky 4y ago
      On well run teams I’ve been a part of it was always understood that you’re not getting much done on your main projects while being primary oncall
      • mehphp 4y ago
        Interesting, I’ve never been somewhere where on call entailed more than maybe an incident or two to handle during the week. I can only recall a single instance that interfered with my current sprint. From the replies, it sounds like a lot of places have constant fires to be put out by those on call? That doesn’t sound “well run” to me…
        • dilyevsky 4y ago
          Imo oncall engineer should seize the opportunity and fix that warning alert that’s been firing for ages before it becomes an active fire. So consequently there’s usually no lack of things to do even if no fires occured
          • mehphp 4y ago
• deeptote 4y ago
  This is why I started my own contracting/consulting company, I hate on call and it always gets abused. I mean, really, what's going to happen if you can't see the score of a baseball game until tomorrow?
  • happyopossum 4y ago
    > I mean, really, what's going to happen if you can't see the score of a baseball game until tomorrow? Well, nothing. Unless you’re MLB.com and have tens of millions of people paying you >$100/yr to have that information readily available. If that’s the case, you’re issuing credits (which is a huge time and money sink) and losing customers.
    • geraldwhen 4y ago
      Then maybe they should pay people to be ready to fix bugs 24/7. They won’t. No one will. They want their salaried employees to also be firefighters and the premise is absurd. I don’t take calls at night; you cannot reach me. What are they gonna do, fire me? Good joke. I run interviews and staffing someone who knows their left hand from their right is nearly impossible. Leverage works wonders.
  • tyingq 4y ago
    Bookies might care :)
  • lrvick 4y ago
    Having been on call as a sysadmin for several companies over 15+ years, starting my own company was mainly so no one can ever demand I do this again.
  • askafriend 4y ago
    > This is why I started my own contracting/consulting company, I hate on call and it always gets abused. Hate to break it to you, but starting your own contracting/consulting company means you are forever on-call. It just so happens that it's not called that explicitly, and the people you have to answer to are your customers (aka your bosses).
• cnj 4y ago
  In my experience, a week-long rotation is much more grueling than a daily rotation. Having to stay home for a single evening/night has much less impact for me than having to do it for a whole week. Additionally, the impact on personal live of being Oncall on the weekend is bigger. At commercetools, we recognize this by paying more for an Oncall day on the weekend (200 EUR on Fri/Sat/Sun) vs. a day during the week (150 EUR).
• falcolas 4y ago
  FWIW, the magic HR word is “accommodation”. Neither your managers or HR themselves will tell you this magical word. And you’ll want to have a psychiatrist to back you up. Being on call is super stressful, and if it’s causing burnout, you don’t need to keep doing it. Does this increase the burden on your teammates? Yes. But so would you burning out.
  • matheusmoreira 4y ago
    > Being on call is super stressful Absolutely. Being on call means we have to be ready to respond. Can't ever fully relax, can't make plans that compromise that readiness. People need to be compensated for that. Where I live doctors get paid when they're on call.
    • azornathogron 4y ago
      You need to be ready, yes. Being unable to relax is IMHO more of a function of how well/poorly managed your systems are and your own level of experience and psychological profile.
  • babyshake 4y ago
    As in, "I have a health issue that requires the reasonable accommodation of only working 9-5 hours, here is a doctor's note."? Is it really that simple?
    • falcolas 4y ago
      Yes. Reasonable accomodations for physical issues are mandated by the ADA, and recently they have started applying it to mental issues as well. Its worth going through; the worst that can happen is they say no (or, admittedly, fabricate a reason to fire you), but you’ll know where you stand.
  • muttled 4y ago
    At my last job (horrible MSP), we would get 1-3 calls per night. Not evening. At night. They had no reason to improve the situation as they charged extra for those calls making them very profitable. They would bill the client minimum time while only paying us for exact minutes worked. I definitely debated getting a doctor's note saying that my health was impacted by being woken up multiple times a night while still required to show up the next day at 7-8 AM.
• 64StarFox64 4y ago
  I just joined a company that does formal but unpaid oncall, coming from a prior co that had implicit oncall. I'm very much in the "if you built it, you run it" camp. This said, I think: - if oncall is a part of the gig, you compensate _somehow_ (demonstrably above market salaries, explicit extra pay, time in lieu, etc); oncall culture (or the lack thereof) should be explicitly mentioned in any hiring process and employment contracts - the team should be striving for 8 or more engineers in the steady state; temporary vacancies should be temporary - primary should be handling 80+% of pages in the steady state; if this is not the case on average across the team, you are not building enough resiliency into your oncall culture, or relevant tech debt should be high priority - relatedly, kpis/incentives should be structured such that as call gets worse, progressively more immediate investments are made to address technical root causes (a la SRE error budget) I'm tinkering with that last one my head. It's easy to say, hard to execute
• cbarrick 4y ago
  Google's oncall compensation structure is phenomenal. For tier 1 oncall (5m response time), for each hour oncall outside of working hours, you are compensated for 40 minutes, which you can either take as time off or at your current pay rate (i.e. you are compensated at 2/3 your usual pay). For tier 2 oncall (30m response time), the compensation is 20 minutes per hour outside of working hours. For a tier 1 rotation, the team has a staffing requirement of 12 people, split between two sites. There's a max of 80h oncall, outside of working hours, per person per quarter. Because oncall is split between sites, you are never oncall overnight.
  • nighthawk454 4y ago
    Better than Amazon, where you get nothing extra. And often do regular duties during on call as well. Kind of nuts. The saving grace is a lot of teams aren’t really doing anything that critical, so the on call is more a formality bc that’s what real teams do. Still pointlessly stressful but less serious.
    • deleted 4y ago
      [deleted]
    • 52358 4y ago
      Meta is the same, it can suck. I was on a team that got down to 4 eng once and everyone was oncall for a week each month.
      • leaflets2 4y ago
        How were you compensated if I can ask?
        • science4sail 4y ago
          Meta doesn't have any oncall compensation; it's like Amazon.
          • 4y ago
• dboreham 4y ago
  Quick note that as an employer you may be subject to local employment laws in this space. Particularly true in the US.
• cletus 4y ago
  Facebook's oncall compensation is really simple: it's zero. Having also worked at Google, I found this situation ridiculous. Facebook treats oncall as something you're just expected to do on top of everything else you're meant to do. So if you have 50 alerts fire, 40 tasks create, 5 UBNs (UBN = Unblock Now, which should be responded to immediatley and will probably be a SEV) and 3 SEVs, well you just have to do all that and your job. Google oncalls (IME) tended to be fairly light. You'd often do releases too but there tended to be a lot of automated processes around this (ie building binaries, packaging MPMs, release to staging, release to canary, regression detection, push to production). Facebook's releases (other than Web) were (again, IME) a dumpster fire. Web was a special case because of continuous push. Push a commit and automated processes would build the (very large) www binary and handle the push to C1/C2/C3 (these are sort of analogous to internal testing, canary aka 1% and prod). Automated processes would verify a commit by deciding what tests to run. This wasn't explicit and would miss relevant tests for various reasons. This could (and often did) break trunk. This could back up pushes for hours. First thing in the morning it may take as little as 2 hours to push to prod. Later in the day it might take 8+ hours. Facebook works around this by using conditional code, like... a lot, meaning certain code would only run if you're in right set of GKs (gatekeepers) and QEs (quick experiments). Behaviour would be flipped on by a separate GK/QE push, which is much quicker. But this means when something of yours breaks (which it often does) you have no idea why. Is it a bad code push? A bad GK/QE push? By you? Or some infra you depend on? I mention this because you had to deal with this sort of thing oncall a lot. The problem with not giving oncall compensation is that the burden is never shared equally. The person or persons who do more than their fair share are never going to do it for the money because it is annoying but at least the money is some form of recogniation or, dare I say it, compensation. Disclaimer: Xoogler, Ex-Facebooker.
  • deleted 4y ago
    [deleted]
  • boruto 4y ago
    I wonder how it works in Europe where the expectation is that you are compensated
• michaelt 4y ago
  This article is missing the single most important question about being on call: how often you get called. It's one thing to be on call where you get called 2-3 times a year, because you're working on a quality system where bugs get fixed more often than they get introduced. Then the pay, if any, is mostly compensation for hurting your social life. It's another to be on call where you get called 2-3 times a week, because the organisation has decided calling you is cheaper than fixing the underlying problems. In that case, the compensation better be worth messing up your sleep cycle and upsetting your partner.
  • leetcrew 4y ago
    disagree. I need to get paged a lot before it becomes more impactful than planning an entire week around an engagement SLA.
    • ironmagma 4y ago
      So that's your personality. What about the rest?
  • GauntletWizard 4y ago
    Google had fantastic software quality and still had SRE teams expecting to be paged twice a week. They had that because they had tremendous software quality; they paged well before there was impact that users would care about, and proactively spent time fixing their problems. Being paged, usually during daylight hours, allowed good bugs to be filed.
    • Morgawr 4y ago
      What a lot of people (even some working in devops) don't get is that pages/SLA metrics are a "budget". If you never get paged and your system never goes "down" (down = you need to fix something, not necessarily down for the user), it means that you're doing something wrong. Obviously you don't want to overdo it, but if you have an oncall rotation for a service that never pages or pages so rarely, you're wasting human and engineering resources. If that's the case, you need to reconsider if you need a devops/SRE team in the first place, if you need an oncall rotation, or maybe if you need to be more proactive in implementing/releasing/deploying new features as long as you stay within SLO budget. We've had weeks and months where we just looked at our graphs and uptime budget and go "our systems are getting worse, we need to slow down releasing and tighten up the automation", and we've also had months where our load was so light that we'd consider doing large migrations or more daring experiments (for our devs) because those also improve our service and our users' experience.
• morelisp 4y ago
  This data is presented in a really frustrating way. First, I suspect (but I'm not certain) most companies do it as X% of salary. So I have no idea if I'm looking at truly different on-call policies or rather salary spreads. Second, there's no associated estimation of how much work "being on-call" is. For us, a small team with SWEs doing voluntary on-call, any out-of-hours page is immediately top priority for work the next day. The person on-call also gets the final say over risky deployments after lunch / on Friday. I know that's not universally true, and we've worked with companies that consider a page a week or even more normal (still without a separate SRE/OpsEng team). If any of us was getting paged once a week, we'd refuse.
  • ipsi 4y ago
    Well, Google is explicitly listed (about halfway down) as paying a percentage, and they're the only ones that are. In my (very limited) experience, it's generally been a flat rate regardless of salary, so I'd go the other way and believe that the majority do, indeed, do that. Your second point is definitely a major concern, though - the author talks about it (calling out Amazon and Twilio as particularly bad), but doesn't provide any sort of hard data on what the workload is like, possibly because it varies heavily even between teams or groups within the same company.
    • morelisp 4y ago
      I know the rate for three other German companies are are percentages. I think time and a half for “activation” is relatively common. I’m less sure about inactive time.
• almog 4y ago
  Do Amazon and Meta get away with zero oncall compensation policy even in Western European countries?
• anon22334556 4y ago
• anon22334556 4y ago
  At USAA they pay $70 a week for on call. If you’re on call till 2am? Still gotta be in on time. At least when I was there
• kodah 4y ago
  > Some companies hire dedicated tech people whose only job is to be oncall, handle alerts, and improve the oncall infrastructure. This role is called ‘DevOps Engineer’ at some companies, SRE (Site Reliability Engineer) at others, and may also be called ‘Operations Engineer.’ I really wish this wasn't stated so matter-of-factly. Neither of these is actually supposed to be true. A lot of times on-call gets stuck on these folks because they're often treated as second class citizens in the softwarescape. There is really great structure for doing these roles right that doesn't involve them making them full time on-call.
  • steelegbr 4y ago
    > A lot of times on-call gets stuck on these folks because they're often treated as second class citizens in the softwarescape. Sadly spot on. For anyone that’s not been the ops side of the fence, you are expected to do major works out of hours as it’ll impact developer productivity. You can also lose your public holidays, weekends and evenings to issues while others get to switch their phone off and forget about work until they return. It does a real number on you. Glad to be fully on the dev side of the spectrum now but some of the attitudes of interviewers I had to endure to get there… And that was with a CS degree and a truckload of IaC/glue-ware experience!
• rb2k_ 4y ago
  One thing that this article is also kinda missing is the base compensation. Some companies (e.g. FB) are in the top 90th percentile or so of the industry but then don't pay on-call compensation.. But that means that in one case you make 200k base, have an on-call and don't get any extra on-call money. In the other case you make 140k base, have an on-call and get 10k extra on-call money. Ultimately you end up doing the same work but one of them gets paid less.
  • thebigspacefuck 4y ago
    They mentioned this in the article: “7. “It’s part of the job for all software engineers and not paid additional.” This approach is common at many companies. A few which stand out: Companies paying top of the market. Places which sit in the top tier of the trimodal nature of salaries usually pay far more without compensating for oncall, than lower-tier companies with very generous oncall compensation do. Big Tech. Most of Big Tech don't pay for oncall with cash compensation. Google is the only exception.”
• rb2k_ 4y ago
  > Some companies hire dedicated tech people whose only job is to be oncall, handle alerts, and improve the oncall infrastructure. This role is called ‘DevOps Engineer’ at some companies, SRE (Site Reliability Engineer) at others, and may also be called ‘Operations Engineer.’ Any company that I've seen put SRE/"DevOps"/... as the sole primary on-call rotation basically just created a glorified operations team. Unless you have shared pain for botched releases, you will never get rid of these problems.
• skeeter2020 4y ago
  I don't think most people here understand how labour laws work. "On call" is a well defined concept and IME universally allowed. Any Western jurisidictions DOES require you to pay someone when they actually get called. If it's overtime or not follows the regular rules for how that's calculated, same with time off and maximum work periods. What we're discussing here is how companies encourage and reward (or don't) for the inconvenience and impact of staying near your computer, not going out of town, or being woken up in the middle of the night. None are going to pay you time and a half on regular work commitments because you might get called. Jobs like a fire fighter are completely different. They work a scheduled shift and either respond to calls OR do other work during that time. They're not really on-call as much as prioritizing work. They also don't get 1.5x for their regular scheduled work.
  • wgjordan 4y ago
    While labor laws are indeed relevant, I think prevailing on-call compensation standards for software engineers have more to do with companies applying their own fairness standards to a tight job market than strict legal compliance. In particular with regards to US law, salaried computer employees (and highly-compensated employees) are 'exempt' from the minimum wage and overtime rules of the Fair Labor Standards Act, so while it's true that you need to pay someone for doing work on an on-call shift, I don't think a US employer is necessarily legally required to pay them any _extra_ if they're an exempt employee.
• deleted 4y ago
  [deleted]
• wgjordan 4y ago
  Relevant US case law is Berry v. County of Sonoma, 30 F.3d 1174 (9th Cir.1994) [1], holding that county coroners' on-call time (requiring carrying pagers and responding by telephone within 15 minutes) was not compensable under the Fair Labor Standards Act. Two key factors are "(1) the degree to which the employee is free to engage in personal activities; and (2) the agreements between the parties." Beyond these general factors, no universal rule applies since the details matter (frequency of calls, response-time requirements and geographical limitations, etc) in the degree to which they limit personal activities, as do any agreements laid out in a contract or company policy (e.g., how specific 'on-call' requirements and compensation are defined and agreed upon in advance). Note that these factors have only to do with the time spent _waiting_ for a call; time spent _actually working_ while responding to a call is more clearly work that should be compensated. [1] https://casetext.com/case/berry-v-county-of-sonoma https://casetext.com/case/berry-v-county-of-sonoma
• yibg 4y ago
  Seems kinda incomplete without considering total compensation. You get 100k a year but some additional payment for being oncall. I don’t get anything extra but make 300k a year. Who really has the better deal?
• snojo 4y ago
  We've unionized on-call to a certain degree, which makes things very nice and transparent in a certain scope. I get paid a static sum (which is very competative) just for having the phone for the week, and then if I get a call, doesn't matter how minor, it's 4h of normal hourly pay for the call. This is only if the call is outside of normal working hours (so between 8pm and 8am) I do really like this setup since it forces the employer to actually fix issues that are causing "wake-up". It should be expensive to make the call and thus an effort should be made not to make it. I'm not sure how it works in other parts of Europe, but in Iceland this is considered normal. We also try to split it quite evenly so it's usually only a week every 4-5 weeks or so.