1

I just read this question about potentially giving on-call responsibilities to a team to match other teams at the same company. Understandably, people are opposed to requiring additional work without providing additional compensation. However, reading the answers gave me the impression that people view on-call responsibilities themselves as bad or out-of-the-ordinary.

That struck me as odd, since in my (albeit limited) experience as a software developer, on-call rotations seem pretty standard for salaried developers. And if software breaks after hours, who else is going to fix it if not the developers?

Are on-call rotations for software developers commonplace or unusual?

12
  • @GregoryCurrie Well, I don't imagine many people would want to be on-call all the time, even with a bonus. So it makes sense to spread out on-call shifts among all the developers. And if everyone is doing on-call, it seems odd to have a special bonus for it. It makes more sense to just pay everyone nice salaries and have on-call be part of the job responsibilities
    – T Hummus
    Jun 26 at 4:56
  • That doesn't seem workable to me. How do you ensure everyone is working the same amount of on-call? Or do you think every developer should be contactable at all times? Jun 26 at 4:59
  • Where I worked, my team needed to have someone on call at pretty much all times. Two of my team did the bulk of the on-call, and they got paid an on-call fee for the inconvenience of not being able to be more than 30 minutes from a computer. They were reliable because they were directly getting paid for it for a specific period of time. Jun 26 at 5:01
  • 1
    Let us continue this discussion in chat.
    – T Hummus
    Jun 26 at 6:10
  • 1
    Some people would have a real issue being reachable 24/7 for a week. I play sport twice a week on a large field, I would have to give that up for the weeks I'm on call. My overall perception is that if something is important, it should be in the employment contract. Jun 26 at 6:44

4 Answers 4

9

Yes. They are commonplace. And they are unusual. Depending on the specific type of developer.

Lots of developers work for companies that develop software for sale to others. It would be very unusual for a developer on the team at Microsoft writing Windows to have any need to do after-hours support. There is a whole support organization within the company that takes calls when some company encounters a critical Windows error at 3am.

Lots of developers work for very large companies that have their own support teams that handle the vast majority of after hours support. You might have a handful of high-level developers that act as third-level technical support when the overnight operators can't solve the issue from their runbook, the admins can't figure out what is broken from the logging the software does, and they call in a senior developer that has a solid grasp of the entire system architecture. In a lot of these organizations, random developers don't even have the ability to meaningfully access the production environment for security reasons so they'd have no ability to do meaningful support. It would be unusual for developers in these organizations to do after hours support.

Lots of developers work for companies that don't need (or pay for) 24x7 uptime (either because they are small or because they really only have people working during business hours). Stuff doesn't break overnight often because no one is using it after hours and if something breaks and there isn't the infrastructure to monitor systems to detect when things are broken. The first person to come in the next morning figures out that something is broken, calls IT, and IT starts working to fix it. It would be unusual for developers in these organizations to have on call responsibilities.

Then there is the middle ground of companies that need 24x7 operations that aren't big enough to have large, dedicated support organizations and SDLC processes that ensure that every project is logging information to the same place, that the organization is able to effectively monitor the environment to detect systems and processes that fail, etc. If you don't have a team that babysits the systems 24x7 and has discovered over the years that System A needs to be rebooted every couple hours because it leaks memory and if System B is falling behind that you need to throttle back the number of System C servers until things catch up then, yes, it probably falls to the developers of the various systems to do their own debugging. It's very common for companies in these sorts of middle ground companies to have on-call responsibilities because no one else can. It's also pretty common for developers to be unhappy when companies initially move from "we don't really care if the systems are up while everyone is asleep" to "we need the systems to stay up 24x7 but don't have the budget to have three shifts of admins so we'll just add the responsibility to the development staff".

2
  • 1
    Ah yes, that middle ground of companies sounds like an accurate description of where I work. And since I knew about on-call responsibilities from the beginning and felt well-compensated, it seemed perfectly natural. But if that responsibility were suddenly dropped on me I would certainly be upset
    – T Hummus
    Jun 26 at 6:18
  • At my current job, it's a large enough company to have people able to handle failures, but you are "on-call" about once every 3 months when it's your time to support the monthly release. You're expected to help with the release and make sure everything goes smoothly, but if something breaks, you're expected to be there for the hotfix. So one weekend in 12 you'll be "on-call". Jun 30 at 18:07
6

Are on-call rotations for software developers commonplace or unusual?

There is a very wide range based on country, industry and type of development job.

Generally speaking, if your software is running during off-hours and needs to service customers (that may or may not be humans) during off-hours, then having people on stand-by to fix upcoming issues is indeed normal.

Whether that is the actual developers of the software depends on the size of the company. The larger the company, the higher the chance they have an "operations" department set apart from the "development" department.

Being on-call should be a regulated activity, that has shifts, responsibilities, is paid and is compliant with all the regulations there are.

In smaller (or less organized or just cheap) companies, "on call" might just mean someone has the developers private number and will bother them if the software isn't servicing customers any more. However, there is no expectation that the developer is actually reachable and able to work at any time. They might be 3 hours out totally drunk on a friends wedding. They aren't on-call. They just were called.

Please note that having an on-call is definetly neccessary, not matter how good of a job the developers do. It's like an ambulance or fire department. You don't dissolve them because there hasn't been a fire recently. They are the safety net.

In good companies, being on-call is a no brainer. A money maker. You are sitting there playing a computer game all evening and you are making money for it, too. You basically sold your right to go out and party, get drunk or otherwise inhibited and drive to far away places. Something you may not have done anyway. In my former team, we always had enough volunteers for on-call that I did not have to do it all year, even if we all signed the same contract. They wanted to do it. Because they knew we did such a good job, it was highly unlikely they would ever get a call.

However, in bad companies or bad teams, on-call can be nerve wrecking. Constantly putting out fires on your supposedly free evening. Never knowing when you will get the call and who will breathe down your neck. Not knowing where in your bugg ridden product it broke this time.

So to sum that up: being on-call is very common in industries where the product is running and covered by SLAs or customer facing. Whether on-call is an easy time or a nightmare is up to the producers of the software. That means developers and their direct project environment. Produce quality and you will have to watch over a quality product, a great job to have. Build a shitty bug ridden product and you have to watch a clown on fire stumbling through a hornets nest. Sure, you will come off as the hero, but only to people who don't ask what the hell the clown was doing there in the first place, why it was on fire and how there happened to be a hornets nest.

In countries with labor laws to speak off, on-call is highly regulated. In others, it's not.

4

However, reading the answers gave me the impression that people view on-call responsibilities themselves as bad or out-of-the-ordinary.

It really depends on what you view as out-of-the-ordinary. If I was to take a complete stab in the dark, I would say that the number of software developers on-call at any one time is going to be less than 5%.

Not every company has people on call, and some companies have dedicated on-call people. Others have shifting rosters.

Do you consider 5% to be unusual?

If you change the definition to be companies that provide a service that needs high availability, that of course shifts the percentage.

If you're surprised at the response, you really shouldn't be. On-call is a burden for employees. If you want to change the status quo, you are going to get pushback. If the company is truly concerned, they should make it worth the while for the employee, and not hide behind the: "other teams have to do it".

That struck me as odd, since in my (albeit limited) experience as a software developer, on-call rotations seem pretty standard for salaried developers.

I'm guessing you're working in a company that delivers a service. The industry is incredibly broad.

0

Every job I've had in the last 8 years has had me 'on call'. However, I can count on one hand the number of hours I've spent utilized in emergencies after hours.

They may need you to be reachable in the event of an emergency, but that emergency may never actually come.

If concerned, I'd ask how many major issues occur that involve your team so you have an idea of the ask. If it ends up being too often you could also push back and say, I didn't expect this, this is getting to be too much time for me, you need to find someone else to cover the on call rotation / i can't do this many hours or be available on these hours.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .