Ten Weeks Without an Owner: A DevOps Team Decision Story

Rajesh Kumar

Rajesh Kumar is a leading expert in DevOps, SRE, DevSecOps, and MLOps, providing comprehensive services through his platform, www.rajeshkumar.xyz. With a proven track record in consulting, training, freelancing, and enterprise support, he empowers organizations to adopt modern operational practices and achieve scalable, secure, and efficient IT infrastructures. Rajesh is renowned for his ability to deliver tailored solutions and hands-on expertise across these critical domains.

Picture a payments team at a mid-sized logistics company, which I will call Harbourline for the purposes of the story. Eleven engineers, a product owner and a security liaison, all capable and all on good terms. In March they decided to replace their ageing deployment tooling. By late May they had held fourteen meetings on the subject, produced a shared document with forty comments, and deployed nothing. This case study follows what happened, what finally changed, and what the pattern says about decision rights in DevOps teams.

The setting: a team with plenty of voices

Harbourline’s engineers shared a culture many readers will recognise. Decisions were taken “together”, meetings were open to anyone and disagreement was welcomed. On paper this is the collaborative spirit that modern delivery practice encourages. In practice, there was a gap: no one had ever stated what happens when the talking ends and the team still disagrees.

The deployment question split the group three ways. One camp wanted a managed pipeline service. A second wanted to extend the existing scripts. The third wanted to wait for a company-wide platform initiative rumoured to be arriving later in the year. All three positions were reasonable. None was winning, and none was losing.

Weeks one to four: the discussion that generated more discussion

Early meetings produced useful information. The team learned how many pipelines depended on the old scripts and which of them nobody dared touch. But the information never led to a decision, because each meeting ended with the same sentence: “Let’s get a bit more input.” Input arrived. The team lead asked for a comparison document, which was written, commented on and then superseded by a revised version.

Two things were quietly happening. First, the engineers whose preference was unpopular were becoming less vocal, which made the consensus look closer than it was. Second, the product owner, who needed a date, started to plan around the tooling work being late, which meant other commitments began slipping.

Week six: the question nobody had asked

The turning point was small. A newly arrived engineer, still unfamiliar with the team’s habits, asked during a meeting: “Who decides this?” There was a pause. The lead said it was a team decision. The product owner said she assumed the lead would decide. The security liaison said he had only been asked for input. Three people, three answers, and a chart that would have fit comfortably on a whiteboard: nobody owned the call.

The team lead, to her credit, did not defend the arrangement. She wrote three lines on the board: the name of the owner, a date and a rule. She proposed herself as owner, with the rule “I decide after hearing from everyone by Friday”, and set the date a week out. Nobody objected, partly because the relief was obvious.

Weeks seven to ten: what changed once the rule existed

The next consultation looked different. Engineers did not argue to win; they argued to be useful. Each person had a defined window to raise anything that would change the outcome, and the discussion stopped when the window closed. The security liaison, who had previously sat on the edge, raised a specific concern about credential handling that reshaped the shortlist. The advocate of waiting for the company platform was asked a precise question: what date would make waiting acceptable? He had no confident answer, which settled that point honestly rather than politically.

On Friday the lead announced her decision in a short written note: the outcome, the main reason, who was consulted and a review date in the autumn. She chose the managed pipeline service for new work, with the old scripts left untouched until a later review. Not everyone was pleased, but nobody was confused, and by the following Monday the first pipeline was being migrated.

Reading the story analytically

It is tempting to say Harbourline simply needed a stronger leader. The evidence points elsewhere. The lead had the authority all along; what the team lacked was a stated process that made it legitimate to use it. Once the rule was spoken, nobody felt overruled, because the rule had been agreed in advance. Cultural work of this kind is explored in this practical article on guiding a team through shifts in how it works together, and Harbourline’s experience fits its central point: people accept firm decisions more readily when the route to them is transparent.

The story also illustrates a structural point about teams that cut across roles. Where product, engineering and security all contribute, ownership cannot be inferred from job titles. The discussion of how mixed-discipline delivery groups are structured describes why this happens and how teams commonly respond. A short ownership statement per decision is the missing piece in many of the examples it describes.

What the team did afterwards

Harbourline adopted three habits and kept them. A list of open decisions, reviewed in the weekly meeting with the question “owner and date?” for each. A short decision note, stored beside the pipeline code. And a standing rule that the consulted list stays small, which kept consultations to a few days instead of a few weeks. Over the next quarter the team reported that its meetings were shorter and that disagreements, when they occurred, were about substance rather than about process.

A gentler side effect went unnoticed at first: people who had previously stayed quiet began to speak up, because the process guaranteed that their input would be weighed within a fixed window rather than lost in an endless thread. Risk discussions improved as a result, an effect consistent with the themes in the piece on managing risk across reliable and secure delivery.

A parallel in everyday life

Teams are not the only groups that lose weeks this way. Families who help a relative plan medical travel often discover the same stall, with dates, paperwork and money all waiting for somebody to take charge. The website BestHeartSurgery is a reading resource that sets out hospitals, destinations and services for people planning care abroad, and it describes itself as informational rather than a provider of treatment. A household using it would do well to appoint, early on, one coordinator for the non-clinical arrangements, with a date and a rule, much as Harbourline did.

Lessons to carry away

  • Open discussion is valuable only if it has a defined end.
  • Asking “who decides?” is a contribution, not an interruption.
  • An owner, a deadline and a stated rule convert opinion into outcome.
  • A short written record prevents the same debate from returning.

Next time your team finds itself in its fifth meeting on the same question, try writing three lines on the board. It cost Harbourline ten weeks to learn how little it takes.

Leave a Reply