4 ms·

Personally, I also ask more questions about on-call: - is there a SLO? - what is the schedule? 24h is no go for me. - is non-business hours on-call compensat

by rednum 4y ago

Personally, I also ask more questions about on-call: - is there a SLO? - what is the schedule? 24h is no go for me. - is non-business hours on-call compensated (even when there are no pages)? In particular, I strongly believe we (as profession) should push more the employers for the last point. Being oncall during weekend means I need to seriously adjust my plans; need to have corporate devices somewhere close, etc. In particular this also means I don't fully disconnect from work if I have to carry laptop/phone with me. This kind of stress slowly accrues long term. All in all: staying alert for oncall is some sort of work. A physical security guard gets paid for keeping an eye on things even when nothing happens; it's startling that so many devs don't.

tomerbd 4y ago
I would go further and ask for a day off after each on call shift
bartvk 4y ago
That's a very good point. I always ask when they last worked in the weekend, but I didn't consider work expecting you being on-call without mentioning it.
neogodless 4y ago
Never heard of SLO before, but I assume you mean this? https://www.bmc.com/blogs/slo-service-level-objectives/ https://www.bmc.com/blogs/slo-service-level-objectives/ (I've also never done on-call!)
- rednum 4y ago
  Kinda. In this context I mean "response SLO" - how much time you have between receiving the page and starting debugging stuff. I think it's also important to clarify; I've been on rotations with response SLO ranging from 5 through 30 minutes to unknown: literally my manager couldn't answer the question "so how fast do you expect me to react" (in hindsight, that was a pretty big red flag about how team approaches production that I missed).
llbeansandrice 4y ago
I agree. I think on-call is a big gotcha of the industry and different companies I've been at wildly succeed or fail at this. Some of it can be more team-driven even if corporate isn't on board. Good-ish example: - On-call T1 was mostly business hours - T2 during off-hours/weekend - Decently large rotation so you're on-call less frequently than every ~6 weeks Bad Example: - Escalation goes to another team that likely doesn't know much about the system - T1 24hrs/day - Small team so on-call is fairly frequent Both of these are still not good examples though. There's no compensation for the on-call hours. The team in my "good" example recognized heavy on-call load and was okay with taking some time off after a heavy on-call week "off books" but that's flimsy at best. I think this would be a great case for a union personally. Engineers have done very well but I don't think there's enough desire to fix this without a centralized coordinator like a union.

by rednum 4y ago

tomerbd 4y ago

I would go further and ask for a day off after each on call shift

bartvk 4y ago

That's a very good point. I always ask when they last worked in the weekend, but I didn't consider work expecting you being on-call without mentioning it.

neogodless 4y ago

Never heard of SLO before, but I assume you mean this? https://www.bmc.com/blogs/slo-service-level-objectives/ https://www.bmc.com/blogs/slo-service-level-objectives/ (I've also never done on-call!)

rednum 4y ago
Kinda. In this context I mean "response SLO" - how much time you have between receiving the page and starting debugging stuff. I think it's also important to clarify; I've been on rotations with response SLO ranging from 5 through 30 minutes to unknown: literally my manager couldn't answer the question "so how fast do you expect me to react" (in hindsight, that was a pretty big red flag about how team approaches production that I missed).

llbeansandrice 4y ago

I agree. I think on-call is a big gotcha of the industry and different companies I've been at wildly succeed or fail at this. Some of it can be more team-driven even if corporate isn't on board. Good-ish example: - On-call T1 was mostly business hours - T2 during off-hours/weekend - Decently large rotation so you're on-call less frequently than every ~6 weeks Bad Example: - Escalation goes to another team that likely doesn't know much about the system - T1 24hrs/day - Small team so on-call is fairly frequent Both of these are still not good examples though. There's no compensation for the on-call hours. The team in my "good" example recognized heavy on-call load and was okay with taking some time off after a heavy on-call week "off books" but that's flimsy at best. I think this would be a great case for a union personally. Engineers have done very well but I don't think there's enough desire to fix this without a centralized coordinator like a union.