Whenever we run a session on DevOps teamwork in the Netherlands, the same questions come up afterwards, usually in the corridor and usually a little quietly. How do we stop the same person being woken at night every time? Is it normal to dread being on call? Can a junior really take a turn? This page gathers the questions we hear most about rotating the hardest jobs in a DevOps team, with answers in plain language. Skim the headings and jump to whatever worries you most.
What do we mean by the hard jobs?
Every team has duties that are tiring, unglamorous or stressful. The usual suspects are the first response to a failing service, the late-evening deployment, the thankless maintenance chores and the conversation with a stakeholder who is frustrated. They are hard not because they are intellectually difficult but because they interrupt life and offer little thanks.
Why do they end up with the same people?
Mostly through kindness and habit. The person who is quick, calm and available gets asked once, does it well, and is asked again. Nobody plans the pattern. It grows because it feels efficient, and efficiency is hard to argue with. The problem appears later, when that person is exhausted, or leaves, and the knowledge goes with them.
What is a rotation, in simple terms?
A rotation is a published schedule that moves a duty from one person to the next in a fair order. The schedule is visible to everyone. Each person knows when their turn is, who is backing them up and what the rules are. That is the entire idea, and it needs surprisingly little equipment: a shared calendar and an agreement.
Is it normal to dread being on call?
Yes, and it is nothing to be embarrassed about. The dread usually comes from uncertainty: not knowing what might happen, not knowing whom to ask, not knowing whether a mistake will be held against you. A well-designed rotation addresses these directly. You have a shadow period beforehand, a named person to call and a team culture in which questions are welcome. Most of the dread fades once the first turn passes without disaster.
Can a junior really take a turn?
With support, absolutely. The path is gradual. First the junior watches an experienced colleague through a whole turn. Then they take their own turn with that colleague as a backup who answers questions but does not take over. Only later do they hold a duty with less support. Career guides such as a map of growing from junior to senior DevOps engineer often mention this staged exposure, because it is how confidence is built in practice.
Will rotating slow us down?
For a few weeks, a little. New people ask more questions and move more carefully. After that, the opposite tends to happen. Work stops queuing behind one person, reviews improve because more people understand the system, and holidays stop causing alarm. Think of the early slowdown as an investment with a visible payback.
How do we keep it fair?
Equal numbers of turns are not the same as fair turns. A few simple adjustments help.
- Count a very busy week as heavier than a quiet one, and give that person a lighter next turn.
- Allow swaps, but announce them to the group so nobody is surprised.
- Give people notice, especially those with caring duties or long journeys.
- Let experienced staff take hard jobs too. If leaders exempt themselves, the rest will notice.
What should we write down at the end of a turn?
Keep it short. A few lines covering what was unusual, what you changed and what is still unresolved. The note is for the next person, and for the team later when someone asks why a thing is set up the way it is. Over months these notes become a quiet library of experience, and each one takes barely a coffee break to write.
What does a good first turn look like?
Picture Sanne, who joined a team in Utrecht a few months ago. In week one she watches Bram handle the first response and asks him why he checks one particular log before anything else. In week two she holds the duty herself while Bram stays reachable. A minor alert arrives on Wednesday; she follows the steps she saw, asks Bram one question and closes it within the hour. Friday she writes four lines of notes. Nothing dramatic happened, and that is the whole point. A good first turn is uneventful and instructive.
Does this matter for my career?
Very much. Engineers who have taken supported turns at difficult duties learn how systems fail in the real world, and employers value that. It also demonstrates teamwork and calm, two qualities that matter at every level. If you are still planning the shape of your growth, an overview of the new pathways open to software developers who learn DevOps shows how broad the options are, and the habit of sharing hard work features in many of them.
What skills should I build alongside?
Learn to write clearly and teach patiently. Learn to stay steady when an alert arrives. And study the technical foundations that make a rota survivable: sensible monitoring, repeatable deployments and decent logging. A broad outline of how these pieces fit together appears in a roadmap for a DevOps engineer’s skills, projects and growth, which makes a good companion while you are building experience.
Can a small team do this?
Yes. A pair of engineers can alternate weeks of first response, and a team of three can share the unloved maintenance task and the stakeholder conversations as well. What small teams must do is be honest about limits. Two people is demanding, so plan leave early, accept that some weeks will be heavy and consider outside help for the periods when the team is thin.
When should we bring in outside help?
If your team cannot cover its duties fairly, or if habits are too deeply set to change from inside, an outside view can help. Organisations such as DevOpsSupport provide consulting and support for DevOps and cloud operations, and teams in different regions use that kind of help to establish shared duties and fair cover. Whether you choose that route or keep everything in-house, the principle remains the same.
What if somebody refuses to take a turn?
Start by listening. Refusal usually hides a reason: fear of failing in public, a difficult home situation, or a past experience of being blamed. Ask what would make a turn feel safe, then adjust. Perhaps a longer shadow period, a lighter first duty or a different time of day. If the reluctance is about fairness, show how weights and swaps work. Forcing a rota on an unwilling colleague without hearing them out tends to produce silent resentment, which is worse than an open conversation.
What mistakes should we avoid at the start?
- Starting with the riskiest duty. Begin with something calm.
- Skipping the shadow period because everyone is busy.
- Treating mistakes as personal failings. Use them as information.
- Letting the old expert quietly take work back. If they step in, they should tell the group afterwards.
- Forgetting to review. After a month, ask what felt unfair and adjust.
How will we know it is working?
The signs are modest and human. People take holidays without apologising. More than one person can explain a tricky part of the system. New colleagues stop being afraid of the pager. Nights are quieter for the person who used to carry them all. You do not need a chart to notice these, though a monthly five-minute conversation about how the rota feels will confirm them.
What is the one thing to remember?
Hard jobs are survivable when they are shared, understood and written down. If you take a single step this week, make it the list of duties your team dislikes, put on a wall or a shared page where everyone can see it. Everything else follows from that honest list.