“We’ll borrow ten people for four months, then give them back.” That sentence, in the capacity plan, is what sends the AI gain back to zero.
An AI transformation isn’t a project with an end date. I deliberately call it AI adoption: the share of real product work your teams ship with the AI tooling, measured next to how long a merged change takes to reach production.
Better tooling doesn’t mean people will use it. A new version of Java helps nobody until somebody ships something with it.
A VP of Engineering, let’s call him Tomas, got the yes for his AI transformation. The selling part is in how to sell your AI business case to product. This post is the week after the yes, when you decide who does the work and how you’ll know it worked.
There is no AI transformation project
Tomas’s first plan had the classic shape: take ten people, build the AI setup, return all of them to their product teams after a few months, and the gain keeps compounding on its own. It’s a false assumption. AI moves so fast that you constantly need a team taking care of it, not ten people but at least three.
The usual advice frames it as a program. HBS Online lists four AI levers for transformation: strategy, governance, architecture and culture. All four are real. None of them names who stops doing product work on Monday, and that’s the decision that makes the other four happen.
Google’s DORA research found in 2025 that 90% of respondents already use AI at work, and that AI is “an amplifier, magnifying an organization’s existing strengths and weaknesses”. Tools are everywhere. What they amplify is your delivery system.
An MIT NANDA report from 2025 put it harder: 95% of organizations were getting zero return from their generative AI pilots. Its method is contested, it rests on 153 survey responses, but the shape matches what I see in mentoring: the pilot ends, the people go back, the gain fades.
It’s like asking why you have support engineers when the feature is finished. The feature was never the whole job.
Seven decisions for the first week
1. Cut a team off from product work
If you don’t pull those people out and build a new team around them, the old work keeps eating them. When we did this at a company I work with right now, we sent a cut-off AI team of eight people on a twelve-week mission, deliberately into the dark, like a rocket you launch. It didn’t talk to anyone on the ground, so people had time and weren’t disturbed.
The opposite version, “they’ll keep doing the product and we give them 4% of capacity for AI”, doesn’t work.
2. Keep a permanent core of three
One person who’s an educator and keeps up with the trends. A second who runs the evals and experiments. A third who keeps tuning the agent tooling and deploying it. Tomas’s team had already estimated they’d need about three people long-term; they just hadn’t cut the roles this way, and the three weren’t in the capacity plan yet.
3. Dissolve the rest after a few months
My rule of thumb: of the ten people you take, you keep three and send seven back into the teams. They spread how to use it, inside real features, which is the part no training does.
4. Budget the adoption, not just the tooling
Internal communication about why you’re doing it, workshops, hackathons, sometimes outside help. Not every person in your company is AI-native; I’ve never seen that in my life.
There’s usually a handful of people you build it around. Sometimes a company borrows that person as a contractor who looks internal, to get it running.
If you skip this budget, people see a bunch of guys doing something, then get told to use it, and they’re pissed. I wrote about what to do with the people who refuse in AI resistance sorts your team.
5. Pair the builders with a communicator
The strong people who build the tooling usually aren’t the communicative ones, and they won’t do the explaining you need done. However good your tooling is, if you don’t connect people to it seamlessly, you’re done. They want it, they’ll just say it hurts. The person you’re looking for is hands-on and on fire, showing teams “this feature took three days instead of two weeks”.
6. Make commit-to-production your second KPI
Tomas wanted to measure the transformation by how fast a team ships the first version of a solution. Fair. Then he described what happens after the code is written, and I asked him a hypothetical: what if the problem isn’t AI, but commit-to-production?
| Step after the code is written | Typical wait in Tomas’s org |
|---|---|
| Review by someone in another team’s codebase | 2-3 days |
| End-to-end tests | overnight |
| Release train | up to 2 weeks |
| Staged rollout to all customers | about 1 week |
| Merge to first real production load | up to ~3 weeks |
One real engineering org, anonymised. The agents also had no read access to production metrics, so they couldn’t check their own work.
DORA calls this change lead time, “the time it takes for a code commit or change to be successfully deployed to production”, and in its 2024 report elite teams do it in less than one day. Tomas’s teams were at up to three weeks, and every day of it is cost of delay.
If you only speed up the writing, you’ve optimised the shortest step.
A second KPI on merge-to-production makes the release train, the review queue and the missing read-only production access visible as AI problems, which they are. For an outside view on where your delivery time goes, that’s what a team productivity audit measures.
7. Own it at VP level, out loud
One move I like a lot, when the VP can afford it: take the AI work on personally for half a year and hand budgeting, roadmap planning and part of the incidents to a peer. You say out loud, in front of the board and your peers, that you’re accountable and you take the risk because you believe in it.
One warning: with your peer it’s not a full handover. It’s “thanks for guarding this for a while, I’ll keep helping you with the systems and processes”, and what your peer gets back is product teams that ship faster.
Call it adoption and measure it like adoption
Usage isn’t the problem, and it isn’t proof either. In METR’s 2025 study, experienced developers took 19% longer with AI tools and still believed they were 20% faster. A licence report would have counted all of them as adopters.
Better tooling doesn’t mean people will use it.
So the dashboard I’d want in month one has two lines, not ten: first version shipped, and merge to production. Plus one honest question per stream in the monthly review: what did the AI tooling change in how you worked this month?
The answer you want sounds like Tomas’s own, about his own work: his agent builds the progress table for the C-level in five minutes, he pastes it into Slack, and the hour of slide-making is gone. That’s adoption: the work changed, not the licence count.
What goes wrong in month three
Product starts cursing the platform
The cut-off team finishes, the people go back, nobody keeps the tooling current, and three months later the product teams say the platform promised them things that don’t work. It’s a platform failure in their eyes, whatever the cause. The permanent core of three is what prevents it.
The champion gets split three ways
Your most hands-on AI person is usually also the one production and the backlog can’t live without. If you don’t free their hands, they do all three badly. Free them, and find someone else for the other two.
You become the bad guy
When adoption fails, the teams don’t blame the tooling team. They blame the VP who didn’t take care of communication. That’s why decision 4 and decision 7 belong to you, not to the team.
Tomas hasn’t picked his team yet. When he has, the commit-to-production number is the first thing I’d look at.
How long does a merged change take to reach your production today? If you want help setting up the team and the two KPIs for your org, that’s the kind of work I do as a fractional CTO.
[Writing time: 3h]
