Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Being on call sucks

bobbiechen.com

Post reply on HN
Print view View original

141–150 of 282 posts

Re: Being on call sucks

#141

Post by DoughnutHole »

sokoloff wrote: post #125
sam0x17 wrote: post #100

Side note -- I know a lot of early YC startups like to play things fast and loose, but you really should compensate your engineers for after-hours emergencies if they are already working 40 hour weeks. Morally and employee-retention-wise it's the obvious thing to do, but beyond that in certain states and jurisdictions you can easily run afoul of local labor laws if you try to require employees to do things outside of…

What I find interesting is that if you give employees a choice of 100 units of currency per year as salary plus 1 unit of currency for each week on call with an expectation of 1 week on call every four weeks versus 115 units of currency for the year with the same on-call expectations, some employees will feel better about the first arrangement and some will feel better about the second arrangement. Some people want t…

I'd say the issue for people who are inclined to pick the first arrangement is one of trust.

If you don't trust your employer not to abuse the second arrangement then you'd be a fool to accept it. With the first arrangement the employer is incentivised not to exceed the agreed upon expected number of on-call weeks because they are financially penalised for additional on-call time. With the second arrangement the employer can demand as much on-call time as they think they can get away with.

It's really a case of if you expect your relationship with your employer to be in some way adversarial - if you trust your employer not to screw you than go ahead, but you can't necessarily reliably make that judgement going into a new job.

Re: Being on call sucks

#142

Post by falcolas »

cube2222 wrote: post #8
Broken_Hippo wrote: post #7

Earlier quoted context omitted.

6. You are paid an amount for every hour of being on-call. This should be on top of your base pay. This is important. If you are on-call, you do not have the freedom that you would otherwise have and you should be compensated for this.

If it's in the contract you sign, then it's already priced in. I don't see much value in specifically outlining which part is base and which is for oncall, if oncall is mandatory.

In a US state with at-will employment, on call can be added to an existing contract without additional pay - continued employment is considered to be sufficient "consideration" on the company's part.

Re: Being on call sucks

#143

Post by valeness »

bpodgursky wrote: post #116
sam0x17 wrote: post #100

Side note -- I know a lot of early YC startups like to play things fast and loose, but you really should compensate your engineers for after-hours emergencies if they are already working 40 hour weeks. Morally and employee-retention-wise it's the obvious thing to do, but beyond that in certain states and jurisdictions you can easily run afoul of local labor laws if you try to require employees to do things outside of…

Unless you're in a really dysfunctional startup, the employees who voluntarily jump in after-hours to fix OC issues are going to be very quickly compensated with raises and refresher option grants. Far better payout generally than a few bucks of overtime. It becomes really obvious who is holding the company together and who is coasting, relying on the "senior" (ie, anyone who puts in the effort) engineers to keep the…

Lolol, I've been jumping in after-hours for years. They only take notice when you say "I quit".

Re: Being on call sucks

#144

Post by okdood64 »

newman123 wrote: post #99
cletus wrote: post #29

So I've been oncall at two major companies (Google and Facebook) and, at least in my experience, this covered both ends of the spectrum. Basically, Google gets it mostly right and Facebook gets it mostly wrong. At Google, a new service has to be supported by the team that developed it. There'a an extensive launch checklist that includes monitoring, having a runbook, etc. Here's the most important part: you're paid wh…

> alerts caused by issues in downstream systems that you could do nothing about How does Google deal with issues caused by downstream systems causing alerts?

Generally 1) Mitigate if possible from your service's end, while simultaneously 2) paging the dependent service's team to mitigate/resolve; and if this happens too frequently or if it was a particularly bad incident you can push the other team to 3) create a postmortem with follow up AIs if they already didn't do so.

Re: Being on call sucks

#145

Post by sylens »

steveBK123 wrote: post #61
sylens wrote: post #34

I have an opportunity to move into an all-remote role that would require me to be on call 24x7 for one week every 3 or 3.5 months. I asked about the frequency of incidents that required the on call person to be pages and it looked like on a bad week, it was about 7 total - a good week was 0. I’m personally torn on whether or not I’ll be okay with the on-call lifestyle so I appreciated this piece for giving me some fo…

That level of rotation is not a deal breaker in itself. You can basically look at it as 3~4 rotations per year, likely 1 or maybe 2 bad weeks per year. I've never been on a big enough team to have a rotation that wide, more typical is every 4/6/8 weeks. Beyond that teams usually build out globally and your rotation remains as often but is fewer hours per day (ie - US covers til 8pm when APAC comes in). The bigger con…

It would be for an internal environment, so weekends would be hopefully quiet. The incident log going back a month or two showed incidents mainly in the EU and US workdays, around 5 AM Eastern to 7 PM Eastern.

Re: Being on call sucks

#146

Post by toomuchtodo »

hrudham wrote: post #131
bpodgursky wrote: post #116

Earlier quoted context omitted.

Unless you're in a really dysfunctional startup, the employees who voluntarily jump in after-hours to fix OC issues are going to be very quickly compensated with raises and refresher option grants. Far better payout generally than a few bucks of overtime. It becomes really obvious who is holding the company together and who is coasting, relying on the "senior" (ie, anyone who puts in the effort) engineers to keep the…

I respectfully disagree. I did exactly this for a number of years. A colleague (and is now friend since we've both left said company) made it clear he would not work overtime without compensation (and never did), but his day-to-day work was excellent. He knew he had a skill they required, and was good at it (and our skill sets were the same). Our careers both grew at about the same pace for four years. He became know…

> As a professional, some self respect is required, or you will be abused.

These are hard learned lessons. You also have to structure your life in a way that you don’t need the job and can walk away when needed.

Re: Being on call sucks

#147

Post by valenterry »

Why not just have on-call being an auction?

Some people hate on call, some people love it since they are usually at home playing games anyways or don't mind so much being disturbed during sleep and love to make some extra money on the side.

So just auction the on-call times and have employees bid for them. Naturally, bids for on-call at christmas will probably be lower and for some other times higher. Employer can set a max. compensation they are willing to pay - if there isn't a low enough bid, well, on-call isn't happening. :)

In some companies something like that is already achieved by allowing people to switch times and also exchange compensation. A fully fledged auction is just the next step.

Re: Being on call sucks

#148

Post by kansface »

valenterry wrote: post #147

Why not just have on-call being an auction? Some people hate on call, some people love it since they are usually at home playing games anyways or don't mind so much being disturbed during sleep and love to make some extra money on the side. So just auction the on-call times and have employees bid for them. Naturally, bids for on-call at christmas will probably be lower and for some other times higher. Employer can se…

That would severely misalign the incentives of the two groups which leads to trouble over time.

Re: Being on call sucks

#149

Post by dkarl »

For larger companies: if you have active customers around the clock, have employees around the world, so engineers are never on-call outside their normal working hours. I guess that's much easier said than done, since having employees in different countries might be complex and expensive (maybe HR outsourcing companies like Trinet solve this for you?) and you have to manage employees in time zones that are offset from leadership.

Re: Being on call sucks

#150

Post by oogali »

gregmac wrote: post #93
oogali wrote: post #26

After years of iteration, here’s what our team does. The team is remote and distributed across multiple time zones ranging from West Coast US to Western Europe. This gets us as close to round the world coverage as we can have. There are two people on call for each shift, each shift lasts a week. It will typically (but not always) be one person from US and one person from UK/EU. This helps reduce the single personal c…

> Anything that is an annoyance during on-call is a candidate for review and change. What does that mean in practice? Hopefully: "This woke me up last night. It's now the top priority until it's fixed so it never wakes anyone up again. Sorry product manager, your new feature will have to wait."

"This woke me up last night, but it could have been something that didn't need escalation outside of business hours."

"This woke me up last night and had I snoozed for 5 more minutes it could have been catastrophic, let's get some more proactive monitoring in place."

"This woke me up last night and it was triggered by bad user input, we shouldn't get alerted on this but more importantly, we shouldn't allow users to submit this crap."

Very rarely do I encounter alerts that are traced back to some deep architectural flaw that requires me to tango with a product manager and their roadmap.

Often times, our team escalates to the engineering lead in question and a small bug fix is slipped into the next release.

Post reply on HN