Let’s do something slightly uncomfortable: an audit of who actually carries your team’s hardest jobs. Not who is supposed to, and not who the org chart says, but who really picks up the late-night page, the stuck deployment and the cranky stakeholder. If your answer is “mostly Sam and Priya,” this checklist is for you. Work through it with a coffee, tick what is true, and by the end you will have a clear idea of how to build a fair on-call rotation that spreads both the load and the skills.
Part one: find out who is carrying the weight
Grab the last three months of alerts, tickets or chat messages. You do not need fancy tooling; a spreadsheet will do. Then check each item below.
- List every out-of-hours alert and write down who handled it. Is one name on more than a third of them?
- List every deployment that went wrong. Who was called to fix it?
- Note every awkward conversation with a customer, a manager or another team. Who did the talking?
- Ask each person privately: which job would you quietly love never to do again?
If the same one or two names keep appearing, you have found your burnout risk. This is not a criticism of those people; it is usually a sign that they are skilled and generous. The point is that skill and generosity are being spent faster than they are being replaced.
Part two: check where the knowledge lives
Next, test whether your team could cope if those names were suddenly unavailable. Try these questions.
- Could someone else restart the key services without calling the usual person?
- Do the notes for the awkward systems exist, and are they readable by a newcomer?
- Has anyone other than the usual people actually taken a live incident this quarter?
- If you run machine learning workloads, does more than one person know how a failed retraining job is diagnosed?
That last point matters for data teams in particular. Work such as that described in this article on why operational discipline decides whether machine learning projects succeed tends to depend on specialised know-how: pipelines, model versions and monitoring quirks. Specialised knowledge is also the easiest kind to hoard by accident, which is why the pager for ML systems often lands on a single person.
Part three: design the rotation
Now build the schedule. This is the actionable bit, so keep it practical.
- Choose the pool. Everyone who can safely respond, plus anyone who could be trained within a month.
- Choose the cycle. A week is common; longer cycles give more continuity but weigh more heavily. Pick what your people can sustain.
- Add a second line. A backup person who can be reached when the first does not know the answer. This is where veterans earn their place without carrying the entire load.
- Include the dull jobs. The incident summary, the ticket hygiene and the post-event cleanup rotate with the pager.
- Publish the calendar. In a place everyone can see, with swaps announced openly.
- Set the handover habit. A short note at the end of every shift, read at the start of the next.
What a typical audit uncovers
Run the exercise once and a few surprises usually surface, whatever the team. Some of them may sting a little, since they point at habits everyone shared. The busiest person is often not the most senior one; it is the person who happens to be least able to say no. Some of the “hardest jobs” turn out to be small and repetitive, such as certificate renewals or a flaky job that needs a nudge every few days, and could be fixed once and for all. Others are social rather than technical, like explaining a delay to an impatient customer, and nobody had thought of them as on-call work at all. Writing them down makes them visible, which is the first step to sharing them.
You may also find that some people want more of the hard work, not less. A junior engineer eager to learn will volunteer happily if shifts are structured with a guide. Give them the chance. Rotation is not only about relief; it is also about opportunity.
Part four: plan the training
A rotation without preparation is a way to frighten people. Use this short list.
- Run a shadow week for every newcomer, with a guide present.
- Hold one calm practice session in which an invented fault is diagnosed together.
- Confirm each person has the access they need before their first shift, not during it.
- Agree what counts as an emergency, so a new person is never unsure whether to escalate.
It is worth reading how modern tooling can lighten the load, for example this overview of how AIOps platforms speed up problem resolution for IT teams. Tools like that can reduce the number of nights people are woken, but they do not remove the need to spread knowledge. Even with good automation, a human still has to understand what the automation is telling them.
A last note on tone: treat the audit as a look at the system, never as a ranking of people. If it turns into a hunt for who did too little, the quiet members will hide, and the honest picture you wanted will disappear.
Part five: protect people
- After a shift with several night pages, give the next morning off or lighten it.
- Avoid scheduling the same person for back-to-back heavy weeks.
- Let people mark holidays and family events before the rota is fixed.
- Recognise on-call work in reviews, so nobody feels it is invisible labour.
Part six: when you need extra hands
If your audit shows too few people to run a safe rotation, you have options. You can cross-train from adjacent teams, shorten the hours you cover, or bring in support. Companies such as DevOpsSupport, which pairs consulting with ongoing support for DevOps and cloud teams, exist for exactly this situation: helping startups and larger teams cover gaps and build habits that the in-house people can then sustain. The goal of outside help is to leave you more capable, not more reliant.
Part seven: review after a month
Finally, schedule the follow-up now, before the enthusiasm fades. At the one-month mark, repeat the quick tally from part one and ask these questions together.
- Did the distribution of alerts spread out?
- Who handled an incident for the first time, and what did they find hard?
- Which handover notes were most useful? Which were missing?
- Did anyone feel the load was unfair, and why?
- Which lessons reached new people this month, and which stayed with the veterans?
Wording for the team message
When you introduce the idea, keep the message short and warm. Something like: “We are going to share the hard jobs more evenly, starting next month. Nobody is being sidelined; the people who have carried the most will help the rest of us learn it. There will be a guide for every first shift, a note at every handover and a lighter morning after a rough night.” People tend to respond better to a plain promise of support than to a policy document.
Your scorecard in plain words
You do not need numbers to read your results. If the same names appear everywhere, the knowledge is in a few heads and nobody else has handled a real incident, you have work to do, and the rotation above is your route. If the load is already spread and notes exist, you are in good shape, and your next job is to keep the habit alive when the team grows or changes.
Either way, put a date in the diary for your first rotation meeting this week. The best time to share the hard jobs was before anyone was tired. The second best is now, while the people who have carried the pager are still glad to teach what they know.