Support teams know a particular kind of tiredness. It is the tiredness of being the person everyone calls first. When the same one or two engineers take every escalation, every awkward customer and every night-time page, they burn out, and the knowledge of how things really work stays locked in their heads. This how-to sets out a clear sequence for fixing that in a DevOps support team: rotate the hard jobs on purpose, with proper support around each turn, so load and skill both spread. Take the steps one at a time, and expect none of them to need more than an afternoon.
The steps assume a small to medium team, but they work for larger groups too. If you want to see how we think about operations support more broadly, our overview of DevOpsSupport consulting, support and training gives the wider picture of the kind of teams we work with, from startups to enterprise groups.
Before you begin
You need three things: a shared calendar, a place to keep short notes and the agreement of the team lead that this is worth a month of trying. You do not need new software, a budget or a consultant. You also need to promise people that the aim is fairness, not surveillance. A rota introduced as a way to catch mistakes will fail on the first day. A rota introduced as a way to share weight will usually be welcomed.
Step 1: Write down the hard jobs
Gather the team for twenty minutes and list every recurring duty people dislike. Typical entries are the first response to a service alert, the escalation from an unhappy customer, the unloved maintenance window and the cleaning up of old, undocumented systems. Ask each person which duty they would happily never do again. The honest answers are your starting material. Do not argue with anyone’s list.
Step 2: Find who carries them now
Next to each duty, write the names of the people who actually handle it today, not the names on any official chart. The pattern is almost always lopsided. If one person’s name appears beside most of the list, you have found the reason your team feels strained, and you have the evidence to explain it kindly to everyone else.
Step 3: Choose one duty to start with
Do not rotate everything at once. Select a single duty, ideally one that is painful but not catastrophic if handled imperfectly. A good first choice is often the first response to routine alerts during working hours. Leave the most delicate, high-risk work for later, once the habit is established.
Step 4: Describe what good looks like for that duty
Write half a page. Cover what the person on duty is expected to do, what they are not expected to do and when they should ask for help. A newcomer should be able to read it in five minutes and know where they stand. Keep the language simple. Where useful, link to your team’s existing guides on the systems involved.
Step 5: Build a shadow-then-support path
Nobody should meet a hard duty cold. Use a three-stage path.
- Watch. The newcomer follows the experienced holder through a full turn, asking questions along the way.
- Hold with a backup. The newcomer takes a turn, with the experienced person available to advise but not to take over.
- Hold alone. Once comfortable, the person takes their turn without a named backup, though the team remains reachable.
This path protects customers and protects people. It also converts every turn into training. It resembles the progression many engineers follow as they grow, a topic touched on in our guide to DevOps role titles and the career paths between them.
Step 6: Publish the rota where everyone sees it
Put names and dates in a shared calendar several weeks ahead. Each person should be able to see their next turn without asking. Keep the rota in one visible place, and keep changes visible too. When someone swaps a turn, they say so in the team’s channel. Surprises are what turn a rota into a source of resentment.
Step 7: Weigh the load, not just the turns
Count a heavy week as more than a quiet one. If a person handled a long incident or a run of difficult calls, their next duty should be lighter. Write this rule at the start so it does not look like favouritism later. Also give people reasonable notice and respect their circumstances: caring responsibilities, travel and planned leave.
Step 8: End every turn with a short note
The note is a few lines: what was unusual, what you changed, what is still open and anything you would tell a colleague about the system. Store the notes together and read them at the monthly review. Over time they reveal recurring trouble spots, and they help new colleagues absorb what the team has learned.
Step 9: Leaders take turns too
This step is quick to state and hard to do. Senior engineers and managers should hold hard duties in the rota, at least sometimes. Their involvement shows the rota is fair, keeps them in touch with the real work and gives juniors a chance to see how experienced people handle pressure. Teams where leaders exempt themselves usually find the rota decays within a few months.
Step 10: Review after a month
Hold a short conversation. Ask three questions: what felt unfair, what surprised you and what should we change? Adjust the weights, the notice period or the shadow length. Only after the first duty feels stable should you add a second. Repeat the cycle until the hardest jobs are all shared.
A short worked example
Suppose a support team of five finds that Marcus handles most first responses and Leena handles almost every escalation. They pick first response as the starting duty. Marcus writes the half page describing it. Priya shadows him for a week, holds a turn with him as backup the following week, and then goes solo in week three. Tom follows the same path. Heavy weeks are counted. At the one-month review, Marcus says he slept better, Priya says she finally understands the monitoring she had only seen from outside, and the team picks escalations as the next duty. Leena, relieved, becomes the guide for that stage.
Common problems and quick answers
- The old expert keeps taking over. Agree that anyone who steps in tells the group afterwards. This keeps learning visible and gently discourages the habit.
- A turn goes badly. Treat it as information. Ask what the system or the guidance lacked, fix that and move on without blame.
- Someone is nervous. Extend their shadow period. Confidence follows exposure, not lectures.
- The team is too small. Count heavy weeks carefully, plan leave early and consider outside support for the thinnest periods.
Showing the outside world what you do
A byproduct of a healthy rota is better evidence of your own abilities. People who have held several different duties have more to say about their experience, and that makes for stronger professional profiles. If you are building one, our walk-through of assembling a strong DevOps engineer portfolio shows how to present practical experience convincingly.
What success looks like
You will know it is working when the signs are ordinary. Colleagues take leave without apology. More than one person can explain how a troublesome service behaves. New starters are not afraid of their first turn. The person who used to take every escalation has time to learn something new. None of these require dashboards, only attention.
The hardest jobs in support will always exist. What changes is who understands them and how heavily they weigh on any single person. Write the list, pick one duty, set up the shadow path, publish the rota and review in a month. Do that, and the knowledge that once lived in one head will belong to the whole team.
