We built our first three rotations by feel. All three quietly failed the same way, for a reason simple arithmetic would have predicted.

Nobody teaches rotation math in engineering school, so most teams — us included — built their first on-call schedule by intuition: enough people that no one feels overloaded, seems reasonable, ship it. All three of our early rotations quietly failed within two quarters, and the failure mode was identical each time.

The formula we were missing

A rotation doesn't just need enough people to cover shifts. It needs enough people that a single absence — illness, vacation, a resignation — doesn't collapse fairness for everyone else. We were sizing rotations for the happy-path headcount, not for the headcount minus one person out.

minimum_viable_rotation_size (rule of thumb we now enforce)
  N = minimum engineers needed so that ONE person being unavailable
      for up to 3 weeks does not raise anyone else's shift frequency
      by more than 25%
  Practically, for a weekly primary rotation:
    N < 5  -> a single absence raises remaining load by 25%+  (fragile)
    N = 6  -> absence raises load by ~20%  (tight but survivable)
    N >= 7 -> absence raises load by <=17%  (resilient)
  We now require N >= 6 before a service goes into an independent
  rotation; below that, it shares a pool with an adjacent team.
"We had five people and thought that was plenty, until one went on parental leave and the other four suddenly had a much worse quarter than any of us had signed up for."

What changed once we did the math upfront

We now run this calculation before any new service gets its own independent rotation, and it has stopped at least four premature rotation splits — cases where a team wanted service-specific on-call before they had enough people to make it fair. Sharing a slightly larger cross-team pool a little longer beats standing up a fragile five-person rotation that fails the moment someone takes real time off.

The part that surprised us

Engineers preferred hearing "you're not big enough for your own rotation yet" explained with the actual arithmetic far more than a vague "not yet, trust us." Showing the math turned a discouraging answer into a concrete, achievable target headcount.

  • Size a rotation for one person being unavailable, not for the happy-path headcount — that's where fragile rotations actually break.
  • A rough rule of six-plus engineers per independent weekly rotation holds up better than intuition-based sizing.
  • Explain rotation-sizing math explicitly when telling a team they're not ready for independent on-call; a number is more persuasive than a feeling.