Kenji had been a build engineer for three years when his manager asked him an uncomfortable question: “Which part of your job could you not hand to somebody else tomorrow?” He thought for a moment and realised the honest answer was almost all of it. Every release weekend, every strange pipeline failure, every call from the customer-facing team, all of it ran through him. This is a story about how Kenji turned that realisation into a career move, and why learning to share the hard jobs in DevOps is one of the most valuable skills a working engineer can build.
The setting is a mid-sized software team in Yokohama, but the lessons travel to any workplace where reliability depends on a few tired people.
The hidden trap of being the reliable one
In many teams, and perhaps especially in cultures that prize diligence, the person who never complains becomes the person who gets everything. Kenji was praised for staying late on release nights. Nobody questioned whether the arrangement was healthy, because from the outside it was working. Releases went out. Problems were fixed. The dashboard stayed calm.
What no one saw was the cost. Kenji had stopped learning anything new, because every spare hour went to firefighting. His colleagues, shielded from release nights, had never developed instincts about how the pipeline fails. And the team’s plans quietly assumed that Kenji would always be available, which made any thought of his promotion, or even his holiday, a source of anxiety.
The skill that does not appear on a course outline
Technical training teaches you tools: containers, pipelines, monitoring, infrastructure as code. It rarely teaches you how to design your own working life so you do not become a bottleneck. Yet this is the skill that separates a good engineer from a trusted lead. A lead is not the person who does the hardest job best. A lead is the person who makes sure the hardest job can be done well by many.
Kenji decided to practise it. He drew up a modest plan and brought it to his manager, Ms. Tanabe, who had been waiting for someone to raise the topic.
The plan Kenji proposed
- List the duties. He wrote down the five jobs that most often interrupted his week: release nights, the first response to pipeline failures, the liaison with the support team, the monthly cleanup of old build artefacts and the explanation of every odd deployment to new hires.
- Choose one to start. He picked release nights, since they were the most draining and the most visible.
- Pair, then hand over a turn. Each colleague first sat beside him for a release, then ran the next with him available as backup.
- Write a short note. After each release the person on duty recorded what was unusual and what they would change.
- Count heavy turns. A difficult release counted for more, so the same person did not always draw the bad ones.
The first few weeks were awkward. Kenji found it painful to watch others take longer than he would have. A colleague named Aya made a configuration slip in her first solo release, and the group fixed it together before breakfast. Nobody was blamed, and the team added one line to their shared notes. By the second month, the nervousness had faded.
What changed in Kenji’s career
Something interesting happened. Because Kenji was no longer trapped by release nights, he had energy to study the parts of the work he had avoided: observability, cost awareness, the design of safer pipelines. His reading broadened. When he later described his progress in a review, Ms. Tanabe noted that he had turned a personal dependency into a team capability, which is exactly the sort of statement that supports a step up to team lead.
His colleagues grew as well. Aya, who had been quiet in meetings, became the team’s most patient explainer of deployment steps. Another engineer, Ren, discovered that he enjoyed the first-response duty because it taught him how every service in the company connected. Each person found a duty that fit and a skill that deepened.
If you are thinking about the direction of your own career, this pattern is worth studying. Articles such as a look at where DevOps work is heading in Japan and elsewhere suggest that roles are shifting from solitary specialists toward people who build shared practice, which is precisely what a rotation develops.
The human side: culture before schedules
A rota is only a calendar. What makes it succeed is the culture around it. Teams where people feel safe admitting a mistake adopt rotations easily. Teams that punish errors make rotations feel like traps. If your workplace sits closer to the second type, begin with trust, not timetables. The ideas in a hands-on guide to steering cultural change within DevOps teams are a good partner here, since a change in schedule needs a change in attitude behind it.
Equally, a rotation is not only about engineers. Customer-facing colleagues benefit when more people understand how the delivery system behaves, because answers to their questions become faster and calmer. That link between internal sharing and external satisfaction is explored in a discussion of how modern delivery shapes the customer’s experience.
Skills to build if you want to lead a rotation
- Clear writing. Short, plain handover notes are worth more than long documents nobody reads.
- Patient teaching. You will repeatedly explain things you find obvious. Practise doing so without sighing.
- Fair judgment. Weigh heavy and light weeks sensibly, and be seen to do so.
- Calm under interruption. A rota exists because things go wrong. Learn to respond without drama.
- Willingness to step back. The hardest skill is letting someone else struggle productively.
A note for those starting out
If you are a student or junior engineer, ask to shadow the duties your seniors dread. It shows maturity and teaches you quickly. Many teams are delighted when a newcomer volunteers for a supported turn of first response, because it tells them someone is willing to share the load. Companies that support operations as their business, such as DevOpsSupport, a consultancy that supports teams with DevOps and cloud operations, exist because many teams cannot cover every duty alone, which is a useful reminder that sharing operational work is normal and professional.
The conversation with his manager, a year on
Ms. Tanabe later told Kenji what had impressed her most. It was not the technical changes. It was that he asked for the rotation before anyone forced it. Plenty of engineers wait until exhaustion makes the request for them, and by then goodwill is thin. Asking early framed the change as leadership, not complaint. She also noticed that he never described the old arrangement as anyone’s fault. He called it a habit the team had slid into, and offered a gentler habit to replace it. If you ever need to propose something similar, borrow that tone. It keeps colleagues from feeling accused and makes the plan feel like an invitation.
He also kept a small page of his own, listing which of his skills he had passed on and to whom. When review season arrived, that page was his evidence. Careers grow faster when you can point to what you taught, not only what you did.
Where Kenji is now
A year later, Kenji leads a small group. His first act as lead was to publish the rota for the whole quarter, with names and backups, and to take a week of leave that nobody had to apologise for. He says the proudest moment was a Saturday release that he heard about only afterwards, on Monday, from a cheerful message by Aya. The release had gone well. He had not been needed.
That is the quiet goal of this whole practice. You are not trying to be less useful. You are trying to make your usefulness something the team can keep even when you are somewhere else, and that is the kind of skill that moves a career forward without burning the person who holds it.