A VP of analytics at a F500 told me last month that her ChatGPT Enterprise rollout had 'change management issues.' When we got into it, what she actually had was two different rebellions on opposite ends of her org, and a leadership team treating them as one problem. That's the pattern across almost every stalled enterprise AI program I see right now, whether the tool is Copilot, ChatGPT Enterprise, Cursor, Claude Code, Codex, or an internal AI BI deployment.
Change management is not one force. It is two, and they sit at opposite ends of the technical spectrum.
The two resistances are not the same problem
Ursula Ortizbanda, who leads AI and analytics at Oracle, put it cleanly: 'It's harder for the two extremes. It's harder for the people that are very good in technology, developers that own their code, they don't want to let it go. And it's harder for the non-technical people to be forced to use the system to do their work.'
Treating these as a single problem produces a single solution. Usually that solution is more training, better documentation, and an executive mandate. It works on neither group.
Extreme 1: the deep technologists
Senior engineers. Principal data scientists. Long-tenured analysts who have spent a decade owning a SQL stack nobody else understands. Their resistance does not look like resistance. It looks like rigor.
You will hear:
'I could have written this faster myself.'
'The query works but it's not how I would have done it.'
'It got the right answer for the wrong reason.'
The benchmark goalposts move every week. This is not bad faith. Their craft is their identity. Watching a model produce in 9 seconds what took them years to learn feels like the floor moving.
You do not beat this resistance with a better demo. You beat it by changing what they own. Their craft moves up a layer. They stop writing the SQL and start owning the context graph, the playbooks, the validation rules.
Cursor and Claude Code got this right. They pitched 'you stay in control, the AI handles the boilerplate.'
Extreme 2: the non-technical users
Finance leads. PMs. Marketing managers. Ortizbanda: 'They want to ask questions like my mom would ask ChatGPT. They don't think about anything. They want the answer.
They try the system once. It gives them a wrong number. They are done. They had a working alternative — emailing the data team — and they are going back to it.
Forcing them to learn prompt engineering is the wrong fix. The fix is to build a system that disambiguates intent the way a human analyst would. Non-technical users don't fail at asking questions. They fail when the system doesn't know what "revenue" means at their company, or which Salesforce stage counts as closed. That is not a user problem. That is a context problem.
The middle is moving faster than anyone thinks
Mid-level analysts. Technical PMs. Data-curious operators. They have enough technical chops to prompt well and enough domain context to spot a wrong answer. They are quietly becoming the internal champion in every successful AI rollout.
The mistake is building your entire adoption strategy around them. They don't need convincing — they are already converted. Rollout plans that stall often mistake a fast-moving middle for a solved problem and underinvest in the two ends that are actively resisting.
What the middle actually needs is not more training. It is scale. Give them the tools to surface definitions so non-technical users get accurate answers. Give them visibility to flag wrong outputs before they reach a VP's dashboard. They become the bridge, not the metric you are optimizing for.
How the two resistances actually compare
Deep technologists | Non-technical users | |
|---|---|---|
What it looks like | Quality nitpicks, goalpost-moving | 'I tried it once, it was wrong, I'm done' |
Root cause | Loss of craft identity | Cost of learning a new interface |
Wrong fix | More accuracy metrics | More training and prompting guides |
Right fix | Give them ownership of context | Build disambiguation into the system |
Time to convert | Weeks, once they own the layer above | One good answer to a real question |
Counterargument: maybe the middle is enough
If the middle is 40% of your org and they get a 3x productivity gain, that is a real number. This works for a year. Maybe two. Then the deep technologists who never bought in start blocking architecture decisions, and the non-technical users who churned never come back. The middle becomes a ceiling instead of a floor.
What to do about it
There is no single playbook. But two specific moves consistently work.
For deep technologists: do not ask them to adopt. Ask them to govern. Give them a layer above the model to own, the business definitions, the disambiguation rules, the metric validation logic. When a senior analyst decides whether "ARR" includes expansion revenue, and that decision persists in the system every time any user asks, the resistance reframes. They are not being replaced. They are the reason the system is accurate.
For non-technical users: measure first-answer accuracy on real business questions, not satisfaction scores after training. One wrong answer to a real question does more damage than five correct answers to generic ones. The system needs enough context about your business to answer without asking the user to rephrase. If it does not have that context, no amount of onboarding fixes the churn.
The middle will move on its own. Use them to route feedback from the other two groups back into the system. That is the actual compounding mechanism.
Frequently asked questions
Why does AI adoption fail in large enterprises?
Most rollout plans treat resistance as one problem. It is two. Deep technologists push back because their craft identity is threatened. Non-technical users churn after one wrong answer because they have a working alternative. A training program that addresses neither specifically will not convert either group.
How do you get senior engineers to adopt AI tools?
Move their craft up a layer. Cursor and Claude Code got this right by keeping the engineer in control of what matters while the AI handles the boilerplate. For data and analytics specifically, that means giving engineers ownership of context and validation — not just asking them to accept AI-generated output.
Why do non-technical users churn after one bad AI answer?
They had a working alternative — emailing the data team — and switching back costs nothing. The fix is not better prompting guides. The fix is a system that already knows what "revenue" means at your company, which pipeline stages count as closed, and how your team defines a metric before anyone has to ask.
Who adopts enterprise AI fastest?
Mid-level analysts, technical PMs, and data-curious operators. They have enough technical skill to prompt effectively and enough domain knowledge to spot when an answer is wrong. In successful rollouts, this group becomes the bridge between the two resistant ends, not the primary metric of adoption.
That architecture is what Genloop's Review Center is built for: senior analysts own the definition layer, every verified metric persists across every query, and non-technical users get accurate answers without needing to know how to prompt.
Connect your warehouse — free.
