Oncall Compensation
Which companies pay for oncall, and how much? Philosophies across the industry for paying for standby duty and numbers from 80 companies.
👋 Hi, this is Gergely with this month’s free issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at big tech and high-growth startups through the lens of engineering managers and senior engineers. Subscribe to get this newsletter every week 👇
This issue is the second part and final article in a series about oncall. Part 1 – published last week – covers healthy oncall practices. In this issue, we dive into:
Oncall philosophies across the industry. How do groups of companies approach oncall practices and compensation?
Companies which pay and those that don’t. An overview of more than 120 firms and their approach to paying, versus others which do not.
How much do companies pay? Data points from 80 employers.
Companies which don’t pay. How do they approach oncall?
Poor oncall cultures. What are examples of places where oncall can be a reason for churn?
This issue of the newsletter is also going out as a monthly, free issue. Feel free to access and share the free issue here.
1. Oncall philosophies across the industry
Looking across the industry, there are several different philosophies.
1. “Being oncall is your one and only job.” 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.’
The role is constructed so expectations are clear and shifts are staggered, so the workload is reasonable.
These roles are typical at more traditional companies, many of which are transitioning from an Ops model, (see Part 1 of this series for detail on what an Ops model is,) to one with more continuous delivery. The role is also widespread in highly regulated industries. Companies which prioritize software engineers’ wellbeing might also opt for this model, or at least utilize dedicated people to be oncall to lighten the burden on the engineering organization.
2. “It’s not part of the job outside business hours.” Plenty of businesses don’t expect engineers to be oncall outside of business hours. These companies are typically:
Local businesses serving local customers who use the service during normal business hours. Many B2B services might fall into this category. In these cases, customers are fine with the system not working at times when they don’t usually contact company employees.
Businesses where downtime outside core hours is not a major problem. These are either small businesses, or those operating with little to no competition.
Startups without many – or any – customers.
Developer agencies and consultancies usually don’t cover for oncall, though there might be exceptions depending on client contracts.
3. “It’s not part of the job outside business hours, but we might still try to reach you during those times.”
A variation of the above two cases, when the company does not expect software engineers to be available. However, they do have someone oncall, and that person might try to reach out to software engineers during an outage. However, it's not expected that the engineer answers their phone.
This is a typical setup at small businesses and startups where incidents are too few and far between to warrant making oncall “official.” It’s more common at companies where the founders are hands-on, and can resolve most issues themselves, thereby bearing most of the oncall burden, rather than the engineers.
4. “It’s part of the job for all software engineers and we operate in regions which regulate how it needs to be compensated with pay and time off.”
There are plenty of countries that regulate oncall pay and time off, the list of which we covered in Part 1 already. Most companies operating in these regions structure their oncall compensation to adhere to local regulations.
I say “most” as two groups will technically violate regulations:
Companies with a satellite office and leadership which is unaware of the local rules. In such situations, it might be down to local employees to communicate the regulation and lobby to put compliant oncall compensation in place.
Small companies for whom following regulations unfit for tech companies would do more harm than good. In some countries, regulations for oncall have been drafted for groups like firefighters or police. While such regulation makes sense for many non-digital professions, the requirements of the regulation might be overly rigid for smaller tech companies to follow. So, they might sidestep it and compensate in line with the spirit of the regulation, while not following it to the letter.
5. “It’s part of the job, but we acknowledge the disruption with pay and additional time off.”
Empathetic companies acknowledge going oncall is another burden that needs to be compensated, regardless if there is no local regulation mandating it. These companies offer pay, and might also offer the ability to choose time off, or a mix of compensation. Companies that typically use this approach:
Traditional firms which pay for oncall in other parts of the business, already. For them, paying software engineers to be oncall is a given.
Companies paying at or below the middle of the market. Without paying for people's time, these places would see high attrition, as engineers would seek opportunities elsewhere.
Companies aiming to minimize engineer attrition. Unpaid oncall will always be a reason to look for a new job. Employers looking to minimize software engineer attrition will seek to recognize this work at the very least with cash, but perhaps also with time off.
Companies investing in healthy oncall practices. These companies look at oncall as a cost that should be quantified, and do so.
6. “It’s voluntary for most people, and we encourage it with pay and time off.”
The final group are companies which do need people oncall, but manage to structure this so it is voluntary. They get enough volunteers by generously compensating for being oncall. Often, these places have dedicated people oncall along the lines of DevOps engineers or SREs.
What if there are not enough people to cover oncall? The company might reserve a mandate for anybody to go oncall until there are enough volunteers, but pay generously for their time. In most cases, the companies I talked to which implement oncalls this way manage to recruit enough volunteers.
For example, an engineer at The Guardian – the UK-based newspaper and website – shared that their oncall is voluntary and works well:
“Our oncall is paid at £750 per week. It’s a voluntary rota of 2 engineers each week. On top of the pay, you are encouraged to take rest after your shift. Oncall is popular and we don’t have issues filling the rotation.”
Voluntary oncall can work well if the effort it takes to staff oncall, is far lower than the number of engineers at the company.
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.
Startups low on capital. Oncall is part of the job at startups that don’t have large amounts of funding. This is the case for most Pre-seed and Seed startups, while plenty of Series A ones operate like this, too.
Companies which can get away with it. Even if not paying the top of the market, compensating for oncall is an additional expense. Many companies will try to avoid it, if they can get away with it.
Some firms compensate with time off, instead of cash. This can range from inviting people to start late if they got paged the previous night, all the way to offering a specific number of days as paid vacation for each week worked of oncall. For companies which already offer unlimited time off, offering lieu days is no change to the existing policy, and so it won’t be seen as a supportive measure.
Although I list seven different philosophies: in reality, there are two main ways of thinking about oncall:
A: Oncall for software engineers is additional.
1. “Being oncall is your one and only job.”
2. “It’s not part of the job outside business hours.
3. “It’s not part of the job outside business hours, but we might still try to reach you during those times.”
4. “It’s part of the job for all software engineers and we operate in regions which regulate how it needs to be compensated with pay and time off.”
5. “It’s part of the job, but we recognize the disruption with pay and additional time off.”
6. “It’s voluntary for most people, and we encourage it with pay and time off.”
B: Oncall is part of the job:
7. “It’s part of the job for all software engineers and not paid additional.”
2. Companies which pay for oncall, and those that don’t
Being oncall means you need to be on standby and have your laptop with you at all times, so you can respond to pagers, and start resolving incidents within minutes. Most software engineers who are oncall tend to have this responsibility for a week at a time.
Being oncall can be quite disruptive in two major ways:
It disrupts your personal plans, outside of work. Going to the movies with your kid, or perhaps on a date? Bring your phone and your laptop and be ready to exit midway through if you get a page. For any event in the evenings, at weekends or during the holidays, you either need to schedule cover with the secondary oncall – if they are around – or be ready for your private time to be disrupted. Some people move their social events around so their oncall week is clear.
It disrupts your sleep. Alerts don’t care what time it is and they can wake you up in the middle of the night. You might also have to do an investigation at 3am. This has happened to me more than once. Disrupting your sleep can also have short and long-term health consequences, according to scientific research.
Several countries have strict regulations around oncall, with some going as far as mandating the right to a certain number of hours of uninterrupted rest per day or per week.
Incident management scaleup indecent.io (disclaimer: I am an investor) ran an oncall survey where they collected 200 responses, and found that while 70% of respondents said each team was responsible for their oncall rota, about 40% were compensated for oncall. An interesting finding from their summary:
“Interestingly, this was more common in larger organizations (5,000+ people) than in small to mid-sized organizations that participated in the survey.
Where companies did provide compensation, most paid a fixed amount for time spent oncall (e.g., $X per hour, day or week). But the actual dollar amount paid ranged significantly, from $5 to $1,000 per week, with the average weekly rate at $540.”
For this series about oncall, I invited people to share whether their company pays for oncall, and if so, how much? Here is a collection of companies which do not pay for software engineers to be oncall – but still require it – and ones that do. Note that companies in the “Unpaid oncall” column need to follow local regulation for oncall compensation in countries which mandate this, as discussed in Part 1 of the series.
So which companies pay, and which ones do not?
Let’s address the elephant in the room: Big Tech generally does not pay for being oncall. Except for Google, and except for regions where paying for oncall is mandatory, they don’t compensate for this. Why is this?
A major reason is these companies pay top of the market: in the third and highest bracket in the trimodal compensation model. So even when not paying for oncall, they offer higher compensation than most other companies which pay lower, but compensate additionally for oncall.
And it’s reasonable to argue that they have a point. Between these two offers, which one sounds more appealing?
$140,000 in total compensation. Oncall is paid additionally, as $800-1,200/week, meaning about an additional $8,000-12,000 per year.
$310,000 in total compensation ($180,000 base salary + the rest in stock). Oncall is not paid.
Many well-funded startups which pay closer to the top of the market also make oncall as part of expectations as well.
The only curious data point is how Google, on top of paying top of the market, also pays for oncall, and invests in healthy oncall practices on top of these, as we’ve covered in Part 1 of the series.
3. How much do companies pay?
How much do companies pay which compensate for being oncall? The answer is, it varies a lot. This ranges from about $100 per week, all the way to around $1,250 per week – and even higher for some engineers at Google.
Compensation approaches are split between these three buckets, ordered by frequency:
Flat rate per week or per day of being oncall. The same amount is paid, regardless if there are incidents that need attention or not. Most companies which pay for oncall follow this approach. A common reason for going with this, is that it incentivizes quiet oncalls: there’s no financial benefit to working on outages out of hours.
Flat rate for standby, plus pay for hours worked outside core hours. Another approach is to have a flat standby rate. However, when an incident occurs and engineers need to spend time mitigating it, they can claim additional compensation for that time. This is usually a multiple of their regular hourly rate, and is often more for a weekend or a public holiday. Several countries mandate this approach, even if companies pay a decent standby rate already.
Only pay for incidents worked on out-of-hours. Some companies don’t pay for people to stand by, but do if they need to do work during the night or at weekends. This work is usually the mitigating of an incident. Most companies that pay this way do so because of local regulation, which mandates paying for overtime at night or during weekends.
Here is a summary of the policies various companies have, and how they compensate.
This issue too long to fit in a newsletter. Continue reading online for more details on:
3. How much do companies pay? Data points from another 70 employers.
4. Companies which don’t pay. How do they approach oncall?
5. Poor oncall cultures. What are examples of places where oncall can be a reason for churn?