AI Adoption: Why Your Experts Aren’t Convinced

A Copilot licence has a price you can put in a spreadsheet. The cost of an expert putting their name to a wrong answer is rather harder to calculate.

That difference matters when you are trying to improve AI adoption. The business case promises faster work. The person responsible for the work may see more checking, a different way of doing the job and a new opportunity to get something wrong.

If some of your most experienced people are holding back, another webinar may help. But before booking it, I would ask whether you have understood the decision you are asking them to make.

The question I want to explore is this: what would make AI useful to someone who already does the job well?

The expert may have a point

The temptation is to treat low usage as resistance. The tool is available, the training has happened and some colleagues are getting good results. Why will this person not get on with it?

There are several possible answers. They may lack confidence. They may need a better example. They may not trust the organisation’s intentions. They may also have tried the tool and found that it made their particular task harder.

That last possibility deserves more attention than it usually gets.

An experienced specialist already has working methods, useful shortcuts and a strong sense of what a good answer looks like. AI has to improve on that baseline. Producing something quickly is only the beginning. Someone still has to supply the context, check the assumptions, correct the mistakes and take responsibility for the result.

Imagine a DBA reviewing a database migration plan. An AI tool produces a polished checklist in seconds. It also misses an important dependency and suggests a step that does not fit the environment. The DBA now has to work out what else might be wrong. The checklist was quick to generate. The work was not necessarily quicker to finish.

The checking belongs in the calculation.

There is evidence that benefits differ with experience. A field study of more than 5,000 customer-support agents found that less experienced and lower-skilled workers gained more from AI assistance than their experienced colleagues. It studied a particular tool in a particular business. It does not establish that senior specialists generally resist AI, or explain why they might.

It does challenge the assumption that the same tool offers everyone the same benefit.

What I take from Rory Sutherland

This is where I find Rory Sutherland’s Alchemy useful. What looks sensible in the business case can look quite different to the person being asked to change their behaviour.

My application of that idea is straightforward. Instead of starting with ‘How do we get our experts to use AI?’, start with ‘What would make using it a sensible decision for them?’

The first question treats the person as the obstacle. The second makes you examine the offer.

What are they being asked to give up? What will they gain? What uncertainty are they taking on? What happens if the output is wrong? And will the organisation recognise the contribution they make once the work looks easier?

Those questions belong in the rollout design. They are also useful questions for the finance director, because a programme that ignores them can spend a lot on licences without changing much.

The checking has a cost, and someone owns the result

Consider the pitch: use this tool and save an hour.

An hour could be valuable. But the expert may be comparing that gain with the possibility of sending a client an incorrect recommendation, approving a flawed design or missing something they would normally have caught.

The organisation sees a potential productivity improvement. The individual still owns the professional consequence of an error.

Loss aversion offers a useful lens here: potential losses can weigh more heavily than equivalent gains. It is not a diagnosis of every reluctant user, and I would avoid pretending there is a fixed multiplier we can apply to professional reputation. Often the simpler explanation is enough. A small saving may be a poor exchange for a risk someone does not yet know how to manage.

This is why ‘the output still needs checking’ is an incomplete answer. Who does the checking? What standard applies? How much time have you allowed? Where can the expert say the tool is unsuitable?

A credible rollout answers those questions before it asks people to become more enthusiastic.

You may also be changing what expertise looks like

There is a second problem, and it connects with the argument about making DBA value visible.

Organisations often recognise expertise through its visible output. The carefully written recommendation. The detailed analysis. The diagnosis under pressure. The person who can explain why the apparently obvious answer is wrong.

When AI produces something that looks similar in a few minutes, it can become harder for someone outside the discipline to see the difference between plausible output and dependable work.

The specialist may be concerned about what the tool can do. They may also be concerned that the organisation will stop understanding what they contribute.

That concern becomes more credible when the rollout message is all about reducing the time it takes to produce things. You are telling people that speed is the benefit while leaving the value of review, context and judgement largely unspoken.

The answer is to make that contribution visible. Show the assumption the expert corrected, the dependency they identified and the reason a recommendation changed. Recognise the person who made the output usable, as well as the person who generated it.

This does not mean every expert’s current method should be preserved indefinitely. It means the new method has to earn its place.

Doing the work can be part of the thinking

Producing the work can be how an expert develops the answer.

Sometimes production is repetitive administration that can usefully be delegated. Sometimes writing the explanation, building the model or investigating the problem is how the specialist works out what they think.

I would not ask a DBA to stop understanding query plans because a tool can suggest an index. Equally, I would not assume that a polished AI-generated strategy document means the organisation has done the thinking needed to act on it.

Brent Ozar describes working with AI as becoming a middle manager. It is a useful way of describing the shift towards briefing, directing and reviewing. Those activities require skill too, and they do not automatically suit every part of the job.

There is also a longer-term question. If junior staff hand over all the difficult drafting and investigation, how will they build the judgement needed to review it later?

An enablement programme needs to distinguish between work that can be delegated, work where AI can support the thinking and work people still need to practise themselves. That is a more useful conversation than declaring manual work obsolete.

A better headline needs a better offer

I still favour framing AI around what the organisation can do with its people. Better service. More capacity for important work. A wider range of options considered before a decision. Less time lost to routine administration.

But framing has to be backed by what happens afterwards.

If someone saves two hours and immediately receives three hours of additional work, they will learn what the programme means for them. If the organisation praises judgement in the launch presentation but measures performance entirely by volume, people will follow the measure.

Calling the programme ‘capability building’ will not resolve that contradiction.

The leadership team needs to decide what released capacity is for. Does it create room for better client work? Reduce a backlog? Allow people to learn? Help the business grow without adding the same amount of administration?

There can be a legitimate cost case too. Time savings matter, and finance is right to ask for evidence. But an hour released is not automatically an hour removed from the payroll. State what the capacity enables and how you will know it has produced value.

If staffing changes are part of the plan, be honest about that. Do not ask people to trust a reassuring message that the operating decisions will contradict.

The signal worth sending

There is value in a senior leader using AI in public, including the bits that go wrong. The demonstration needs to be supported by practical commitments.

A leader admitting uncertainty can make it easier for others to try something unfamiliar. A leader showing how they check an answer can also make the expected standard clearer.

The stronger commitment is protected time, access to someone who understands the role, and permission to report that a trial did not help.

For a fee-earning team, protected time means recognising the effect on utilisation. For an operational team, it means adjusting the workload. Asking people to experiment while keeping every existing target unchanged makes experimentation another task to squeeze in.

That is a signal people can assess without reading the intranet campaign.

There is a useful test for leadership here. If a pilot produces a disappointing result, do you treat it as information or as a failure of enthusiasm? Your experts will notice the answer.

An AI adoption experiment an expert can trust

Here is how I would turn the argument into something practical.

Choose a task they want help with

Start with a real frustration in the specialist’s working day. Let them help choose it. It could be extracting requirements from an approved document, finding gaps in a checklist or proposing additional test cases.

Keep the first experiment small enough to understand. Agree what data can be used, where the output will go and who reviews it. The purpose is to establish useful evidence without introducing unnecessary uncertainty.

Agree what better means

Record how the task currently works. How much effort does it take? What quality standard applies? What happens when something is missed?

Then agree the improvement you are looking for. It might be lower total effort at the same quality, broader test coverage for the same effort or a clearer recommendation. Decide before seeing the result, so you cannot quietly move the goalposts afterwards.

Compare the whole task

Count briefing, prompting, checking and correction, alongside the work needed to turn the output into something usable. Compare quality as well as elapsed time. Use another reviewer where that would give a fairer assessment.

Suppose a task normally takes 45 minutes. AI produces a draft in three minutes, but briefing and review take another 50. The generation was fast; that version of the workflow has not saved effort.

It might still be worth using if it reveals an important omission or improves the result. Record that benefit clearly. Do not turn it into a time-saving claim it cannot support.

Give the expert authority and support

The specialist should help set the acceptance criteria and identify the limits. That role needs time and recognition. Simply making them the final checking point for everyone else’s output can create a new bottleneck.

Use what they learn to improve examples and review standards, so more colleagues can work competently. The goal is to spread capability while keeping accountability clear.

Allow three possible outcomes

The trial may improve the workflow. It may need another iteration. Or the tool may be unsuitable for that task at present.

All three are useful findings. If only the first is acceptable, you are running a demonstration designed to produce a positive result.

When something does work, repeat it enough to understand whether the benefit holds. Then let the expert explain the result to colleagues in the language of their own discipline. A credible example travels further than a generic promise.

Measure the decision, as well as the activity

This is part of the distinction I make between adoption and enablement. Usage data has a purpose. It can show where people are trying the tools and where support may be needed. It cannot, by itself, tell you whether the work has improved.

For each useful experiment, I would keep a short record of five things: the task, the baseline, the observed result, the business consequence and the next decision. Include the limits of the evidence.

That gives you something a finance director and a specialist can both interrogate. It also helps close the AI adoption gap between individual experimentation and measurable business value.

You may find that someone who uses AI infrequently gets substantial value from a few well-chosen tasks. You may find that someone who uses it constantly creates work that colleagues have to correct. The usage chart alone will not tell you which is which.

A word to the expert

If you recognise yourself in this, I think there are two responsibilities on your side of the conversation.

The first is to be specific about your caution. Explain whether the problem is accuracy, missing context, checking effort, the way the work is measured or uncertainty about the organisation’s intentions. A concrete objection gives people something they can address.

The second is to leave room for a fair test. A poor result from one tool on one task does not settle the question for everything you do. Find a bounded piece of work, agree the standard and see what happens.

You do not need to suspend your judgement to use AI. Applying that judgement is part of finding out whether the tool deserves a place in your work.

The question I would take back to the board

Job seniority tells you little about whether AI will improve a particular task. The board needs evidence about the work and the people doing it. Some experts will be enthusiastic users. Others will be cautious for different reasons.

The useful challenge is this: have you made an offer that is credible to someone who already knows how to do the work?

That is how I would apply Rory Sutherland’s lens. Look beyond the neat calculation to the person making the decision. Reduce uncertainty. Make the value of their judgement visible. Test a small change and be willing to learn from an inconvenient result.

Your experts’ scepticism can improve the programme, if you give it somewhere useful to go.

Where to start

If your organisation has bought AI tools but is struggling to turn access into useful work, start with the wider readiness picture. My AI Readiness Assessment is a starting point for that conversation.

Take one real task to the people who understand it best. Give them the time and authority to test it properly. Before asking for more enthusiasm, give them evidence that AI makes their work better.

Useful Links

DBA Value in the AI Era: Lessons from Rory Sutherland

What Is a Consultancy AI Operating System?