Why AI Adoption Is a Leadership Problem

Most companies treat AI adoption as a technology problem: they buy the tools, put people through training, and wait for results that often don't arrive. We've run these programmes inside a number of engineering organisations, and the technology is rarely the thing that decides how they turn out - the deciding factor is almost always leadership. By the time the tools are in people's hands, most of the technical work is behind you, and what happens next comes down to a set of human and organisational problems that no tool solves on your behalf.

There's good data on this now. The 2025 DORA report surveyed thousands of engineers, and its central finding is that AI works as an amplifier: a strong engineering team becomes meaningfully more capable with it, while a weaker one tends to get worse, because the tooling adds speed and pressure to whatever is already there. DORA's own reading is that the value of AI comes mostly from the practices and the culture around it rather than from the tool itself, and that lines up closely with what we find when we work with these teams.

What moves the adoption curve

Across the organisations we work with, the same rough pattern tends to repeat. Roughly one in ten people are ready from the first week, and they'll run several agents at once and push the tooling further than you asked. Another three in ten come along once they've seen a working example inside their own team. About half will move with a clear expectation and some support behind them. The last one in ten resist for as long as they can, and a few of them never come round.

A clear signal from the top is important. When a CTO makes it plain that fluency with these tools is now expected, people stop treating adoption as optional, and that really shifts things. On its own, though, a mandate usually backfires, because it arrives as pressure without any of the support that would make the pressure fair. I once watched a company put up a dashboard that ranked its engineers by how many tokens they'd consumed, as if usage were the point, and a measure like that buys gaming and quiet resentment far more than it buys adoption.

A sceptic is rarely won over by a mandate, and more often by getting hands-on with the tools. People need somewhere they can try the tools without being judged, and they need to see output good enough to change their minds - on more than one occasion, the thing that shifted someone was watching a current model produce solid code on a piece of their own work. It also helps a great deal to hear it from a colleague they already respect, rather than from a vendor or a slide.

The trap of saved time

There's a more quiet failure here that troubles me more than open resistance, because from the outside it can look like things are going well. You give people the tools, some of them get faster, they finish their work in less time than before, and then a surprising number of them do nothing with the hours they've freed up. Those hours fill with other things, the week stays just as full, and you end up having paid for the tools, paid for the training, made people individually faster, and delivered roughly what you delivered before.

From a distance the programme looks healthy. People are using AI, the survey scores are good, and the team's output sits about where it always did. That's why "are people using AI" is the wrong question to ask. People aren't reliable judges of their own speed: in one randomised study, experienced developers were around 19% slower with early-2025 AI tools even as they felt faster. The question worth asking is whether you're delivering more than before, and if a tenth of your engineers are saving most of their time while the backlog moves at its old pace, what you've bought is a set of expensive tools and not much else.

Your most experienced people struggle the most

A good manager's instinct is to step back. You hire capable people, you trust their judgement, and you stay out of their way, and for most of the work, most of the time, that's the right instinct. During a change like this one, it isn't.

For a while AI can make your most experienced engineers inexperienced again, because the instincts they built over years - about what good code looks like, how to structure a system, how long a task should take - stop matching how the work is now done. The response should be to move closer to the work for a time, directing and coaching more than you usually would, the way a senior engineer on a live incident gives clear instructions rather than opening a discussion.

What this looked like at Odevo

The clearest example I can point to is Odevo, a Swedish company with around a hundred developers. When we ran their AI-native bootcamp, the response split the way it usually does: a few people took to it immediately, most sat somewhere in the middle, and a few didn't like it at all.

There were many measurements that showed success, but the moment that did the most to change people's minds was a single concrete result. One engineer had been stuck on a difficult rewrite, and using the new way of working he built a mobile app in three days. It's live in both app stores today, and before that the same piece of work had gone nowhere for a year and a half. That result showed managers what was possible and gave the sceptics a reason to look again.

What followed is something the team described in their own words as the "scared curve" flattening, as the people who'd been anxious or dismissive started to come round. Agentic coding across the organisation rose by roughly 400%, and the share of engineers who described themselves as hesitant about AI fell from around half to almost none.

One of the biggest improvements after the training is the change in the people, more than the speed of the rewrite or the app in the stores: a group of experienced engineers moved from doubt into steady, everyday use of these tools and didn't drift back. That happened because we led them across, rather than waiting for them to find their own way. None of it depended on tooling the rest of the field doesn't also have. What it needed was leadership willing to lead the change for as long as it took.

Frequently asked questions

Why do most AI adoption programmes stall? Usually because of people and leadership rather than the tools, which tend to work well enough on their own. What's often missing is a leader who sets a clear direction, plans for an adoption curve that always takes time, and makes sure the hours people save get spent on work that matters. The 2025 DORA report describes AI as an amplifier of whatever a team already has, which is part of why two companies with the same tools can end up in very different places.

How should leaders manage teams through AI adoption? By directing and coaching more than they normally would. A large change temporarily turns experienced engineers back into beginners, because their instincts no longer match how the work is done, and the usual habit of stepping back becomes the wrong move. It helps to pair a clear expectation with a safe place to learn, visible proof that the output is good, and a respected colleague who has already made it work.

re:cinq runs AI-native adoption and transformation programmes for engineering organisations, including the work behind the Odevo results above. If your team has the tools but the change isn't taking hold, talk to us, or start with our free book, From Cloud Native to AI Native.