On-call is the workplace tradition with the worst public-relations problem in engineering. Half the team treats it like a tax. The other half treats it like a hazing ritual. Both teams are wrong, and the fix is not complicated, just unglamorous.
The deal
A humane on-call rotation has three properties. First, the engineer on call is not also expected to ship a feature that week. They're a firefighter; you don't expect firefighters to also paint the firehouse. Second, an alert at 3 a.m. earns you the next morning off, no questions, no Slack message of approval needed. Third, every page becomes a ticket, and every ticket becomes a decision: is this alert telling us something we need to know, or is it noise we've been tolerating?
The cultural fix
The team treats the on-call engineer like the most senior person in the room that week. They are. They have more context on what's actually breaking than anyone else. Their judgment about what to fix first should be respected without debate.
And the manager runs the on-call retro every two weeks. Not the engineers. The manager. Because the unglamorous truth about on-call is that most of its pain comes from decisions made months earlier — service ownership, alert thresholds, runbook quality — and only management can change those.
Get those three pieces right and on-call stops being the rotation everyone dreads. It becomes the week you learn the most.