She had her resignation letter drafted before we even knew there was a problem. This is what the exit interview taught us about warning signs we missed.

The resignation email arrived on a Monday morning, polite and short, the kind that tells you the decision was made weeks ago and the notice period is a formality. We asked for one conversation before she left. What she told us reshaped how we run on-call.

The pattern we couldn't see from the outside

On paper her on-call load looked normal — same number of shifts as everyone else, page count within range. What the dashboards didn't show was that four of her last six shifts had landed on weeks with a major release, meaning her "quiet" rotation slot consistently absorbed post-deploy instability nobody had planned for. The schedule was fair by the metric we tracked and unfair by the one that mattered.

"Every time I looked at the calendar, my week had a release in it. I stopped believing 'random rotation' was actually random."

What we built after she agreed to stay

She stayed, on the condition that we fix the scheduling blind spot, not just for her. We added release-week weighting to the rotation generator so it actively balances deploy-adjacent load instead of ignoring it.

rotation_generator_config:
  fairness_dimensions:
    - raw_shift_count       # existing
    - page_count            # existing
    - release_week_overlap  # NEW — weeks containing a scheduled major release
    - post_incident_week    # NEW — weeks immediately following a P1/P2
  rule: no engineer may draw >2 high-load dimensions in any rolling
        8-week window without manual override + manager sign-off

What almost losing her taught us

Fairness metrics that only count shifts and pages miss the texture of the work. Two shifts are not equal if one sits during a stable quarter and the other sits during a migration. We now review the rotation generator's fairness dimensions every two quarters and ask on-call engineers directly, not just the dashboard, whether the schedule feels fair — because we'd have kept trusting a metric that was wrong if she hadn't told us in person.

  • Shift-count and page-count fairness can both look fine while load is badly unbalanced in ways that don't show up in either metric.
  • Weight rotation generators for release weeks and post-incident weeks, not just raw shift and page totals.
  • Ask on-call engineers directly whether the schedule feels fair — dashboards miss texture that a five-minute conversation catches immediately.