Why the COO should own deployment, not IT

Three weeks after a new field tool goes live, the service manager notices that half the crew is still turning in paper tickets. She mentions it to IT. IT checks: every tech has an account, every device has the app, the logins work. From IT's side, the project is done and healthy. From the service manager's side, nothing has changed.

Both are right. And that gap is why we think deployment of an operational tool belongs to the COO, or whoever in the company owns how the work gets done.

Deployment is a change in how work is done

When most companies think about rolling out software, they think about installing it. Accounts, devices, connections to the accounting system, permissions. That work is real, and it is IT's work.

But an operational tool is not finished when it is installed. It is finished when the crew does the job differently. The dispatcher builds the schedule in the new tool instead of the whiteboard. The tech closes the ticket before leaving the site instead of at the end of the week. The office stops retyping.

Those are changes to how people work. They involve habits, expectations, trade-offs between speed and completeness, and sometimes disagreements between the field and the office about what matters. None of that is a technical question. All of it is an operational one.

The person who can answer operational questions, and make the answer stick, is the person who runs operations.

What goes wrong when IT owns it

We do not say this to criticize IT teams. Most IT people we work with are careful and good at what they do. The problem is structural.

When IT owns deployment, the natural finish line is go-live. The tool is installed, the accounts work, the integration passes its tests. By every measure IT is responsible for, the job is done. There is no reason for IT to keep watching whether the crew uses it, and usually no authority to do anything about it if they do not.

Then the real problems start. A tech says the tool is too slow at the end of a job. A supervisor lets his crew keep using paper because it is a busy week. The office quietly starts entering things on the crew's behalf. Each of these is a decision about how work gets done, and each one lands on someone who cannot make it.

So the decisions do not get made. The tool drifts into partial use. Leadership sees that it is live and assumes it is working. Months later someone asks why the numbers still do not match, and the answer is that half the work never went through the new tool.

This is also where approval drag shows up inside the project itself. Every small question about the workflow waits for someone with the authority to answer it, and the tool loses momentum while it waits.

What the COO actually owns

Owning deployment does not mean the COO configures software. It means the COO owns a short list of decisions that nobody else can make.

• Name the crew who will use the tool first, and the one person who is accountable for the workflow.
• Free real time for training and for the rough first weeks, instead of asking people to learn on top of a full load.
• Decide what happens when the old way and the new way conflict, and say it out loud.
• Agree before the build what "used" means, as a number counted from the company's own records.
• Look at that number every week until it holds, and act when it slips.

That is not a large time commitment. It is a clear one. Most of it is making decisions early and repeating them often.

The third item matters more than it looks. In every rollout, there is a moment when someone says, "Can I just do it the old way this week?" If nobody with authority answers, the answer becomes yes by default. The COO does not have to answer no every time. But someone who owns the result has to answer.

None of these decisions needs a long meeting. What they need is someone whose word settles the question in the moment. On a Monday morning, when a supervisor asks whether his crew can skip the new tool because two techs are out, the answer has to come from someone who can weigh the week's pressure against the reason the tool exists. That weighing is operations judgment. It is the same judgment a COO uses about overtime, callbacks and scheduling every week, and it belongs with the same person.

What IT should still own

None of this sidelines IT. A tool that the COO champions but that cannot get access to the systems it needs will fail just as surely.

IT should own the things that keep the tool safe and connected: user accounts and access, security reviews, devices, the systems of record the tool reads from and writes to, and the rules for what data can go where. IT should also have a clear say in anything that touches those systems, and a right to stop anything that puts them at risk.

The split we recommend is simple. IT owns whether the tool can be used safely. Operations owns whether it is used. Both are required, and they are different jobs.

When we run a build, we ask the company to name the people on its side before the clock starts: an executive sponsor, someone who owns the workflow, someone who can grant access, and someone from the crew. The sponsor is almost never IT. Access almost always is. That structure is deliberate.

Why this is harder to hand off than it looks

Some owners respond to this by hiring someone to own it for them: an AI lead, a new operations technology role, a project manager. That can help with coordination. It does not solve the core problem unless that person has real authority over how the crew works.

A new hire without that authority is in the same position IT was in. They can see the problem. They cannot make the decisions that fix it. We wrote more about that choice in our comparison of a workflow firm versus hiring an AI director.

The simplest arrangement is usually the right one. The person who already runs operations owns the change to operations. Everyone else supports them.

It also helps to be clear about what the owner does not need to do. The COO does not need to learn the tool in depth, attend every training session or sit in on build reviews. They need to show up at the start to set the goal, stay visible during the first weeks, and read one number every week. Crews notice very quickly whether the person who runs operations cares about a change. That attention is often worth more than any feature.

What to do next

Before your next rollout, write down two names. The person who owns whether the tool can be used safely, and the person who owns whether it is used. If the second name is someone in IT, or nobody, fix that first.

If you already have a tool that went live and stalled, our guide on what to do when the crew won't use the new system is a good place to start. And how we work lays out the roles we ask a company to name before a build begins, and why the usage number is agreed before anyone writes code.