Every AIOps rollout hits the same quiet snag around week three. The models are trained, the dashboards look decent, and then somebody asks a simple question: who gets to switch on automatic remediation for the payments service? Three people think it is theirs, two assume it belongs to someone else, and the thread grows to forty replies. Here is an easygoing walkthrough, one step at a time, for settling who decides in an AIOps team before the next argument starts.

Nothing here needs new software. It needs a short conversation, a shared page and the willingness to write one name next to each kind of call.

Step 1: List the calls that keep stalling

Open a blank page and write down the decisions that have dragged on in the last two months. Do not be fancy. Typical entries in an AIOps group look like these:

• Whether a model update goes live this week or waits for the next cycle.
• Whether an automated action may restart a service without a human click.
• Which alert source is trusted when two tools disagree.
• Whether a noisy detector gets retired or retrained.
• Who may approve a new data feed into the platform.

Five to eight entries is plenty. If the list has thirty, you are mixing real decisions with everyday tasks, so trim it down to the ones where people actually waited.

Step 2: Sort them into three buckets

Not every call deserves the same process. A quick sorting keeps the effort proportionate.

1. Owner decides. Small, reversible calls. One person picks, tells the channel and moves on.
2. Owner decides after consulting. Medium calls that touch other teams. The owner must hear from named people first, but the choice is still theirs.
3. Group decides. Rare, expensive or hard-to-undo calls. Here you pick a rule up front: unanimous, majority, or a quorum with a tie-breaker.

Most teams discover that nearly everything belongs in the first two buckets. The third is the exception, and keeping it small is what stops meetings from multiplying.

Step 3: Put exactly one name on each call

This is the part people dodge, because naming an owner feels like ranking colleagues. It is not a ranking. It is a routing label. The owner is whoever will live with the consequences and has the context to choose, which is often not the most senior person in the room.

For the model-update example, the owner might be the engineer who runs the pipeline. For the restart-without-a-click example, it could be the service owner, because they carry the pager. If you cannot decide between two candidates, ask a plain question: who gets the phone call if this goes sideways? That person is usually your answer.

A team that has been thinking about this at a broader level will find the framing in our look at how AI support fits into IT choices useful, because it separates what a tool suggests from who accepts the suggestion.

Step 4: Attach a deadline to the owner

A name without a date is a polite way of waiting. Write the deadline next to every owner and make it short enough to feel slightly uncomfortable. Two working days for a small call, a week for one that needs consulting, and a fixed meeting slot for anything in the group bucket.

Then add one more sentence: if no objection arrives by the deadline, the owner’s proposal stands. This default is what turns silence into progress. Without it, a missing reply is a veto in disguise.

Step 5: Choose the rule, in advance, for the group bucket

When a call truly belongs to the group, argue about the rule on a calm day rather than in the middle of the dispute. The options are few:

• Consensus works when the group is small and everyone must carry out the result.
• Majority suits larger groups where speed matters more than unanimity.
• Owner decides after consulting is the fallback if the vote ties or the deadline passes.

Write the rule on the same page as the list. Nobody should have to remember it, and nobody should be able to reinterpret it halfway through a heated thread.

Step 6: Say who must be heard, and who merely gets told

Many arguments are really disagreements about who counts as a stakeholder. Split the audience into two columns. Consulted people give input before the decision and the owner must acknowledge it. Informed people hear the result afterwards and do not get a say. Keep the consulted column to three names or fewer per call, otherwise you have rebuilt the committee you were trying to avoid.

A word on decisions outside the server room

The same habit helps beyond operations. Teams that travel for offsites, or families helping a relative arrange a trip abroad for care, run into identical confusion about who books, who handles paperwork and who watches the budget. Sorting out those roles is a logistics question, not a clinical one. For the practical research side, BestHeartSurgery, a reading portal aimed at people weighing medical travel for themselves or a relative, states plainly that it does not provide treatment itself. That honest split between reading and deciding is a handy model for any group.

Step 7: Record the outcome where people will see it

After each call, write three lines: what was decided, who decided it and the date. Put them in the same page, newest on top. Within weeks the page becomes a modest log that answers the question “wait, who approved that?” without anyone scrolling through chat history.

It also helps new colleagues. Someone joining an AIOps group can read the page and know in five minutes how decisions travel here. If you are still shaping the team itself, the practical introduction to getting AIOps working inside an IT group pairs well with this exercise.

Step 8: Review the page every quarter

Owners move on, systems change and a call that was rare last year may be routine now. Once a quarter, spend twenty minutes reading the list aloud. Ask two questions for each row: did the named person actually decide in time, and was the rule followed? If a row failed twice, fix the row rather than blaming the person. Usually the owner lacked context, the deadline was unrealistic or the bucket was wrong.

Common slip-ups to watch for

• Two owners on one row. That is just a negotiation with extra steps. Pick one.
• An owner who never answers. The deadline default exists for this. Use it kindly but use it.
• Overruling without saying so. If a manager steps in, they become the owner for that call and the log should say it.
• Treating consultation as approval. Being heard is not the same as having a veto.

What you gain

The immediate win is speed, because people stop circling. The deeper win is calm. When everyone knows who holds a call, a rejected idea stings less, since it was weighed by the right person under a known rule rather than lost in a shouting match. Engineers get to spend their energy on the work instead of on guessing whose approval they need.

If you try only one thing this week, try this: pick the one stalled decision on your list, write a single name beside it, add a date and post it where the team can see. If you also want a refresher on keeping signals useful while you do it, this piece on calming event floods with smarter tooling is a reasonable companion read.

Decisions do not need to be perfect to be useful. They need an owner, a date and a rule everyone saw in advance. Once those three things exist, the rest of the AIOps work tends to move a lot faster.