Every organization we work with has them: a few people already using AI on their own, without being asked. They’re not necessarily technical. They’re curious, high-agency, and a little impatient with slow work.

We call them AI operators — it’s one of the three concepts our whole methodology rests on — and in most companies they’re 5–10% of the team. They didn’t wait for a policy. They didn’t ask for a license. They just noticed that part of their job was repetitive, tried a tool on it, and kept the parts that worked.

Find them before you build anything

These operators are the most reliable signal you have about where AI fits. They’ve already run the experiments — which tasks work, which tools help, where the friction is. A readiness audit that skips them misses the best data in the building.

They matter for a second reason: they’ve already made the mistakes cheaply. They know the model writes a confident wrong answer when the source document is stale. They know which customer questions it handles and which it mangles. That knowledge usually lives in nobody’s documentation — it lives in how they phrase their prompts. Ten minutes with an operator tells you more about your real AI readiness than an hour with an org chart.

How to spot them

You can’t find operators by asking "who here uses AI?" in a meeting — the honest ones undersell it and the enthusiastic ones oversell it. Look for the artifacts instead:

  • Their output changed shape. The office manager whose customer emails suddenly got longer, clearer, and faster. The estimator whose proposals started including a tidy summary paragraph nobody asked for.
  • They automated themselves first. Before anyone approved anything, they had a prompt saved somewhere for the weekly report, the job posting, the follow-up sequence.
  • They ask vendors uncomfortable questions. In every software demo, they’re the one asking "can it draft the response automatically?" while everyone else asks about pricing.
  • They complain differently. Most people say "we’re too busy." Operators say "why do we type this twice?" — they see process, not just workload.
  • Other people quietly route work through them. "Send it to Dana, she has a thing for that" is the surest sign in the building.

Here’s the shape it usually takes: a mid-sized services company, and the person who runs the front office has — without telling anyone — built a small library of prompts for quotes, review responses, and collection reminders. She isn’t "technical." She’s never written a line of code. But she’s effectively already running the pilot program your leadership team is still debating. The only question is whether the company notices before she takes that skill somewhere else.

Build around them, not past them

The common mistake is to roll out a tool to everyone at once and hope for adoption. It rarely sticks. What works: give your operators room, let them prove a win on a real task, and let that win travel. People trust a peer who saved four hours last week more than a mandate from above.

This ordering matters more than the tool choice. A mediocre tool in the hands of a motivated operator beats an excellent tool pushed onto an indifferent team. The operator supplies the two things no rollout plan can buy: a real task, and the persistence to get through the awkward first week.

A few things not to do, learned the hard way:

  • Don’t appoint your most senior person as the "AI champion." Seniority and operator energy are different traits. The best operator is often two levels down, and putting a title on the wrong person teaches everyone that this is theater.
  • Don’t buy licenses for the whole company on day one. Fifty unused seats read as failure in the next budget meeting, and that failure gets blamed on the technology instead of the rollout.
  • Don’t standardize too early. Let operators try things before you pick the official tool. The point of the exploration phase is to learn; locking it down first skips the learning.

What this looks like in practice

  • Identify the 5–10% already experimenting — using the signals above, not a survey.
  • Pair them with one well-scoped problem worth solving, and give them explicit permission to spend work time on it.
  • Capture what they learn in a shared format the rest of the team can follow — this is what our AI Solutions Brief exists for.
  • When the win lands, let the operator present it. Peer proof travels; mandates don’t.

Then repeat. The second operator is easier to activate than the first, because now there’s a visible path. This is also where training actually earns its cost: teaching a team that has already seen a peer win is a different job from teaching a skeptical room cold.

Technology without adoption is shelfware. Adoption starts with the people who were never waiting for permission — and the first practical step, before any tool decision, is simply learning who they are. If you want help finding them and turning what they know into a first measurable win, that’s exactly the work we do.