Your AI Rollout Is a Change Management Project. That Makes It the COO's Job.

Buying the licenses is the easy part. Getting a team to use AI well is change management, and the way a company introduces the tool shapes the culture, the adoption, and the return on every dollar it spent.

There's a pattern I keep seeing when a company has had AI tools for a few months.

A handful of people have become power users. They've rebuilt how they work and they can't imagine going back. A bigger group uses it now and then, mostly to clean up an email. And everyone else tried it once or twice, shrugged, and went back to the way they've always done things.

Same tool. Same licenses. Same company. Wildly different results.

When leaders see that split, the first instinct is to push. Send a reminder. Run a lunch and learn. Track who's logging in. But the split usually isn't a skills problem, and it isn't a motivation problem. It's a communication problem. And communication at that scale is an operations problem.

People fill the silence

When a new tool shows up with no direction, people don't sit in neutral. They fill the silence with their own story about why it's there.

For a lot of people right now, especially with AI, that story is "this is here to replace me."

You can't blame them. They read the same headlines everyone else does. If nobody tells them what the tool is for, what it isn't for, and how it fits into their work, the replacement story wins by default. And nobody runs with a tool they're afraid of. They use it for the safest, smallest tasks, or they don't use it at all.

I wrote before about a friend whose company handed her an AI tool with no direction at all. She ended up resenting it, and honestly, I understood why. The tool wasn't the problem. The rollout was.

I've been on the other side of this

I've worked in environments where AI was being built and rolled out with good intentions. Nobody said "we're replacing people." Most leaders would tell you, and honestly believe, that they aren't.

But replacing a role doesn't always come from a decision. Sometimes it comes from how the tool gets built. When the plan is simply "let AI handle this process," and the only thing anyone looks at is the end result, everything between point A and point B disappears. The checks. The approvals. The person who knows which number always needs a second look. That's where the role lives, and that's what gets replaced, even when nobody meant to.

When I build an agent, I start with those in-between steps. Who approves what. Where the work goes next. What has to stay human. It ends up looking more like a product roadmap than a shortcut, and that's the point.

Seeing that gap up close, I had every reason to keep my distance from AI. Instead, I decided to learn it. I took every course I could find, and then I started building. What I found surprised me. AI didn't shrink my job. It made me more valuable, because I could suddenly build the workflows, tools, and fixes I'd been asking other people for.

But I got there in spite of how the tool was introduced, not because of it. Most people won't push through that much uncertainty on their own. They shouldn't have to.

Not everyone needs to go down the rabbit hole

Here's something I didn't expect. Even on a team that's open to AI, comfort levels are all over the map.

I went all in. I took the courses, I started building, and I kept going. But I work with a colleague who is just as capable and just as interested, and she simply doesn't have the time. Her calendar is full of client conversations and deadlines. Asking her to spend weeks learning how to build with AI would mean taking her away from the work that actually moves the business.

So I built it for her. I sat down with her, mapped out a workflow she runs all the time, and created an agent that handles the repetitive parts. She doesn't need to know how it works under the hood. She just uses it, and she gets the time back.

That changed how I think about adoption. The goal was never to turn everyone into a builder. The goal is for everyone to get value. Some people will go deep. Some people need a tool that's ready to use on day one. A good rollout plan makes room for both.

The rollout belongs in the plan

If you're building an AI product, or rolling one out internally, getting your own team to engage with it should be part of the product plan, not an afterthought. If your own people aren't using what you're building, that tells you something about what you're building.

The same goes for any company bringing AI into its operations. The tool is the easy part. The plan around it is the work. And that plan is exactly where a COO or Chief of Staff earns the seat, because it touches every team, every role, and the culture underneath them.

Here's what I'd put in that plan.

1. Say what it's for, and what it isn't for.

Name the work you want AI to take off people's plates. Be just as clear about what isn't changing. If roles are changing, say how. People can handle hard news. What they can't handle is guessing.

2. Show it on real work.

Generic demos don't stick. Sit with a team, pick one task they do every week, and build it together. The moment someone sees their own Tuesday afternoon get shorter, the tool stops being abstract.

3. Find your champions and let them build for others.

Your power users already exist. Give them time to show their peers what they've built, and to build for the people who don't have time to learn it themselves. People trust a colleague who knows their work far more than a vendor slide.

4. Make it safe to be a beginner.

Everyone is new to this. Say out loud that experiments are expected, that some won't work, and that nobody gets in trouble for trying. If people are afraid to look slow, they won't learn.

5. Tell people where the saved time goes.

This is the one most companies skip, and it's the one that decides whether people trust the whole thing. If saved time quietly turns into headcount cuts, everyone will notice and adoption will stall. If it turns into bigger projects, new skills, and growth, people will lean in.

6. Measure outcomes by sharing, not tracking.

Usage numbers tell you who opened the tool. They don't tell you whether work got better. And asking people to log how many minutes each task took turns a tool meant to help them into something that feels like being watched. People don't experiment when they feel watched.

There's a better way to see the results. Once a month, or once a quarter, hold a short town hall where people share how they're using AI. What they built, what it saves them, what they're doing with the time they got back.

That's where the real numbers show up. Someone on the finance team mentions she saves three hours every Wednesday with one simple workflow, and now spends that time getting audit prep in better shape. Someone else asks how she did it. The next month, three more people have tried it.

Those are your outcomes. Hours returned, work that got better, ideas spreading across teams. And every story told out loud makes it easier for the next person to raise their hand. The more people who share, the clearer your return becomes, and the more it grows.

The return on investment is a culture number

Companies like to talk about AI ROI as a technology question. Which model, which vendor, which license tier.

In my experience, the biggest driver of the return is how the tool is introduced to the people expected to use it. The same license can produce a team of builders or a team of quiet holdouts. The difference is direction, trust, and a leader who explains the why.

That's not a software decision. It's an operating decision. And it's one of the most important ones a COO or Chief of Staff will make in the next few years.

Access is step one. The story you tell about it is step two. Most companies are stuck between them.

If you're rolling out AI and want a plan that brings your team with you, let’s talk.

Next
Next

What a New Chief of Staff Needs From You in the First 90 Days