Driving AI adoption past the enthusiasts

The premise

The single most common failure at the Expand stage is not technical. It's a category error: the organization thinks it's scaling the tool, when what actually needs to scale is the workflow — and the workflow only scales through people who know how to run it.

The typical arc: one pilot works. The team buys licenses for 500 people. Usage spikes for six weeks, then drops to 15%. Nine months later the central team is still answering questions from the same twelve people they started with, and the next pilot is harder to fund because nobody can articulate what changed. The tool didn't fail. The adoption plan was never written.

Why adoption is Expand's whole job

The five-stage roadmap names Expand as the stage where two or three pilots become twenty runs across functions. That can only happen if the pattern the pilot proved is repeatable by teams who weren't in the room — which means it can only happen through people, not through tool deployments.

The pattern that recurs is worth naming, because it recurs everywhere:

• The pilot works. One workflow, one team, one set of results. The metric moved; the baseline held.
• The pilot gets bought. The pilot sponsor secures a broader rollout. Licenses go out to two hundred more people.
• The rollout produces usage. Weekly active users spike to 40%. The pilot's success is declared. A press release is drafted.
• Usage drops. Six weeks later, weekly active users are at 12%. The pilots have become side projects. The tool is embedded, but the workflow isn't.
• The next pilot gets harder. Because the previous "win" is already contested, and the CFO has started asking about ROI.

Every failure in that arc is an adoption failure — not a technology failure, not a product failure, not a strategy failure. The technology worked. The strategy existed. The scope of what "success" meant became confused, and there was no one whose specific job was to keep the workflow running after the pilot ended.

What actually needs to expand

The pattern above happens because teams measure the wrong things. Five specific category corrections, in order of how often they hold back a rollout:

The workflow, not the tool

Installing the tool in more places is deployment. Running the workflow across more teams is expansion. Deployment is measured in seats; expansion is measured in workflows in production, per team, per function. If your rollout dashboard has a license count on it, it's answering a different question than the one the roadmap needs answered.

The pattern, not the license count

When one team can stand up a workflow using the pattern the pilot created — the same integration shape, the same eval harness, the same HITL thresholds — the pattern is the asset. Licenses are the cost. A rollout that ships 500 licenses and zero reusable patterns scaled the cost, not the pattern.

The operators, not the users

Users try a tool. Operators run a workflow. The difference isn't seniority or enthusiasm — it's knowledge of what "normal" looks like for this specific workflow, and the standing to escalate when it stops looking normal. You can have 500 users and 12 operators. You cannot have 500 operators; you don't need to.

The measurement, not the training

Training completion is not adoption. Training is a leading indicator; adoption is the workflow's primary metric moving against its baseline. If you can't show the workflow's metric moved after six weeks of operation, adoption hasn't happened — only attendance has. The training may have been excellent and the workflow may still be failing, and you need to know which.

The roles, not the champions

Champions without a job description aren't roles. They're volunteers. Volunteers help until their day job calls them back. Real adoption requires roles with the authority to change the workflow — what an operator does, what a strategist does, and which decisions belong to each. That's the difference between a name on a slide and a job in the org chart.

Operators and strategists

Expand introduces two roles to the org chart. They're sometimes confused because both touch the workflow. They're not interchangeable, and collapsing them into one role is one of the quietest ways adoption fails.

Why the two roles must be different people: if the operator holds both roles, the workflow never redesigns — it just runs, because the person running it doesn't have time to redesign it. If the strategist holds both roles, the workflow never gets run well — it gets designed and left alone, because the person redesigning it isn't close enough to notice when it drifts.

Why the two roles must be connected: if they live in different organizations with no shared workflow, the workflow never improves either. The operator's weekly exceptions report is what the strategist's monthly review works from. The strategist's redesign decision needs the operator's weekly data to be grounded. Both roles need the same workflow in their job description.

The five-part plan by team

An adoption plan is per team, not per org. Every part is concrete enough that someone who has never met the team could read it and know what's supposed to happen — and know who owns what. The whole plan fits on one page per team.

Expand on each of the five, in turn:

1 · Workflows in production

List each workflow the team runs, in production. Not "we have access to Claude." Not "we've been piloting some AI." The specific workflows: "first-response drafting for tier-1 support tickets." "Invoice exception triage for AP." Each gets its own row. If a workflow names a tool instead of a workflow, the plan is measuring deployment, not adoption.

2 · Operators

For each workflow, name 1–3 individuals who run it. The role can be a full-time operator, a lead who runs the workflow as part of their job, or a designated senior practitioner — the point is a name and the standing to know what "normal" looks like. "The support team" is not an operator. If the answer is "we haven't decided yet," the workflow is running without an owner.

3 · Strategists

For each workflow, name one person (different from the operators) who owns the workflow's design and the automation-vs-risk tradeoff. This is usually the function leader, a senior practitioner, or a product owner. The strategist is the person who can say "we're going to change where the HITL threshold is" without wondering who they need to ask. If that person doesn't exist, the workflow has an operator but no owner.

4 · HITL posture

For each workflow, the specific decisions that route to a human. Not "human review" as a principle — a list: "refunds over $500 require manager approval." "First-response drafts for tier-1 billing tickets auto-send; tier-1 technical tickets require operator approval." The list is specific enough that somebody could code it into the workflow. If it's not specific enough to code, it's an intention, and it will be resolved by whoever's closest to the workflow that day.

5 · Measurement

For each workflow, the primary metric against its baseline. "Handle time moved from 18 min to 12 min." "Rework rate moved from 12% to 9%." Not "the tool is being used." The measurement is what makes adoption a claim that can be checked rather than a feeling that can be asserted. This is where the baseline playbook pays off — the baseline is what the current numbers are compared to.

Worked example

A customer support team at a mid-size software company, nine months after their pilot. Two workflows in production, four in the pipeline. Expand the example to see the plan.

The trap, in depth

1 · Counting seats as adoption

"We shipped to 500 users." Five hundred people with credentials is five hundred people who could, in principle, use the tool. Adoption is forty people who run the workflow well enough to run it without help, every week. Symptom: the adoption slide has a bar chart of "users" and no bar chart of workflows. Test: ask anyone in the room to name three of the 500 and what workflow they run. If nobody can, the number is not measuring anything.

2 · Confusing training with operation

"We trained everyone." Training is a leading indicator. Awareness is not capability. The test is what happens on the fifty-first case — the weird one that didn't look like the training scenarios. Can the person they trained still run the workflow, or do they need to page the central team? If they page the central team, the training made them a user, not an operator.

3 · Measuring use instead of outcomes

"We have 40% weekly active use." Use is a leading indicator; the workflow's metric is the outcome. A workflow used 100% of the time that produces worse output than before is not adoption — it's a problem. Symptom: the adoption dashboard has weekly-active-user counts but no baseline-vs-current comparison for any workflow. If the workflow's metric didn't move, adoption may still be worth pursuing, but it hasn't happened yet.

4 · Confusing the tool with the workflow

"The tool is now embedded in our process." A tool embedded in a broken workflow doesn't fix the workflow — it accelerates the brokenness. The workflow is what needs to change, and the tool is at most an accelerant. Symptom: the adoption narrative uses the word "embedded" without naming the workflow that improved. Test: cover the tool name in the slide. Does the workflow still seem better? If not, the improvement was the tool, not the workflow — and the tool will be replaced by the next tool.

5 · Champions without authority

"We have 40 AI champions across the org." Champions who can't adjust a threshold, allocate a budget line, or change a workflow aren't champions — they're enthusiasts. Enthusiasts help when they have time; they can't sustain a workflow when their day job calls them back. Symptom: the champions' job description doesn't include "authority to change X." Test: name one change a champion made to their workflow in the last 30 days, without escalation. If you can't, they don't have authority, and the role isn't doing what the org chart says it does.

Quality bar — what "good" looks like

1. Every workflow has named operators — 1–3, by name. Not "the team." A specific human being with a specific workflow in their job description.
2. Every workflow has a strategist who isn't the operator. Different name, different month-end review, different decision rights.
3. The HITL posture is specific enough to code. Every decision routed to a human is named. If it's not codable, it's not a posture — it's an intention.
4. Every workflow has a metric moved against baseline. Not "users" — the workflow's primary metric. If the metric didn't move, adoption hasn't happened yet, and the plan should say so.
5. The plan is one page per team. If it's longer, either the team runs too many workflows to have a coherent plan, or the plan is documenting org structure instead of describing operations.
6. Operators and strategists are both represented in the review cadence. Operators report weekly; strategists decide monthly. If either cadence is missing, the workflow stops improving or stops running.
7. The plan names the escalation path. When this workflow breaks — and it will — who is called, and by whom? If the answer is "the central AI team," adoption hasn't happened. The team owns it.

Red flags — signals adoption hasn't happened

What this sets up

A complete adoption plan — five parts, per team, one page — is what makes the next three stages possible. Every later stage is a coordination problem, and coordination problems can't be solved for workflows that don't have named owners.

• Executize. The coordination agent needs a registry of workflows and their agents — that registry is the union of every team's Part 1. It also needs to know who to propose improvements to — those are the strategists. And it needs a decision log that shows what's been changed — those are the strategists' monthly reviews. Without the adoption plan, the coordination layer has nothing to coordinate.
• Transform. New workflows and new roles that weren't possible before will inherit the operator/strategist pattern. The org chart that supports Transform-scale redesign starts with the operator/strategist distinction it learns at Expand.
• Autonomate. The five-tier autonomy ladder requires tier-level ownership. Who decides a workflow can go from L2 to L3? A strategist. Who monitors for drift at L3? An operator. Without both roles defined at Expand, the autonomy decisions at Autonomate become centralized and slow.

Common questions

How do operators differ from power users?

Power users use the tool well. Operators run the workflow — which means they know what "normal" looks like for the workflow, they own the daily output quality, they can tune thresholds within an allowed range, and they know when to escalate. A power user is an excellent user. An operator is accountable for the workflow's output. Power users are a gift; operators are a role.

Should operator and strategist be the same person?

For very small teams, sometimes — but the same person then has to be resourced as both, or the workflow never redesigns. If the same person is running the workflow all week and also responsible for redesigning it, the redesign never happens — because the operator's day job is running the workflow, and the strategist's day job is going to come second. If you have to combine them, name the split explicitly: "X is the operator Mon–Thu, the strategist Fri." If you can't resource both, the workflow is running, not growing.

What if the team doesn't have enough operators?

Then choose the workflow's coverage deliberately instead of pretending. Options: hire into the role (usually slow), design the workflow to need fewer operators (usually right but requires the strategist), or accept a smaller scale of the workflow (usually honest but requires an executive decision). What doesn't work is running the workflow without operators and hoping the central team covers. That's the pattern that produces the 12% weekly usage drop.

How do we measure adoption without a baseline?

You don't — you measure something else, and you call it something else. Weekly active users is a deployment metric. Training completion is an awareness metric. Neither is adoption. If you can't measure adoption, measure what you can and label it correctly, then prioritize getting a baseline for the next workflow so the measurement problem doesn't compound. A team with three workflows and no baselines has three times the problem.

What about teams that don't own their workflow?

That's the most important edge case, and it's very common. A shared service team might run a workflow whose output goes to another team. A finance analyst might run workflow steps whose decision rights sit with someone else. In these cases, the operator/strategist distinction has to be split across teams: the executing team names operators, the owning team names the strategist, and both share the monthly review. What doesn't work: split ownership without a review cadence — each side optimizes for its own goals, the workflow drifts, and nobody notices until the metric has moved.