Buying the AI tools was the easy part

Access removes friction; it does not create adoption

How do you know whether your team is actually adopting AI? I recently discussed this with a company leader who believed the engineering team was already quite far along. How do you know AI is being used effectively, what does it even mean?

To get a clearer picture, I spoke with members of the team about how they used AI. AI usage had never been discussed as a team, and most of the examples I heard were still code completion and small assists. People had been left to choose a tool and get started on their own, which works for those eager to experiment. If you want adoption beyond that group, you have to make suitable tools easy to access. Providing an account removes a practical obstacle, but it does not teach people where AI belongs in their work.

Adoption spreads through the team

AI has brought engineers more than promises of productivity. It has also brought an identity crisis. If tools can write more of the code, where does that leave the engineer? Two types are on the opposite side of the spectrum. Enthusiasts explore what is possible. Skeptics ask whether any of it should be trusted. Most people sit somewhere less dramatic, waiting to see whether any of it helps with their work.

You need both groups, and either can derail adoption. Give the enthusiasts free rein and the team’s workflow becomes a patchwork of this week’s tools and last week’s abandoned experiments. Let the skeptics set the pace and the smallest mistake is enough to discard the whole idea. The skeptics' concerns are useful when they become quality criteria: what are we trying to improve, what could go wrong, and how will we know whether the result is good enough? They stop being useful when finding one wrong answer is enough to end the experiment.

Make experimentation visible and safe

The fastest way I have seen adoption spread is through someone inside the team showing how they actually work. Give the enthusiasts a podium, not to pitch the newest tool, but to demonstrate a real task, including what failed. I have seen skeptics try a tool after watching a colleague use it. They did it on their terms, with safeguards they trusted.

Showcasing experiments only works if people have the time to act on what they see. Don't expect people to experiment between the different deadlines they have to make. Give engineers a place to collect ideas, to try them with real work, and share what they learned.

Measure changed work, not AI activity

It's important to measure the right outcomes. Number of pull requests is the wrong metric. How do you assess whether AI has had a positive impact? Did the team's work improve?

Are features reaching customers faster, and are customers actually using them? Are fewer bugs reaching production, or are bugs resolved sooner? These measures will not prove that AI caused every improvement. They do move the conversation closer to delivered value than counting generated pull requests.

Ask someone to show you one repeated workflow they changed. Ask what improved, what evidence they kept, and whether they still use it. If they cannot show a changed workflow, you are probably still measuring access or enthusiasm.

Creating a Claude Team and assigning a credit card can remove the first practical obstacle. It gives people a place to start without turning every experiment into a request to access a new tool. The adoption work comes afterwards: internal examples, protected time, useful skepticism, and evidence that a workflow improved. If all you end up with is an invoice, you only bought seats. You still don't know whether anyone changed how they work.