The Exit Interview Nobody Schedules: How On-Call Design Flaws Are Draining Your Senior Infrastructure Talent
Photo: tired engineer laptop night office on-call alert, via thumbs.dreamstime.com
When a senior infrastructure engineer resigns, the organization typically runs a standard exit process: access revocation, knowledge transfer sessions, a farewell email. What almost never happens is an honest accounting of why that person left — and in a meaningful share of cases across US enterprises, the answer traces back to the on-call rotation they lived inside.
The Arithmetic of Burnout
Consider the typical rotation at a mid-sized American company: one primary, one secondary, coverage spanning nights, weekends, and holidays. Alerts flow from a monitoring stack configured years ago by people who have since moved on. A single flapping switch can generate dozens of pages in an evening. None of them are actionable, but each one interrupts sleep.
Research from industry surveys, including Google's SRE work and subsequent studies from PagerDuty and the Ponemon Institute, has consistently linked after-hours paging to measurable declines in sleep quality, cognitive performance, and job satisfaction. Engineers describe a state of permanent low-grade dread — the Sunday-evening feeling that never quite lifts. For staff-level engineers with a decade of tribal knowledge, the labor market offers an easy escape: remote-first roles, consulting engagements, or companies that treat operational sustainability as a design requirement rather than an afterthought.
The exit interview rarely captures this. Engineers leaving over on-call conditions tend to cite "new opportunities" — a socially acceptable shorthand that lets everyone avoid an uncomfortable conversation about operational debt.
What Departure Actually Costs
The financial modeling of attrition usually focuses on recruiting and onboarding: a recruiter fee, several months of ramp time, the vacancy gap. For senior infrastructure roles, this understates the problem considerably.
The departing engineer takes with them the undocumented context that never made it into the runbooks — the reason the Dallas failover behaves strangely after a failback, which vendor's support queue actually resolves issues, why a particular legacy application cannot tolerate a routine patch cycle. Replacing that context takes the remaining team years, if it happens at all.
There is also a multiplier effect. When one senior operator leaves, on-call burden redistributes across a smaller pool, which accelerates fatigue among survivors, which drives the next resignation. Enterprises that lose two or three senior people from an operations team in a single year frequently enter a spiral that ends in either emergency consulting contracts or a managed-services arrangement that costs multiples of the salaries they were trying to preserve.
Diagnosing an Unhealthy Rotation
Most on-call dysfunction shares common symptoms, and IT leaders can audit for them directly:
-
Page volume without actionability. If engineers routinely acknowledge alerts without taking action, the monitoring configuration is generating noise, not signal. A useful benchmark: fewer than one in five pages should require a human response.
-
Single points of operational knowledge. If one person is the only responder who can resolve a category of incident, the rotation is structurally fragile regardless of how willing that person is.
-
Escalation chains that always reach the top. When secondary escalation means waking the same staff engineer every time, the rotation exists on paper only.
-
No recovery time. Post-incident rotations that place an engineer back on primary within a week guarantee cumulative fatigue. Recovery intervals need to be protected like any other capacity constraint.
-
Silent suffering. Engineers rarely volunteer that on-call is breaking them; they simply update their LinkedIn profiles. Anonymous rotation surveys surface problems before resignation letters do.
Redesign Before the Resignations
The fix is rarely more headcount alone. It is operational discipline applied to the alerting and scheduling layer:
Treat alert quality as a product. Every recurring non-actionable page should be triaged like a defect, with an owner and a remediation deadline. Teams that run quarterly alert audits routinely cut page volume by half or more.
Compensate and respect the interruption. US enterprises increasingly follow the model of paying for after-hours pages — not as a perk, but as an honest pricing signal. When each page carries a cost, managers suddenly develop an interest in alert hygiene.
Rotate the primary burden deliberately. Follow-the-sun scheduling, even across US time zones, shifts overnight pages to daytime hours for someone. Splitting primary and secondary duties, capping consecutive weeks on rotation, and enforcing blackout periods after major incidents are all structural interventions that do not require new hires.
Measure the rotation's health. Page counts per shift, mean time to acknowledge, and post-shift survey scores belong on the same operational dashboard as uptime and latency. A rotation that cannot be observed cannot be managed.
The Leadership Test
There is a straightforward question every CIO and VP of Infrastructure should be able to answer: who is on call this weekend, how many pages did they receive last weekend, and how many required real work? Leaders who cannot answer are managing an organization whose most critical operational function runs on hope.
Senior infrastructure engineers are not leaving because they cannot tolerate hard work. They are leaving because the work is structured in a way that makes their expertise feel like a punishment — an endless pager tax on the very people the enterprise can least afford to lose. Redesigning the rotation is cheaper than replacing the team, and the organizations that figure this out first will hold their institutional knowledge while their competitors post the job listings.