The adoption of the trend called on-call is high among software companies where they expect employees to work beyond office-hours for things like urgent customer issues, pipeline failures, etc. This can be an overhead for the scrum team members as they know that unexpected work can pop at any time of day or even night as well. Companies make sure that an employee can work at any time by providing laptops and setting company specific apps of their mobile phones to keep them updated all the time. This hinders freedom of employees, disturbs work-life-balance and arises a sense of insecurity or fear among them.

A model where an employee is only expected to stay online or fix critical issues only during his usual working hours and after that he is free to do anything or go anywhere without worrying about the work really sounds employee friendly and appealing.

So why are even big tech giants reluctant to provide employees such a mental peace and push systems like on-call and are there are companies which prefer not to disturb employees even in case of critical issues ?

  • 5
    Employees are usually compensated for being on-call. Where they aren't, it's the employee's responsibility to make themselves unreachable outside of working hours. I don't have company emails on my phone, and I don't check my emails until I'm at work. Feb 28 at 11:59
  • 9
    Can you back up your claim with some actual data. that this is frequent ? In my experience on-call expectation is very rare except for critical roles where it's part of the job and compensated for .
    – Hilmar
    Feb 28 at 12:21
  • Frequency depends on how stable the module owned by an individual is. What I see most of the time is people working beyond regular office hours in case of CI/CD pipeline failures. Though it is compensated on hourly basis, trade between money and free time is not what every programmer wants. Feb 28 at 13:32
  • @JoeStrazzere though not explicitly mentioned as 'on-call' I see most of the company's policy docs saying 'You are expected to work at least for 40 hours a week. You may need to work extra and on weekends if the job demands so.' Feb 28 at 13:38
  • @NishantIngle , to cut to the point, no companies do that any more. Notice my answer and the humorous example. You're just stuck in an oddball experience. Change companies.
    – Fattie
    Feb 28 at 14:25

Because companies can't afford their systems to be down for 16 hours (or 2.5 days if things fail at 5 PM on Friday). If that happens, the company goes bust and then nobody has a job.

Sure, there are bad ways to do on call, but if it's done right then:

  1. The on-call team are only notified for things which are actually a critical issue.
  2. On-call time (and in particular, being woken in the middle of the night for an on-call issue) is adequately compensated for, either in terms of money, time in lieu or both.
  • 1
    @JoeStrazzere At least at my work (a major streaming service), we already hire people to keep the systems running 24/7/365. People are on-call for when the problems are too hard for the operations folks to resolve, it's just not possible for them to have deep domain knowledge of all of our critical systems. Feb 28 at 12:37
  • 2
    When companies need 24/7 coverage they should and can pay specific people to be in call. Feb 28 at 23:24
  • 2
    Having developers on call, for issues that are too hard for others to fix, also provides an excellent incentive for developers to make those issues less likely to occur. The least reliable systems I worked on, were those where the devs could leave it up for the ops people to deal with. Mar 1 at 12:24
  • @mattfreake That's far too narrow a view IMO - Availability levels and operational requirements need to be specified and costed in the first place so they become part of the core acceptance criteria. Sufficient infrastructure as well as extra testing is also necessary before the system reaches production. Resilience involves architectural considerations, and along with extra testing and infrastructure, involves extra cost. This isn't something which you can fix with an "incentive" because it's something which affects every aspect of delivery, not just development. Mar 1 at 14:55
  • Those all sound like issues that can be resolved by ops, rather than more dev focussed issues that they have the knowledge how to resolve Mar 1 at 16:03

I believe you overestimate the size of the problem.

I've worked in this business for 35 years, for 9 companies on 2 continents and none of those companies have had an actual "on call" policy in practice. There were only 1 where I was ever presured to work extra hours for more than an evening or two, and that was for a company-survival-level emergency. Most of my colleagues have similar stories.

Companies do often say "we expect you to work whenever you are needed" so that they can call on their developers when they need it. But even then people are not usually "on call" 24/7.

Genuine "on call" is a problem for companies. What are they going to do if they need you and you are at a family wedding? Or your wedding? Or on a wilderness trek with no wifi? Or at a party and too drunk to code? At the very least there must be times when the company has to acknowledge you are unavailable, which means there needs to be at least two people and some kind of rota. Where there is an actual requirement for 24/7 customer response then a team is assigned to provide it, and they are told what hours each one needs to be available, and are compensated for the time they are on call.

If a company literally says they require you to be on call at any time, ask them what happens in the situations above? If they say that you "have to be available" even when you are not at work, then respond appropriately. I would just tell them that's not acceptable and ask if they want to continue the interview.

Having said that there are companies that regularly require long hours, but outside highly competitive industries like gaming it is rare. And it's a cultural thing rather than the rules. If you interview with a company where you suspect they might require long hours, ask the interviewers how many hours they have worked in the last month? And usually with such companies the internet is full of horror stories about how long the hours are.

In many jurisdictions a person cannot be on call (In the sense they must be available) unless they are paid for that time.

  • Hi @JoeStrazzere .. could it be you're sort of conflating the (truly rare) cases tyoday where (certain very specific) devs are indeed on call (in an organized and finely business-like manner), with, the "old - era" practices of shambolic coding, everyone shambolically "working 24/7", no testing practices, no structured development, no CI, everyone being phoned 24/7 when the credit card gateway goes down, etc !!
    – Fattie
    Mar 1 at 16:28

Phillips excellent answer addresses a core issue, mine is just a more general view.

The practice is an old one. Companies do it for many reasons and it's normally a win win situation.

The company gets it's needs met in an emergency and the employee makes more money.

But there are also underlying reasons. It gauges a persons work ethic if nothing else, staff are expected to have some commitment to the company that pays them in terms of keeping their role running smoothly. Why would you even hire someone who's basically saying they're not interested in doing that, it's tantamount to saying they're just there to keep a seat warm and they won't or can't work under pressure. There's plenty of other potential hires who are more than OK with it.

At the end of the day if you don't like that clause in a contract you don't have to sign it. It makes sense for the business to have it, and in some places and locales workers are actually looking for companies that have a reasonable amount of overtime. But there are also businesses that don't need it, you should target those.


Other than a truly tiny organization (e.g. 10 tech staff) , assigning development staff do operations work will prove more costly in the long run. The development will suffer, and they are overpaying for the ops work hours. The only way this is a cost savings is if the work is being done "for free", in which case the effect on the quality of the ops work should be self explanatory. Last but not least, the best staff leave, the average/below ones stay.

Unequivocally, a bad move on the company's part.

The reason for "why", is short term incentives up high. That simple.

  • 1
    A straightforwardly correct answer, like mine. The downvotes here seem to be due to a confusion between (A) the extremely rare cases where very certain devs are indeed on call at al times and (B) a shambolic outfit where everyone gets phoned at all hours over shambolic bugs.
    – Fattie
    Mar 1 at 16:26
  • I disagree with this answer. The reason is that developers operate with a limited knowledge. By having some (not all the time) interactions with actual users, the developers can learn important details that will make their design decisions better and the code more useful. I find that I learn a lot by talking to users and they will suggest improvements to my code. I have also learned that I do not want to write code that generates the 3 AM phone calls because something is not working.
    – David R
    Mar 1 at 17:32
  • @David R -- what you say makes sense, and I agree with it -- the occasional trip to support customers/ mfg/ service on-site have, without exception, given me perspective I wouldn't have gotten otherwise. But a little goes a long way in that regard. Having to take "emergency" calls (most aren't), on a weekly basis, would result in me quitting and/or asking for a massive pay increase that I wouldn't dare to otherwise. I think it's safe to say the situation to which the OP is referring is one where the management simply believes the cost of a full-time position to do this is somehow wasteful.
    – Pete W
    Mar 1 at 18:04

The adoption of the trend called on-call is high among software companies where they expect employees to work beyond office-hours for things like urgent customer issues

Fortunately this is simply completely wrong.

That was a trend in - say - the 1990 era.

Any software company that adopts this "cowboy coding" / "cowboy service" approach today would just be seen as boobs, a hoobyist company at best.

are there are companies ...

Yes, all serious companies now operate in a modern, non- "cowboy coding" / "cowboy service" approach.

To make a humorous analogy the question would be like asking

"Nowadays are there any software companies that bother commenting their code?"

It's likely you just had a bad experience with some oddball company. Simply move on, due to the enormous demand for software engineers at the moment you can easily change companies.

  • ? As it says " "cowboy coding" / "cowboy service" ". Formally and correctly having specific devs on call is a normal and (in rare cases) appropriate business model. As I read the question, the problem at hand is the shambolic situation where everyone is always on call, which is a joke situation .. "cowboy service" if you will. The first three sentences of this answer are pretty clear. "Fortunately this is simply completely wrong. .. Any software company that adopts this "cowboy coding" / "cowboy service" approach today would just be seen as boobs, a hobbyist company at best."
    – Fattie
    Mar 1 at 16:24

You must log in to answer this question.

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