Every team that runs automated operations eventually discovers an awkward truth: the smarter the tooling gets, the more the remaining human jobs concentrate on a few people. Automation absorbs the easy incidents, and what is left is the strange, the ambiguous and the urgent. Whoever carries that residue is carrying the on-call rotation in everything but name. This comparison looks at three common ways to organise it, judged on the things that matter once the novelty wears off: how much strain each model puts on individuals, where knowledge ends up, and how it behaves when someone is ill or leaves.

What an on-call rotation is really distributing

Most descriptions of an on-call rotation talk about hours. That is the visible cost, but it is not the whole bill. Three different things are being shared, or hoarded, depending on the model you choose.

• The interruption. Being the person who is woken, pulled out of a meeting or kept from dinner. This is the burden people complain about first.
• The judgement. Deciding in the moment whether a machine-generated suggestion should be trusted, overridden or escalated. This is the skill that grows with exposure.
• The aftermath. Writing up what happened, chasing the follow-up work and explaining it to colleagues who were asleep. It is unglamorous and it is where most learning is consolidated.

A model that spreads only the interruption but keeps the judgement and the aftermath with one expert has not really rotated anything. Keep that test in mind as we go through the options.

Model one: the standing expert

The simplest arrangement is to let your most experienced engineer carry the pager, with others stepping in as backup when asked. It feels efficient. That person already knows the estate, resolves problems quickly and rarely needs to escalate. In a young team with a tiny footprint, it is often how things start, and there is nothing shameful in that.

The costs arrive slowly. Fatigue is the obvious one, but the quieter cost is dependence. Every incident handled by the expert is an incident nobody else learned from, so the gap between that person and everyone else widens with each month of success. When the expert takes leave, the team discovers that the machine-assisted triage it relies on was always being interpreted by one brain. Colleagues also become reluctant to challenge the system’s output, because they have never had to defend a decision about it.

Where this model genuinely works is for short, bounded periods: a launch window, a migration weekend, a stretch when the stakes are high and the expert volunteered. As a permanent policy, it trades resilience for speed, and the trade tends to be invisible until it fails.

Model two: the plain round-robin

Round-robin is the model most people mean when they say rotation. Each engineer takes a turn in a fixed sequence, usually a week at a time, and the baton passes on a known day. Its great virtue is fairness you can see. Everyone knows when their turn is, can plan around it, and can trade a week with a colleague when life intervenes.

For the knowledge question, round-robin is clearly better than the standing expert, because every person eventually meets the odd incident first-hand. Its weakness is that it treats unequal people as equal. A newer engineer in their first turn may face a night they are not ready for, and the team’s response is to lean on the expert informally, which quietly recreates model one inside model two. Teams also tend to forget that a week is a long time: the rhythm suits people with flexible home lives and is punishing for those with caring duties, unless trades are made easy and genuinely normal.

To make round-robin work in a team that leans on automated suggestions, add two small habits. First, pair the newest person with a shadow for their first couple of turns, with the shadow listening in rather than driving. Second, make the aftermath a rotating job in its own right, so the person who wrote up the last incident is not always the person who was on call for it. A straightforward rotation of write-ups gives you a surprisingly good picture of who understands what.

Model three: tiered rotation with a deliberate escalation path

The third model splits the burden into layers. A first line, drawn from a wider pool, takes the initial contact and handles what the tooling and a well-understood checklist can resolve. A second line, a smaller group, takes the harder problems. Both lines rotate, but at different cadences: the first line changes often and keeps turns short, while the second line changes more slowly and is staffed by people who have completed a few first-line turns.

This is the model that most naturally suits an operations team built around AIOps tooling. The first line is where machine-generated recommendations are met by people, and the structure gives juniors a ladder rather than a cliff. Because second-line turns are earned through first-line experience, the skills move up the team rather than pooling at the top.

Its weaknesses are organisational. Tiering needs enough people to fill both layers without anyone being permanently stuck in one of them. In a team that is small, it can collapse into the standing expert again, simply with extra ceremony. And the escalation path must be respectful: if first-liners feel that escalating is a failure, they will hold on to problems too long, and if second-liners feel they are being bothered, they will stop answering with goodwill. Leaders have to say out loud that escalation is a normal use of the system.

Comparing them honestly

Set side by side, the three models line up like this on the criteria that matter most.

• Strain on individuals. The standing expert is worst; the round-robin is fair on paper and uneven in practice; the tiered model is gentlest on newcomers and heaviest on the second line, which is why that line must rotate too.
• Where knowledge accumulates. The standing expert hoards it, round-robin spreads it thinly and slowly, and the tiered model moves it upward in steps.
• Resilience to absence. The standing expert is brittle, round-robin copes well if trades are easy, and the tiered model copes best provided the second line is not too small.
• Setup effort. The standing expert needs none, round-robin needs a calendar and a trading habit, and the tiered model needs agreed boundaries and honest conversations about escalation.

No model wins everywhere. What the comparison does show is that the hard jobs follow whichever structure you choose. If you do not decide how they are shared, they will be shared by default, and the default is usually the person who is best at them.

Choosing for your own team

A few questions help you pick without turning the decision into a research project.

1. How many people can realistically take a turn? If the honest answer is two, no rotation model will rescue you, and the right move is to widen the pool first.
2. How varied are your incidents? Where most are routine, a tiered model rewards the investment. Where most are novel, a plain round-robin with strong shadowing may be easier to run.
3. Who is not on the list who should be? Platform engineers, data specialists and the people who tune the models often avoid the pager because their work is considered too specialist. Their absence shifts the load onto everyone else.
4. What happens the morning after? A rotation that ignores recovery time, even informally, is just a longer shift.

Teams that have outgrown their own experience sometimes bring in outside help for this kind of design question. DevOpsSupport, a consultancy that supports operations teams in the cloud, works with startups and larger organisations on the practical side of running systems, from advice to courses. An outsider can also make the unspoken explicit, which is often half the battle.

Keeping the machine in its place

One more consideration is specific to AI-assisted operations. When suggestions arrive from a model, it is tempting to treat the person on call as a courier for its output. That is the fastest route to disengagement. The rotation should instead make clear that the human on call owns the decision, which means they need the right to disagree and the time to say why. Our own piece on supporting IT decisions with machine assistance makes the same point from the tooling side: the better the recommendation engine, the more important it is that people stay practised at judging it.

The same logic applies to the longer view. Anything that predicts trouble before it arrives, such as the ideas discussed in the article on forecasting equipment and system failures with learning models, only pays off if somebody on the team is paying attention to what it says and understands why. Rotating the job of reviewing those predictions, rather than leaving it to one enthusiast, keeps the practice alive when the enthusiast moves on.

A sensible way to start

Do not redesign everything at once. Pick the model that fits your current headcount, run it for a few cycles, and ask the team three plain questions at the end of each one: what was hardest, what would you want to have known beforehand, and who could have taken a turn but did not? The answers will tell you whether to widen the pool, add a shadow, or introduce a second line.

Above all, keep the rotation visible. A calendar that anyone can read, a written trading rule and an honest note about who is shadowing whom do more for morale than any perk. The aim is not to make on-call pleasant; it is to make sure the unpleasant part is shared, understood and survivable, so that the knowledge it produces is held by everyone rather than by whoever happened to be awake.