3 ms·
It can also impact IT professionals and others in fields where after-work emergencies are frequent. Come again, what now? For critical services you have an on-
by HarryHirsch 9y ago
It can also impact IT professionals and others in fields where after-work emergencies are frequent.
Come again, what now? For critical services you have an on-call roster, like hospitals and utilities have always had. Why would anyone think that IT was any different? If the company continuously flies by the seat of its pants and needs to call in the sysadmin to put out unscheduled fires it's simply poorly run, that's all.
- noir_lord 9y agoAbsolutely this. I don't respond to email after work unless the building is literally on fire unless I'm on rotation in which case that's either in my contract and I'm compensated for it or it isn't and I don't respond. Salary buys 40hrs of my time (on average, some weeks might be 45, some 35) and that is it. My time outside of that is my own and jealously guarded.
- emmelaich 9y agoAbsolutely. My work wanted after hours support but would never pony up with the requested on-call rate. They'd still pester us and ask for Gentlemen's Agreements to attend if we happened to be available. All the while we used to get lectured about maintaining a good work-life balance from HR.
- omginternets 9y agoMoreover, certain contracts can and do stipulate on-call schedules. This article is rather absurd.
- hjnilsson 9y agoIt's ridiculous how the article portrays the employee as the as the bad guy here. Remember that the law only applies to companies with >50 employees. If you are at that scale, you can afford to pay on call people for emergencies.
- autokad 9y ago'employees a “right to disconnect” from technology after office hours.' seems reasonable to me. not a ban, but we should have the right to refuse. if a company continuously flies by the seat of its pants and needs a sysadmin at all times, then hire more sysadmins, come up with a better solution, or rightfully go out of business. hospital doctors is a very different animal, and honestly I haven't thought long enough on it nor have enough information on it to make an opinion, so I'll leave that to the field to decide. as far as utilities, I believe they are paid overtime. like 2x. in my first job that was a support role, I was told to stay on call 5-8 and work 1 extra weekend shift from home every 4 weeks without additional pay.
- derefr 9y agoIn IT generally, yes; but specifically in pre-money startups, you usually can't afford to employ enough people to have an "on-call roster." The single ops person (who is usually also one of the devs) has to work a regular shift, and then also be on-call to put out fires. (Not that this situation has anything to do with the law under discussion, which is only for 50+-employee companies; but it is an awful situation generally and one we should figure out how to avoid—it's IMHO one of the primary causes of burnout.)
- sologoub 9y agoThat's a recipe for disaster - a burnt out engineer is the last person you want next to a customer emergency in a proof of concept startup. This is one of the reasons why multi-person founding teams are favored by investors. Regardless if you have 3 people or 23, you have to balance the load between them. Having one person shoulder the responsibility and pain alone leads to resentment, burnout and failure. Even if you are a non-tech founder, you can chip in by taking pager duty alerts and verifying that they are real and not a false alarm. It's amazing how much a night of sleep after weeks of fires can really help you stay sane.
- InclinedPlane 9y agoPrecisely. What this is about is pushing the requirement to be on-call into the open. It has to be negotiated and agreed to. And, hopefully, compensated for. That's all.
- sologoub 9y agoIt's really sad how many execs who claim to be very technical do not understand this. Recently had a debate on this exact issue where they were going to assign after hours support duty to the sole engineer on a particular API that's supporting a mission critical dashboard. The right way to do it would have been to work with other teams and product to share the burden of alert triage and filtering false positives. If and only if it's a real problem that can't remediated with a restart, then we can wake up the sole engineer. Otherwise, burnout and churn...