Most organisations I talk to reach the same point. The licences are in place. A few enthusiasts are getting real value. Everyone else tried the tools twice, got something they had to redo, and went back to the old way. Then the board asks what changed, and nobody can answer with confidence.
The group who tried the tools and went back is bigger than most leaders expect. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they were using or planning to use AI tools in their development process, yet more of them actively distrusted the accuracy of those tools (46%) than trusted it (33%). People have the tools. Many of those people don't yet trust what the tools produce.
So the question I get most often is some version of this: how do we get people to use the tools after buying the licences? My answer starts with the work around the tools, and a few of the changes to that work can only come from the leadership team.
Decide what good looks like before anyone is trained
Every programme I run starts with a kick-off where leaders and teams agree what good looks like, and where cross-role teams are formed. A kick-off can sound like ceremony. This one produces the standard and the teams that the rest of the programme depends on.
Before the kick-off I ask the sponsor for three things: the criteria that make a project worth approving, a few example project shapes that fit the organisation, and some pre-approved ideas. I also ask for the limits: compliance, security, data access, and what is out of bounds. When the criteria and limits are visible from day one, teams aim at problems the business actually wants solved. Without the criteria and limits, people practise on toy examples, and that practice doesn't carry over to their real work on Monday morning.
Setting those criteria and limits is the first leadership change. Someone senior has to say, in writing, which real problems are fair game and what the boundaries are. Teams can't make that decision for themselves, and when they are left to guess they choose the safest option.
Protect practice time inside the working week
The second leadership change is time for practice. A programme fits when the organisation can protect a few hours a week for practice on real work. If people are expected to learn this on top of a full delivery load, they will quietly drop the learning, and they'll be right to.
I measure both time and incentives directly. My pre and post tracker asks each person whether they have time to work this way while hitting their current commitments, and whether the way their work is measured rewards working this way. Those two answers describe the employer far more than the person. A team can believe in working this way and still score low on both questions. When that happens, the blocker is the schedule and the incentives, and only leaders can move those. I go into how to read those tracker results in how to measure AI adoption in a software team.
Bring the whole team in together
AI adoption that starts and ends with developers tends to stall once the work moves beyond the code. Stories still arrive vague. Test design still happens by hand afterwards. Product and QA can't read what the agent produced, so they can't judge it.
Those problems are why my groups mix developers, testers, product, delivery, and the people in marketing and operations who were told AI would help them too. The whole group learns one shared way of working. I've written more about why in AI training for the whole team, and about where people who don't write code fit in can non-developers use Claude Code?
Practise on real work, in a repeating rhythm
A single workshop produces a good afternoon and very little change. Skills stick when they are introduced gradually and revisited, practised on real work with feedback, and recalled often enough to become habit.
I design every phase around the same rhythm: introduce, practise, reflect, refine. Try something on your own work, look at what happened, adjust, and try again. That rhythm runs through the whole engagement.
In the programme for teams, that rhythm takes the shape of eight two-hour masterclasses, each applied to your real work from requirements through to review. A few topics run through all eight masterclasses:
- Context. The difference between useful and useless output is usually what the model knew. Teams learn to keep a short set of project ground rules the agent reads every time. See why context matters more than the prompt.
- Checking. Agents report success confidently whether or not the work is done. Teams learn to ask for evidence and to put automatic checks in front of every change. See how to check AI output.
- Reuse. Anything a person does three times can become a small, shared procedure the agent follows. See turning repeated work into a skill.
- Unattended work. Some tasks can run while you're in a meeting, and most can't yet. See what AI agents can run without you.
Put someone between the sessions
Most rollouts stall in the gap between a good session and the next real task. Someone hits their legacy system, an awkward compliance question, or a workflow nobody else has, and there's nobody to ask. They take the task back and finish it by hand. Next time they don't start with the agent at all.
I hold office hours between every masterclass so that people can bring the problem only they have. Office hours are also where anyone can bring the question they didn't want to ask in front of the group. Over the programme, a few people become the ones their colleagues ask first. By the end, your own people are answering each other's questions and the shared way of working is written down.
For leaders, the change here is to treat support between sessions as part of the rollout. Budget for that support the way you budget for the licences.
Where a team agrees to it, I also look at how they actually use Claude Code between sessions and aim the next session at what I find. I describe the method, and how consent is handled, in coaching AI adoption from real usage.
Finish on your own backlog
The programme ends with a hackathon. Teams take real problems from your backlog and build them end to end with what they've learned, and I work alongside them.
How the hackathon is judged matters. Teams are scored on the change from a tagged starting point, nearly half the points go to how they learned and used AI, and token, prompt and commit counts don't count as achievements. That scoring tells everyone what the organisation values. If you reward volume, you'll get volume. I explain the scoring in more detail in how to measure AI adoption.
What running an engineering department taught me about this
At a software company where I've been fractional CTO, I run an engineering department of five cross-functional teams: DevOps engineers, developers, test engineers, business analysts and product owners. Over that time we adopted Agile, Lean and DevOps principles, which reduced the software delivery cycle by 75% and increased deployment frequency by 400%. All teams now average 90% unit test coverage. I've also trained and coached four of those teams to augment their daily workflows with AI tooling.
The lesson I carry from that work is that a new way of working spreads through practice, coaching and standards the team writes down for itself. Testing, CI/CD and small releases took hold that way, and I see AI-assisted work taking hold the same way. Running that department also made me value the groundwork: a team with automated tests and fast feedback can safely absorb the extra change an agent produces, and a team without them mostly gets more breakage.
A short checklist for the leadership team
Before you sign off another round of licences, check that you have:
- Written down which real problems are fair game, and where the limits are.
- Protected a few hours a week for practice, inside the working week.
- Put developers, QA, product and delivery in the same sessions.
- A rhythm of practice on real work, spread over weeks.
- Someone people can ask between sessions.
- A way to show what changed, measured from a baseline.
- Incentives that reward evidence of better work over activity counts.
If several of those seven items are missing, the licences will keep sitting mostly idle, however good the tools get.
Talk through where you are
If you've bought the tools and usage has stalled in the way this article describes, book a conversation. Tell me what you've bought, what's happening, and what the board is asking, and I'll tell you plainly whether the programme fits, or what would fit better.