Adoption That Is Real Rather Than Reported

The instinctive response to slow adoption is a target: every team must use AI, or usage must reach some percentage by a date.

What that reliably produces is compliance behaviour. People open the tool, generate something they do not use, and the dashboard improves. The organisation now has a metric that is rising and a practice that has not changed, which is worse than a low number honestly reported, because it removes the signal that would have prompted a look.

The deeper problem is that a mandate answers the wrong question. Adoption is not the objective. Better outcomes are the objective, and adoption is one possible route to them. A team that correctly concluded AI does not help with their particular work and used it anyway to satisfy a target has been made worse off in service of a proxy.

What works better is narrower and slower: identify a specific task where the tool plausibly helps, make it easy to try, remove the obstacles, and let the result be visible. Adoption driven by a colleague demonstrating something useful is durable. Adoption driven by a target lasts exactly as long as the target is measured.

The managerial discipline is to keep asking what got better rather than how many people are using it.

Reluctance is usually treated as an obstacle to overcome. It is more useful treated as data, because the objections are frequently correct.

The common ones, and what each is actually reporting.

It gets things wrong in my domain. Often true and specific. Someone with deep expertise is detecting errors a generalist would miss, which makes them the most valuable evaluator on the team rather than the least cooperative.

Checking takes longer than doing it. The verification tax from the previous lesson, observed directly. This person has run the calculation you should be running.

I do not trust where the data goes. A legitimate governance question. If it cannot be answered, that is a finding about the tool rather than about them.

I am worried about my job. The only objection that is not about the tool. It deserves a straight answer rather than reassurance, and a manager who does not have one should say so instead of improvising something comforting that later proves false.

And this feels like cheating. A norms question that the disclosure and standards work addresses, and it is worth taking seriously rather than dismissing, because it usually reflects pride in the craft.

The move in every case is to ask which one it is. Four of the five have concrete answers, and the fifth is the one where honesty matters most.

Three layers of measurement, only the third of which answers the question worth asking.

Activity metrics: seats provisioned, logins, prompts sent. Cheap, always available, and they measure whether people opened a tool. They are the metrics that go on a slide and they support no conclusion about value.

Behaviour metrics: which tasks changed, whether the output is used or discarded, whether people return to the tool unprompted for a second task. Harder to collect and far more informative, because a tool used once and abandoned looks identical to a tool used daily in the activity layer.

Outcome metrics: cycle time on the actual work, quality as measured by rework and defects, cost per unit of output, and whether the team can absorb more work without more people.

The direction of the arrow matters. Activity is a leading indicator of nothing in particular, and organisations that report it are usually reporting it because the other two are harder.

And all three need the counterweight: quality, rework and the review queue, which is where a throughput gain most often turns out to have been borrowed.

Most AI pilots are demonstrations. A few design choices turn one into evidence.

Pick one task, not one team. A team-level pilot mixes a dozen different tasks with different verification taxes, and the result is an average that describes nothing. One task, one clear before-and-after.

Measure the before. This is the step almost universally skipped, and skipping it makes the after uninterpretable. Two weeks of baseline on cycle time, rework and volume costs little and is the difference between evidence and impression.

Define what would count as failure, in advance. If no result would cause you to stop, you are running a rollout with extra steps, and everyone involved knows it.

Include a sceptic. A pilot staffed entirely with volunteers who wanted the tool measures enthusiasm. The person who objected on domain grounds is the one whose participation makes the result credible.

Run it long enough for the novelty to wear off. Early enthusiasm is real and temporary, and a four-week pilot mostly measures it.

And measure the counterweights alongside the gain: rework rate, review queue length, and defects found downstream. A pilot reporting a throughput improvement without those numbers has measured half of the effect, and it is usually the flattering half.

AI adoption creates differences within a team that a manager has to notice, because they compound quietly and are rarely raised directly.

Uneven benefit. The tools help most with tasks that are verbose, structured and routine. Team members whose work is mostly that gain a great deal; those doing mostly judgement, relationship or physical work gain little. If recognition follows measured output, the second group is penalised for the composition of their role.

Uneven access. Language, disability and expertise interact with these tools unevenly. Some people benefit substantially, and some find the tools work poorly for how they work. Treating uptake as a proxy for engagement penalises the second group for a tool limitation.

Uneven risk. Someone using AI heavily and shipping a polished error carries more visible blame than someone slower and more careful, unless the manager makes clear that the standard is unchanged and that speed is not the metric.

And the confidence gradient, which is the one most often missed. People who are confident experiment freely and gain; people who are anxious about being seen to need help do not try, and fall behind for reasons that have nothing to do with capability.

The managerial responses are unglamorous: recognise contribution rather than output volume, offer support privately as well as publicly, and check who is not adopting before concluding they are resistant.

The question underneath most resistance is rarely asked directly, and how a manager handles it determines whether anything else they say is believed.

Three failure modes to avoid.

False reassurance. Promising that nobody's role will change, when you do not control that, buys short-term calm and destroys credibility permanently when it proves untrue. Everything you said about the tools is then reconsidered in that light.

Evasion. Answering a direct question with a statement about augmentation not replacement is heard as evasion, because it is. People notice.

And catastrophising, which drives the best people to leave first, since they have options.

What works is bounded honesty. Say what you know, say what you do not, and say what you will do.

What you know might be: the plan for this team this year, whether headcount reduction is on the table, and what the organisation has actually decided rather than what it is discussing.

What you do not know is usually most of the medium term, and saying so is more credible than the alternative.

What you will do is the part within your control: that you will tell them when something changes rather than letting them find out, that you will invest in their development, and that you will be honest when the answer is bad.

A team that believes their manager will tell them the truth handles uncertainty far better than one being managed with optimism.

Adoption has a characteristic shape: initial enthusiasm, a trough when the limitations become apparent, and then either a durable practice or quiet abandonment.

The trough is the important phase and the one managers are least prepared for, because it looks like failure and is actually calibration. People discover the tool is unreliable at some things, the novelty ends, and usage falls. That fall is healthy if what remains is the use that genuinely helps.

Four things determine which way it resolves.

Whether the successful patterns get shared. The specific prompts, workflows and task types that worked for someone need a route to everyone else, or each person rediscovers them independently and most give up first.

Whether the failures get shared too, without blame. A team that knows the tool is unreliable on this specific thing wastes far less time than one where everyone learns it individually.

Whether the friction is removed. Access, approval, integration into the actual workflow. A tool requiring three extra steps loses to the old way regardless of quality.

And whether anyone owns it after the launch. Adoption efforts almost always have an owner during the rollout and none afterwards, which is when the practice needs maintenance most.

A useful cadence: a standing item where people share one thing that worked and one that did not. Cheap, and it does most of the work of the first two.

Pulling the three lessons together into what is actually within a manager's control.

Clarity about accountability. The person who submits the work owns it, stated once and held to consistently, including when it is inconvenient.

A defensible standard. Written, unchanged by production method, and defended when volume rises and the queue tempts everyone to relax it.

Honest measurement. Outcomes rather than activity, counterweights reported alongside gains, and a willingness to conclude that something did not help. The METR finding means self-report is not measurement, including your own impression.

Protection of the constraint. Review capacity is the resource the change lands on, and it has to be planned for explicitly rather than absorbed silently.

Deliberate skill formation. If the tasks that built expertise are now automated, replacing that developmental path is a management responsibility, and nobody else in the organisation will notice it is missing until the seniors start leaving.

And honesty about the uncertain parts, particularly job security, because the credibility of everything else depends on it.

None of that requires a view on where the technology is going, which is fortunate, because nobody has a reliable one. It requires the ordinary managerial work of knowing what your team actually does, measuring what actually changed, and telling people the truth.