|
|
|
|
|
by taormina
1666 days ago
|
|
Let's do the laziest back of the napkin math. Let's pretend you make $100k and work 2000 hours a year. You make $50/hr. Let's say you do 50 hours of week between trying to impress your boss and getting woken up to do call. Congratulations, you are now a $40/hr employee! Also, in my experience, the people who aren't getting woken up at 3am (aka. your boss) don't value the time and effort needed to stabilize these systems. So they want you working on the new shiny product feature that will get them promoted. Fixing the crappy data pipeline that shouldn't alert every other night isn't a priority when you aren't the one being woken up. Well, it should be a priority, but I also don't work at that previous job for this exact reason. I took a nice pay increase and have never had to be on-call. Don't settle. EDIT: Original 2000 hours comes from 40 hours a week * 50 weeks. Like I said, back of the napkin math here. |
|
There's the rub. The issue isn't being on-call, it's not prioritizing making sure the system is robust so that on-call is boring.
In my last job there was no formal on-call, but if shit was going bad I'd be expected to resolve it, or track down the right resources to do so. In my current there is a formal on-call rotation. In my 15 years at the previous job I probably got called out of bed 3-4 times (and due to my roll I was the first call, if anyone got woken up, I did, and then had to wake anyone else needed). In my 7 months in the new job it hasn't happened yet.
When everything is on fire, it feels obvious to me that asking your $x00k employee to put it out isn't unreasonable. What is unreasonable is making that the plan instead of having robust fire-prevention systems and making that the exception.