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; pain for the worker, reward for the company, that’s wrong.
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.
“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”
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.
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; pain for the worker, reward for the company, that’s wrong.
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.
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.