At two in the morning, a support engineer stares at a failing service and a half-written proposal to change a configuration that could fix it or make things worse. Who approves it? The answer depends on the organisation, and the differences between organisations are larger than most people expect. This piece compares three common ways that DevOps support and managed-service teams settle decisions about changes and escalations, tells a short story about each, and suggests when each one earns its keep.

Model one: the single on-call approver

The first model is the simplest. For a defined category of change, one named person, usually the on-call lead, has authority to approve and proceed. They may consult a colleague, but nobody else needs to sign off.

I once heard about a small managed-services outfit run this way. Their on-call lead for the week could approve any change inside a documented boundary: restart a service, adjust a limit, roll back a release. If a customer’s outage was hurting, the fix happened within minutes. The weakness showed up only when the boundary blurred. A change that touched billing data was approved by a tired lead who did not realise a second team depended on it, and the clean-up took a day.

Strengths: speed, clarity, easy accountability. Weaknesses: depends heavily on one person’s judgment and on a well-drawn boundary. Best for: routine and low-blast-radius changes, and urgent incident response.

Model two: the review group

The second model uses a standing group, commonly some variant of a change review meeting, in which several people examine proposed changes and approve them together. Everyone present has a voice and often a vote.

The story here comes from a larger support provider whose review group met twice a week. It caught real problems: a missed dependency, a timing clash with a customer’s busy period. But it also produced a queue. Simple requests waited days for a slot, and engineers began splitting work into smaller pieces to avoid review, which defeated its purpose. Worse, when a change failed, nobody could say who had decided, because everyone had.

Strengths: broad perspective, shared awareness, fewer blind spots. Weaknesses: slow, diffuse accountability, tendency to become a rubber stamp or a bottleneck. Best for: large, cross-team changes with real coordination needs.

Model three: owner decides after a bounded consultation

The third model sits between the first two. A named owner is responsible for the decision, but must consult a defined short list within a fixed window before deciding. The rule is stated in advance, the deadline is explicit, and the outcome is recorded.

A mid-sized support team adopted this after growing tired of both extremes. For each change class, they wrote down the owner, the people to consult and how long consultation should take. A schema change might give two days; a firewall rule, a few hours. The owner decided, noted the reason in the change record, and informed the affected parties. The team found that approval times fell for medium-sized changes, while contentious ones still got the airing they needed.

Strengths: speed with perspective, clear accountability, an audit trail. Weaknesses: needs discipline to keep the consulted list short and the windows honoured. Best for: the broad middle of changes, where neither a lone approver nor a full meeting is the right fit.

Putting the three side by side

• Speed: single approver first, owner-after-consultation second, review group last.
• Breadth of input: review group first, owner-after-consultation second, single approver last.
• Clarity of accountability: single approver and owner model both strong; the review group weakest.
• Paper trail: strongest when the owner model includes a short written note, weak in the other two unless a habit is enforced.
• Risk of a bottleneck: highest in the review group, lowest in the single approver.

The right answer for most support organisations is not one model but a mapping. Match each class of change to a model, write the mapping down and review it twice a year. Routine restarts go to the single approver; infrequent, cross-team migrations go to the review group; the remainder go to the owner-with-consultation model. A related look at how responsibilities are named in the first place is offered in the guide to common DevOps role titles and how they differ, a helpful reference when deciding who should hold approval rights.

Why the mapping matters for customers

Customers of a managed service never see the internal model, but they feel its results. Slow approvals look like slow fixes. Unclear ownership shows up as contradictory answers from different team members. A team that can say, “This is who owns the decision and this is when you will hear,” builds confidence quickly. The ideas behind such predictable service are close to those in this overview of the principles behind reliable software delivery, and the two pair naturally.

It is also worth thinking about handover. Support work is shift-based, and decision rights that live in one person’s head disappear at the end of a shift. Writing the mapping where the whole rota can see it removes that hazard.

One more practical point: write down what triggers a change of model. A routine restart that touches a customer database for the first time should move from the lone approver to the owner-with-consultation path automatically, and an incident that spans three teams should pull in a wider group at once. Teams that spell these triggers out spend far less time arguing, mid-crisis, about which road they are on.

An echo outside engineering

The comparison applies to ordinary life as well. A family arranging a relative’s treatment abroad, for example, must pick a model for the non-clinical planning: a single coordinator for dates and documents, a family meeting where everything is voted on, or a coordinator who consults two relatives and then decides. BestHeartSurgery is an informational website whose own description makes clear that it does not deliver treatment, and it can give such a family background reading about options and destinations. Which model the family picks matters less than that they pick one and say so.

How to choose for your own team

1. List the last ten changes or escalations your team handled.
2. For each, note who actually decided and how long it took.
3. Sort them into the three models, whether or not you meant to use them.
4. Ask where the approach caused delay or surprise.
5. Write a short mapping and share it on the rota page.

Doing this once usually reveals a surprise: much of what a team treats as needing a meeting could be handled by a named owner, and a few things that were handled informally deserve more eyes. Start with the list, and let the evidence shape the rule.