An On-Call Burnout Pattern We Fixed With One Process Change

A client's on-call rotation was, by the numbers, completely fair — six engineers, one week each, rotating evenly, same number of shifts per quarter for everyone. And yet two specific engineers were visibly burning out while the other four seemed fine, which didn't make sense against a schedule that looked identical for all six on paper.

What the schedule wasn't measuring

We pulled actual page volume and resolution time per on-call shift for the past two quarters, broken out by which engineer was on call, and the pattern that an equal-rotation schedule had completely hidden became obvious immediately: two specific services, both owned by a legacy subsystem nobody had fully documented, generated the overwhelming majority of middle-of-the-night pages, and those pages disproportionately required deep system-specific knowledge that only two of the six engineers actually had. Every other engineer's on-call week was quiet by comparison, not because the rotation favored them, but because they genuinely couldn't be paged into those systems at 3am and expected to resolve anything — so in practice, those two engineers got pulled in anyway, informally, on top of their own scheduled shifts, whenever anyone else's week hit one of those services.

An equally distributed schedule isn't the same as an equally distributed burden. The schedule measured shifts. It should have measured pages that actually required showing up.

The one rule that fixed it

Rather than rebalancing the rotation itself, which wouldn't have fixed anything since the knowledge gap was the real constraint, we split on-call into two explicit tracks: a primary rotation covering general pages across all six engineers as before, and a secondary 'legacy systems' escalation track covering just the two problem services, staffed only by the two engineers who actually had the context, compensated with extra on-call pay specifically for that track and an explicit cap on how many legacy-track weeks either of them could take per quarter.

• Made the informal, unpaid burden those two engineers were already carrying into an explicit, compensated, capped responsibility instead of an invisible tax on being the only people who understood a subsystem.
• Started a deliberate knowledge-transfer effort to get two more engineers comfortable enough with the legacy systems to join that track within two quarters, rather than treating the two-person bottleneck as permanent.
• Added page volume and after-hours escalation count as a tracked metric per engineer, specifically to catch this kind of hidden imbalance earlier next time, since an equal-shift-count schedule alone had completely masked it for two quarters.
• Gave both affected engineers the option to drop out of the general rotation's night shifts for one quarter as a direct burnout response, since the fix needed an immediate relief valve, not just a better long-term structure.

Both engineers' reported burnout symptoms improved noticeably within the following quarter, and neither left the team — which, given how specifically scarce their legacy-system knowledge was, would have been a genuinely expensive loss. The schedule had looked fair the entire time. Fair by shift count and fair by actual burden turned out to be two different measurements, and only one of them was being tracked.