Nobody Quits Over On-Call. Except They Do.

On-call never shows up in exit interviews. But across half a dozen consulting engagements, I've watched it quietly hollow out engineering teams. The pattern is always the same, and it's always fixable.

In every exit interview I've ever read — and I've read more than I'd like during consulting engagements — "on-call" appears exactly zero times as the reason someone left. People write "career growth," "compensation," "looking for new challenges." The polite things.

But I've sat across from enough departing engineers to know what actually pushed them. It wasn't the salary. It wasn't the tech stack. It was the 2 AM page for a service they didn't write, followed by a morning standup where nobody asked how they were doing, followed by another week of the same rotation because the team was too small to give them a real break.

On-call is rarely the reason. It's almost always the last straw.

The pattern I keep seeing

Over the past two years, I've worked with six teams that had what I'd call on-call problems. Not alert noise problems — I've written about that before — but structural problems with how rotations were designed and what they cost the people in them.

The pattern is remarkably consistent. A team starts with five or six engineers and a reasonable 1-in-5 weekly rotation. Somebody leaves. Now it's 1-in-4. Management hires, but hiring takes three months. In the meantime, another person leaves — partly because the rotation just got worse. Now it's 1-in-3.

At 1-in-3, on-call stops being a periodic inconvenience and starts being a defining feature of your job. You're either on call, recovering from being on call, or dreading the next round. I've seen teams get stuck in this spiral for over a year.

One client — a mid-size SaaS company running about 40 microservices — had a platform team of four when I arrived. Four people, on call for infrastructure that served 200 engineers. They'd been a team of seven eighteen months earlier. Every person who left cited "better opportunity" in their exit interview. Every person I spoke to informally mentioned the on-call rotation within the first two minutes.

What makes a rotation bad

It's not just the frequency, though frequency matters. The worst rotations I've seen share a few traits:

No escalation path. The on-call person is expected to handle everything, from a certificate expiry to a full database failover. When a junior engineer inherits the same rotation as someone with ten years of distributed systems experience, you're not running an on-call schedule — you're running a stress test on your least experienced people.

No protected recovery time. You were up until 3 AM dealing with an incident? Cool, see you at standup at 9. This is shockingly common. One team I worked with had no formal policy on post-incident rest. Engineers just quietly took a slow morning and hoped nobody noticed.

No separation between "your services" and "everything else." At the SaaS company I mentioned, the platform team was on call for services other teams had deployed but refused to own overnight. The platform engineers were debugging business logic they'd never seen, in languages they didn't regularly use.

No compensation, no acknowledgment. Not even an extra day off. Not even a "thank you" in the team channel. I'm not saying on-call needs to come with hazard pay, but when it comes with literally nothing, people notice.

The fix isn't complicated

None of the teams I worked with needed exotic solutions. They needed someone to say out loud what everyone already knew.

At the SaaS company, we did three things. First, we established service ownership with teeth: if your team deployed it, your team was on call for it, no exceptions. The platform team's rotation went from covering 40 services to covering 11. Second, we wrote an explicit policy that anyone paged after midnight got a half-day the next day, no questions asked, no approval needed. Third, we added a secondary on-call tier — a senior engineer available for escalation, not primary response. The secondary was on a longer rotation and got paged maybe once a month.

Within two months the platform team's page volume dropped by 60%, and the pages they did get were actually in their domain. Within four months they'd hired two new engineers — and for the first time in a year, nobody was interviewing elsewhere.

On-call as a signal

I've started using on-call health as a diagnostic when I join a new engagement. Not the tooling, not the alert rules — the human side. How many people are in the rotation? What happens after a rough night? Who's responsible for what? Do people trade shifts willingly, or is every swap a negotiation?

The answers tell me more about a team's real health than any architecture diagram or sprint velocity chart. A team that treats on-call as a shared responsibility and protects the people in the rotation is almost always a team that ships well and keeps its engineers. A team that treats on-call as an invisible tax — something everyone endures and nobody talks about — is usually bleeding people and doesn't fully understand why.

If your best engineers keep leaving and your exit interviews keep saying "career growth," maybe ask them about their last on-call week instead.