Eight Ways to Rotate the Hard Jobs in a DevOps Engagement

Digital transformation programmes rarely fail because the technology is wrong. They fail because the three or four worst jobs in the programme land on the same three or four people, who then burn out, leave, and take the real knowledge with them. If you run or sit inside a DevOps consulting engagement, this list is for you: eight practical ways to rotate the hard jobs so the load, and the learning, spread across the whole team.

The advice is deliberately plain. Each item says what to rotate, how to start and the trap to avoid.

1. Rotate the legacy system duty

Every transformation has an old system nobody wants to touch: the batch job with no documentation, the ageing server in the corner of the data room, the integration that only one retired colleague understood. Left alone, one brave engineer becomes its permanent keeper.

Start by naming a monthly keeper and a deputy. The keeper handles any request that touches the legacy system, and the deputy shadows. Swap each month. The trap is giving this duty only to junior staff because it feels like grunt work. It is the best education in the building, so spread it across levels.

2. Rotate who faces the sceptical stakeholder

Every programme has a department head who doubts the whole effort. Usually the most diplomatic consultant ends up in that room every week, and wears out. Share the conversation. Brief each attendee beforehand, write a few lines afterwards, and rotate between client and consulting staff. People learn the objections firsthand and stop dismissing them as noise.

3. Rotate the on-call position for new platforms

When a new pipeline or platform goes live, the first responder duty tends to attach itself to whoever built it. That is an understandable habit and a dangerous one. Move on-call onto a published rota as early as possible, with the builders paired alongside the newcomers during the first rotation. The trap is rotating too early with no pairing, which turns the schedule into a source of fear.

4. Rotate the steering-meeting chair

Chairing the weekly progress meeting is quietly exhausting. It means chasing updates, keeping people on topic and calming tempers. Give the chair to a different person each week, with the previous chair coaching the next. Within a quarter the team understands how the whole programme fits together, because every lead has had to summarise it to others.

5. Rotate the unglamorous documentation pass

Someone has to read the notes, fix the diagrams and chase the missing explanations. When it is always the same careful person, everyone else stops writing carefully, because they know somebody will tidy it later. Rotate the pass weekly. The moment people know they will inherit next week’s mess, their own writing improves.

6. Rotate the difficult client request

Every engagement has a request that is awkward rather than technical: the change that arrives late on Friday, the scope question that is not quite a scope question. Decide in advance who takes the awkward request this week, and let that person make the call with a named senior backup. For practical background on how engagements are structured, this walk through a consulting engagement from first assessment to team enablement shows where these requests tend to appear.

7. Rotate the post-incident write-up

After something goes wrong, a written account is valuable and tedious to produce. If the engineer who was woken up always writes it, you reward the person already tired with more work. Rotate the author, with the responder available for facts. A fresh pair of eyes asks better questions, and several people end up understanding the failure.

8. Rotate the coach role itself

Consulting teams often elect one experienced person to explain things to everyone else, which mirrors the single-owner problem. Share the coaching role. Each month, a different team member takes responsibility for a topic they know well, runs a short session and answers questions. Teaching a subject makes you realise what you do not know, and that is a healthy discovery.

How to roll these out without chaos

Eight at once would be a mistake, so do not try. A sensible order looks like this.

1. Pick the duty that currently causes the most visible fatigue. Usually it is on-call or the sceptical stakeholder.
2. Write who holds it now, who will hold it next and the date of the swap, and put it where the whole team sees it.
3. Add a shadow period for newcomers and a named backup.
4. Count heavy weeks as heavier, so the next assignment is lighter.
5. Review after one month. Ask what felt unfair and what surprised people.

Resist designing a perfect scheme. A rough rota that people follow beats an elegant one that nobody reads.

A word on pace

Rotation changes how people feel about their week, and feelings need time. Expect grumbling in the first fortnight from people who liked being indispensable, and mild panic from those who suddenly hold a duty they have never touched. Both reactions pass. Keep the schedule steady, keep the shadow period honest, and resist the urge to rescue someone at the first wobble. Rescues teach the wrong lesson.

Why this matters for the business case

Executives sometimes treat rotation as a soft people topic. It is a risk topic. If the knowledge of a critical system sits with one person, the organisation carries a hidden dependency on that person’s health, mood and notice period. A programme designed to improve agility cannot be agile if it depends on a single set of shoulders. Material such as a strategic guide to using consulting support for enterprise agility makes the broader case, and a visible rota is among the more down-to-earth means of making it real.

What a rotated week looks like

Picture a six-person team on a month-three engagement. On Monday, Tomas chairs the steering meeting while Leila, last week’s chair, sits beside him and nudges him back on topic. Tuesday, Hana holds the legacy system duty and fields two requests, noting in the shared log that one of them exposed an undocumented dependency. Wednesday evening, Ravi is on call for the new platform with Tomas as backup, and nothing happens. Thursday, Leila takes the awkward client request, makes the call and tells the group why. Friday, someone different writes the short weekly note. Nobody has done more than a fair share, and everybody has touched something they would not otherwise have seen.

Common failures to watch for

• Rotating titles, not work. If the person on duty still asks the usual expert to do everything, nothing has changed. Ask who actually did the work.
• Making it punishment. If a duty is given as a penalty, people hide mistakes. Frame it as part of everyone’s growth.
• Skipping the handover note. Without a short note, each new holder starts from nothing and the learning evaporates.
• Exempting the senior people. The moment leaders opt out, everyone else notices. Seniors should hold the awkward jobs too, visibly.

Where outside support can help

If your organisation lacks the spare capacity to run a rota, or the habits are too entrenched, an external team can set the first cycle in motion. DevOps and cloud operations consulting and support firms, DevOpsSupport among them, work with startups and larger teams on round-the-clock support, and that experience is relevant when you want a rota that survives the first busy month.

A final checklist

• Can every person on the team name who is on duty this week?
• Can at least two people explain how the legacy system behaves?
• Has every lead chaired a meeting in the last quarter?
• Does every duty have a shadow and a backup?
• Does anyone on the team feel they cannot take leave? If so, that is your next duty to rotate.

Transformation is a long road, and long roads punish anyone who carries the same load the whole way. Share the hardest jobs early, write the schedule down, and the programme will go further with less drama.

Kabir Malhotra