this post was submitted on 01 Oct 2024
788 points (98.4% liked)
Technology
58303 readers
16 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Those compensation requirements would basically make it financially impossible to have someone on-call or they'd just have to hire people for those hours and say they are normal working hours.
How would you force someone to take time off?
If I was their boss I would say something like "you're job is to stay home and do anything besides work for the next week, you will still be paid for this time". Easy.
As for the on-call stuff. Yes, that's the point. It should be unsustainable for a company to continually rely on their daytime programmers for frequent on-call alert handling.
If off-hours issues happen often, the company can hire an additional team to handle off-hours issues. If off-hours issues are rare, then you can depend on your daytime programmers to handle the rare off-hours issue, and know that they will be fairly compensated for being woken up in the middle of the night.
I've been at too many companies where an off-hours alert wakes up a developer in the middle of the night and the next day the consensus is "that's not good, but we'll have to fix the underlying issue after we finish implementing the new UI the design team is excited about". It's not right for a developer to get woken up in the middle of the night, and then the company puts fixing that on the backburner.
I'll say it again. It's about aligning incentives. When things that are painful for the worker are also painful for the company, that is alignment. Unfortunately, most companies have the opposite of alignment, if a developer gets woken in the middle of the night the end result for the company is that they got some additional free labor, that's pain for the worker, reward for the company; that's wrong.
Classic. Once I landed in a team who's been woken up every night, often multiple times a night for several years. The people left were so worn down, burnt out and depressed that it was obvious just by looking at them. The company has cut the team to the bone and the only people left were folks that didn't have the flashy resumes to easily escape. They had drawn up plans to fix the system years ago. BTW, none of that was disclosed to me until I had signed up and showed up for work and asked who are those miserable looking people over there. "That's your team" the man replied.
If this is happening, sounds like you have a shit-ass Product Manager (or no PM).
Signed, not a shit-ass Product Manager
While there are voluntary shit-ass PMs, you can only afford to be not a shit-ass PM because the org isn't squeezing you for all it can. Once it does, you'd have to make similar decisions. If you quit because you don't agree with the way things are going, a compliant shit-ass PM will take your place, or no PM, and the people would end up in the place the parent described.
Leadership definitely drives a lot, but even with bad leadership a PM can and should do a lot to help here. I spent 5 of my years of PMing with an operations org that drove every big decision and I still did everything I could to protect my devs. I ended up in major burn out from it multiple times, but I don’t regret it.
Alerts that are waking devs up in the middle of the night have a user impact too, and a PM can and should communicate that impact and risk to the business side as part of why it needs to be prioritized. Alternatively, there might be a reason that the UI change is ultimately more valuable, and it’s the PM’s job to communicate why that is the priority to their devs. If developers with a Product team ever truly believe the reason they’re building something is just “because [insert team here] is excited about it,” then the PM failed at a critical responsibility.
These are not the only options. Here are some others:
Something's telling me most orgs where 2 is an option would go with that. Related to that - increases in labor compensation is what forces companies to spend money on capital investment that increases productivity - read new equipment, automation, fixing broken shit, etc. If there are cheap enough slaves to wake up during the night, doing this investment is "low priority" (more expensive) and isn't done.