Moving the People

A company does not become AI-native when everyone gets an account. It does not happen when the training is finished, or when a policy says the word "AI" enough times to sound serious. Those things make adoption visible. They do not move the work.

The work moves when people move. Not out of the company, necessarily, and not all at once, but out of the old posture: a person doing the task, with AI nearby as a helper. Into the new one: a system doing the task, with a person directing it, checking it, and owning the result.

That is the part most AI transformations skip. They buy the tools, announce the ambition, and leave the org chart untouched. The machine arrives, but the work still routes through the same people, same meetings, same approvals, same dashboards. Nothing changed except the software bill.

McKinsey's 2025 survey has the shape of the problem: 88% of organizations report regular AI use, but roughly two-thirds have not begun scaling AI across the enterprise, and the high performers are the ones redesigning workflows and getting senior leaders to model the change themselves. BCG says the same thing more bluntly with its 10-20-70 rule: only 10% of the work is algorithms, 20% is data and technology, and 70% is people, processes, and culture.

The hard part was never getting people to try AI. The hard part is moving them to a new job.

Do not start with everyone

The beginner mistake is democratic: train everyone, invite everyone, ask everyone to find use cases. It sounds fair. It usually produces noise.

Most people are not positioned to redesign the work they sit inside. They can improve a step. They can write a faster email. They can automate a spreadsheet. They cannot retire the meeting, change the approval path, replace the handoff, or decide that a role should now supervise an agent instead of performing the task by hand. That authority sits somewhere else.

So a company needs a migration pattern. There are three that actually work, and they are not interchangeable.

Plan A: one leader pulls the work across

The fastest path is one accountable leader, usually the founder, a business owner, or the head of a function, who changes their own work first and then pulls the team behind them.

This is not an AI evangelist. An evangelist can make people excited. They cannot change the route a purchase order takes, kill a dashboard, or tell a team that the old manual review is no longer the default. The first lead needs authority over real work, not enthusiasm about tools.

The move is simple:

• Pick one workflow that matters.
• Redesign it so the machine does the first pass, not the human.
• Run it personally until the new shape is undeniable.
• Remove one old step, not just add one new tool.
• Make the team copy the new workflow, not merely admire it.

This works best in a small company, or inside one function where the leader controls the full loop. A sales lead can rebuild outbound. A support lead can rebuild tier-one resolution. A founder can rebuild reporting, research, hiring screens, product specs, customer follow-up. The important thing is that the leader changes a workflow people already respect.

The signal is not "the team uses AI more." The signal is that an old step stops existing.

Plan A fails when the lead is too junior, too far from the work, or too polite. If the person cannot say "we are not doing it that way anymore," they are not leading the migration. They are running office hours.

Plan B: a small cell runs beside the old team

The second path is a separate cell of one to three people running parallel to the traditional team.

This is the right move when the existing team is too loaded, too risk-sensitive, or too entangled with legacy process to redesign itself while keeping the trains running. You do not ask the current machine to rebuild itself mid-flight. You put a small team next to it and give them one narrow workflow to beat.

But the cell cannot be an innovation lab. A lab makes demos. This cell owns a production metric.

Give it a real lane:

• Same input as the old team.
• Same success metric.
• Freedom to use a different workflow.
• Access to the data and systems it needs.
• A deadline to prove whether the new shape is better.

For example, one to three people take a slice of customer support, lead qualification, content operations, internal reporting, QA, or implementation onboarding. They run the AI-native version beside the normal version. Same queue, same customer reality, same quality bar. If they win on cycle time, cost per task, quality, or throughput, the company has learned something real. If they only win in a demo, it has learned almost nothing.

Plan B is useful because it protects the old team from chaos while protecting the new workflow from the old team's antibodies. The legacy team keeps serving the business. The cell gets enough room to violate the assumptions the legacy team has to obey.

The danger is exile. If the cell stays separate too long, it becomes a museum of interesting work. The rule should be set on day one: if the cell proves the workflow, the workflow moves into the company. Either the old team adopts it, the cell becomes the new owner, or people rotate out of the cell into the functions they just changed.

A parallel team is a bridge, not a second company.

Plan C: every team gets an AI owner

The third path is distributed: every team has one person with real AI expertise embedded inside it.

This is what scale looks like, but it is a bad place to start. If nobody has proven what good looks like, "one AI person per team" just creates a network of local prompt helpers. They answer questions, share tips, build small automations, and slowly become the helpdesk for other people's hesitation.

An embedded AI owner is a different job.

They own the local harness of the work: where the model enters, what tools it can call, what context it gets, when a human must approve, how quality is checked, what the task costs, and which old steps should disappear. They are close enough to the function to understand the work, and technical enough to know when the workflow is lying to itself.

This person should be measured on work moved, not workshops delivered:

• Human touches removed from a workflow.
• Exception rate after the agent handles the first pass.
• Cost per completed task.
• Rework and error rate.
• Time from input to outcome.
• Old tools, meetings, or handoffs retired.

At this stage, the company also needs a central spine: shared standards, security rules, model routing, eval patterns, reusable tools, cost visibility, and a place where lessons compound. Deloitte describes the same tension in AI centers of excellence: the capability needs to be close to strategic business work, but standardization and governance become more important as AI gets closer to the core.

So Plan C is not pure decentralization. It is a federated model. The teams own the work. The center owns the rails. If everything is central, the company waits in line. If everything is local, the company repeats the same mistakes ten times.

The order matters

These three plans are not a menu. They are a sequence.

Plan A creates the first visible belief. Someone with authority changes a real workflow and proves the company is allowed to stop doing things the old way.

Plan B creates evidence. A small cell shows, against the old process, that the AI-native version can beat the traditional one on a real metric.

Plan C scales the pattern. Each function gets someone who can keep moving work locally without waiting for a central team to rescue it.

Small companies may go from A straight to C. Larger companies usually need B, because legacy process has too much gravity. But almost every company needs A. Without a visible leader doing the work differently, AI remains optional behavior. Optional behavior loses to the calendar.

What people are really afraid of

People do not only resist AI because they are skeptical. They resist because the migration changes what competence looks like.

A person who was valuable because they could do the work quickly is now being asked to become valuable because they can direct, judge, and improve a system that does the work. That is a real identity shift. If you pretend it is just upskilling, people feel the lie immediately.

BCG's adoption research found that most employees remain in the middle stages of AI adoption, while fewer than 10% reach semiautonomous collaboration. That sounds right. The gap is not access. It is confidence, permission, incentives, and local leadership. BCG also points out that visible manager use, protected learning time, peer examples, and team-based incentives matter because adoption is social before it is technical.

This is why the migration cannot be handed to HR as training, or to IT as enablement. HR can help. IT can help. But the move has to happen inside the work, owned by the people who can change the work.

The company changes when the old path closes

There is a clean test for whether a company is becoming AI-native.

Can a team still choose the old process?

If the old process remains fully alive, staffed, measured, and respected, most people will return to it the moment the new one becomes uncomfortable. The migration only becomes real when the old path starts closing: the manual first draft is no longer accepted, the meeting is removed, the report is generated before the analyst opens the dashboard, the support agent handles the first pass by default, the human only sees exceptions.

That is why moving people is more sensitive than buying tools. A tool can be added quietly. A workflow cannot. A workflow declares what the company now believes a person is for.

The AI-native company is not the one where everyone uses AI. It is the one where the work has been redrawn so people are no longer trapped doing what the machine can already do.

First one leader proves it. Then a small cell tests it against the old way. Then every team gets someone capable of keeping the migration alive.

That is how the people move. And until the people move, the work will not.