[Johnny555]

On call is justified in my opinion only if someone will die if the problem isn't handled. Or if compensation is dramatically increased and agreed upon in advance.

What if the company will die if the problem isn't handled? Many companies (mine included) provide a service that needs to be highly available 24x7 (customers run automated tasks 24x7 against our service). If our site regularly went down for hours at night (or even for an entire weekend) because of a software problem that no one could fix because the developers weren't picking up the phone, we'd lose customers and eventually, the company would go out of business.

Even a 10 minute outage is a significant event and requires a full RCA for customers. We try hard to architect for high availability, but bugs do happen.

[dsp1234]

The answer here seems simple. Include on-call time in compensation, and fire developers.

Note that for some developers, you're never going to be able to compensate 'on-call' hours appropriately due to their evaluation of the opportunity cost of their time.

[vkou]

> Include on-call time in compensation...

I'm glad you brought this up - there's a quick conclusion to this conversation:

"On-call time compensation is part of your salary."

[mjevans]

Yeah, the labor laws are broken.

Salary shouldn't be a thing that a company can ever hide behind.

Labor laws really do need to cover the maximums that an employee can be expected to work. They should also make going above those maximums exponentially more expensive in 'bonus time'; and the accumulation rate shouldn't magically reset after time, but only after time back on normal/reduced work load and duration.

Also, while I'm on this subject, 'full time' work should really begin at more like 24 hours / week. Benefits for part time work should be pro-rated. (It should never be more cost effective to split a full time job in to part time jobs. That is defrauding the economy and making others pay for the costs of your labor.)

[galdosdi]

That's just fine, as long as on-call expectations are fixed as part of the job offer, just like salary is. If the on-call expectations change for the worse later, that is exactly the same as a salary cut.

IANAL but I believe (in the US or in NYS at least) this would be grounds for quitting with full unemployment coverage (you are not usually eligible for unemployment benefits if you quit, exceptions include the basic nature/hours/wage of the work being changed without your consent, since that is philosophically similar to having your old job terminated and being offered a new, worse one)

Get any on call expectations in writing when taking an offer if you can, just like you'd expect salary in writing

[lazerwalker]

The real problem then is engineers being unwilling to vote with their two feet.

In a market as friendly to software developers as we're currently in, the correct response to that is totally "great, consider this my two week's notice, I'll go to this other company across the road that pays the same salary but doesn't demand I have on-time call".

(No, the response to every problem with your work environment should be to get a new job, nor is that even a realistic possibility for many. The economic argument still stands.)

[PeterisP]

It's a valid answer provided that on-call was part of the conditions known during hiring and salary negotiations. If we've negotiated a salary of $X for doing Y, but then you suddenly want Y+on-call, then you're going to either pay more or find another employee, because $X is simply too little for that.

[st3v3r]

"What if the company will die if the problem isn't handled?"

Then they should be paying huge bonuses to be on call, or simply hiring for multiple shifts. It's pretty easy.

[Johnny555]

Maybe they "should" do one of those, but it seems unrealistic to expect a small 10 - 30 person company to do either.

And when the company grows large enough that they can support 24x7 engineering staffing, they usually do it by having an overseas team.

[arielb1]

If you can't pay enough to find someone competent to be on-call, you have to do without. That's life.

[st3v3r]

"Maybe they "should" do one of those, but it seems unrealistic to expect a small 10 - 30 person company to do either."

Why? What's so special about a tiny company that they get things for free? What's so hard about, "If you want something, then pay for it"?

[Johnny555]

Because, math? That company may have a team of 5 developers, how do you split those 5 developers across 3 8 hour shifts that cover 24 hours/day 7 days/week + holidays + vacations + sickdays to get 24x7x365 coverage without doing an on-call rotation.

When you're in a 100 or 1000 person company, then it's easier to have dedicated after-hours support staff (or staff working from multiple timezones around the world)

No one is saying that it should be "free", it's built into the salary - every company that I've worked at that's had an on-call is very clear about on-call rotations during the interview.

[st3v3r]

"Because, math?"

Except you're saying that small businesses should get to ignore that math, and get stuff for free.

" That company may have a team of 5 developers, how do you split those 5 developers across 3 8 hour shifts that cover 24 hours/day 7 days/week + holidays + vacations + sickdays to get 24x7x365 coverage without doing an on-call rotation."

You hire more people so that you can, or you don't make deals you can't afford. Honestly, why is this so hard to understand? Why do you feel so entitled to things you can't afford?

[Johnny555]

Again, who said anyone is getting anything for free?

My company has 100+ engineers, all of whom do a on-call rotation, they are all aware of it when the sign up, so that on-call duty is included in their salary. The employee can evaluate for themselves whether or not they think the salary is sufficient to cover that, but as far as I know, we've never had a candidate turn down an offer due to the on-call requirement (though I don't know that they'd always tell us that's why)

But really, does any engineer join a small company (in the USA) without assuming that they'll be on-call after hours? Even in early stage companies that haven't launched a product yet, there's still after-hours support to be done to keep dev systems running, fixing broken builds, etc.

[brazzledazzle]

And that overseas team often has little-to-no ownership so they call people while they're sleeping or half ass everything. This problem is magnified if they're contracted and not actually employees.