If a big selling point of your system is the ability to be on 24/7, on-call is inevitable. But it definitely can be way less gruesome than it currently is at Amazon for a lot of teams right now. For example, my on-call schedule is extremely relaxed and low-stress, it is never a worry I actually have or something I dread ahead of time. But getting rid of it completely is simply impossible for a lot of "always online" services.
hire more people?
Hiring more people is a great idea for making on-call less stressful, because it allows for much sparser on-call shifts (e.g., one week every 8 months vs. one week every 2 months). But I don't see how hiring more people gets rid of on-call completely. Someone will always have to be on-call.
You cannot just hire people who do on-call-only duties and nothing else, you have to be very closely familiar with the code and features being written in order to resolve issues effectively. Which usually means that you need to be someone who actually worked on those things, not just some glorified extra-fancy customer-support worker.
Being effectively at work 24 hours a day for seven days straight sure sounds like a recipe for burnout to me. As TFA notes, these people aren't doctors, the only thing that happens if a glitch takes two hours to fix rather than one is that Amazon loses some money. Amazon naturally would prefer not to lose that money, but its workers presumably would prefer to be able to sleep too.
They typically aren't, you need to hire more people then. In anything defined as critical I would suggest that being well rested is also a requirement rather than having a team of people who are so overworked they develop mental illness.
I would much rather bite the bullet, be on call a week a month or so and use the budget for something else.
And I'm not talking about Amazon here. Of course Amazon can afford to hire everybody and their mom to cover 24 hours in a day. I'm under the impression that your original comment was really a critic of the practice in general, not just this specific example.
Some small companies build products they try to sell to bigger companies. These bigger companies have SLAs, so they need SLAs from their providers to sign a contract. Even at a small startup on call may be necessary to get customers.
It absolutely was criticism of the practise in general. Yes, small companies that can't ensure that there workers aren't overworked don't really make sense with protections like these. But the same is true for environmental protection.
Critical infrastructure arguably ought to be handled by companies large enough and with enough staff to comply with regulation like this.
For anything else I don't see the issue. Some random smartphone app company doesn't need to fix anything at 3 am in the morning, it can be fixed the next day. That's exactly the culture I'm critizing. 24/7 readiness to work for some random product at the expense of mental health is awful.
I gave you examples of how to implement on call without overworking your employees and even giving them the option to run a few errands here and there. So what's the problem? You seem to be against the practice just for the principle, not even really for any bad effets due to bad implementations.
As for which products are worth implementing "on call" for, yes I agree, some companies are too quick to think that the world can't function 30 minutes without their product.
Anyways, I've seen it implemented successfully at companies with very low attrition and I do believe it is a necessary tool sometimes for small companies to grow and sign big whale customers.
It doesn't make financial sense because companies can get away with exploitative behavior because software engineers are quite naive (or even actively detrimental to themselves and their peers) when it comes to labor relations.
I see this comment again and again on this thread "if it's really critical spend the money", but the thing is even small companies sometimes have critical systems. Simply because they're trying to compete with bigger ones, or they're partnering with companies that do have critical systems and the SLA gets passed down the chain of dependencies.
They could afford to 3x the teams if they wanted to. They just don't want to, because management prefers to just keep the money and burn out their subordinates. (There's always more where they came from.)
The description in the post is not even that bad. A page a week is nothing. And it is clearly state that your workload is reduced during your on call period.
In practice, your workload may not be reduced during on call because it's "expected" and you still have to meet your normal deliverables while the team isn't staffed with "extra" people. It also takes a toll on employees to be mentally-available at all times in case some triviality emerges and raises an alarm. You'll find many engineers not willing to leave a small area or even go out for dinner without bringing their laptop and a hotspot, just in case.
- use a primary and secondary on call so that the primary can still go get groceries, or play in the yard with their kids, etc - overlap on call and work hours. I did that at a job and I was fine with working 6pm - 2am just to cover this time slot. Won't work for everyone, but may be a nice compromise for some.
Like everything else, there are ways to do it right, and way to go complete bananas with it.
Sure, agreed. Sometimes it's implemented well and sometimes it isn't. I've experienced some of both.
When it isn't well-implemented and is particularly non-critical, it can feel a bit dystopian to the engineers. If done well and for a good cause, it should be fine.