Consulting · Team AI Adoption
The licences got bought.Nothing changed.That is not an adoption problem.
Seat count went up and cycle time did not, because the tool was bolted onto a workflow designed for a world where implementation was the expensive part. It is not any more.
- [PLACEHOLDER: Team engagement price]
- 90 days
- Remote · product and engineering, run separately
- Monthly working session for the full term
- Metrics leadership can actually read
Who this is for
Three people usually start this conversation.
All three are looking at the same gap between what was bought and what changed. They are looking at it from different heights, which is why the training runs separately for product and for engineering.
01
The person who signed the invoice
VPs · heads of engineering · founders
You approved the seats on a business case about velocity and you now cannot evidence any. The uncomfortable part is that you half suspect the business case was right and the rollout was not, and nobody in the reporting line is incentivised to say which.
02
The lead watching two people use it properly
Team leads · staff engineers
Two engineers have quietly rebuilt how they work and are visibly faster. Everyone else opens it for boilerplate and closes it again. You cannot work out what the two are doing differently, and neither can they, which is the normal state of an undocumented skill.
03
The product org where nobody agrees what a ticket is
Product leads · delivery managers
Implementation got cheaper and the process did not move, so PMs write the same tickets they wrote in 2023 and engineers answer them with output nobody scoped. The arguments look like personality clashes and they are almost entirely a specification standard that does not exist yet.
When this is the wrong engagement.
Four of them, and the first two are the ones that actually come up.
- You want a one-day workshop and a deck. Ninety days is the point: a workshop moves behaviour for about a week, and I would rather not take the fee for that.
- Leadership will not change any process. If the workflow is fixed, the honest framing is that you bought a faster autocomplete, and you should size the expectation to that rather than pay me to raise it.
- You want a number for how many seats you can now cut. This is not a headcount exercise, I will not let it be dressed as one, and a team that suspects it is will tell me nothing useful for ninety days.
- The team has not been told this is happening. I will not be introduced as the consultant who arrived to evaluate them: the first fortnight depends entirely on people being honest about how they actually work.
The problem
The pilot succeeded. That is why nothing changed.
Almost every stalled rollout followed the same path, and it is a path made of individually sensible decisions. Somebody ran a pilot. The pilot went well, because pilots are run by volunteers on problems they chose. Licences were bought for everybody on the strength of it. And then the tool met a workflow that was designed, reasonably, for a world in which writing the code was the expensive step.
So it gets used for the cheap parts. Boilerplate, tests, a regex nobody wants to think about. Real gains, small ones, and entirely invisible at the level where the spend was approved. Meanwhile the expensive step moved: it is now specification, review and integration, and none of those got a single hour of attention during the rollout because none of them were the thing that was purchased.
The failure mode is not resistance. Resistance is loud and you can address it. This is quieter: everyone uses it a bit, nobody changes anything structural, the numbers do not move, and in about three quarters somebody concludes the technology was overhyped rather than that the workflow was never rebuilt around it. I have watched that conclusion get drawn inside a real company, which is most of why this engagement exists.
The ninety days
Four phases, and the first one is doing nothing.
The order matters more than the content. Every version of this that starts with training produces enthusiasm in week one and nothing measurable by week six.
01
Days 1–14: watch, do not teach
How the team actually ships, not how the process document says it does. Where work waits, who unblocks it, what gets written down and what travels by conversation. No training in this fortnight at all, and telling the team that in advance is what makes the fortnight honest.
02
Days 15–30: one workflow, rebuilt end to end
One real workflow, usually the one with the longest wait in it, redesigned around specification rather than around implementation, and run live with the people who own it. One is deliberate. A team that has seen one thing genuinely change argues about the second one on the merits instead of on principle.
03
Days 31–60: the spec standard goes team-wide
Live training for product and for engineering, run separately because they have different problems and the joint session is where both groups stay polite instead of honest. Out of it comes one shared standard everybody writes against, plus repository-level configuration and review conventions so the standard has somewhere to live other than a wiki page.
04
Days 61–90: measurement and handover
Adoption metrics that show what the spend bought, chosen to be defensible rather than flattering, and a named person inside the team who owns the standard after I leave. If nobody will own it, the standard has about a quarter of life left in it and it is better to say so now.
05
After day 90
You are left with the standard, the configuration, the recordings and the metric. What you are not left with is me, which is the intended outcome: a ninety-day engagement that turns into a retainer is one that did not transfer.
What is in it
Ninety days, itemised.
What the programme includes
- Audit of how your team actually ships today, not how the process doc says they do
- Live training for product and engineering, run separately: they have different problems
- A shared spec standard the whole team writes against
- Repo-level configuration and review conventions
- Adoption metrics so leadership can see what the spend bought
- Monthly working session for the full 90 days
What is not in it: hiring, tool procurement, a security or compliance review of any vendor, and anything resembling an assessment of individual performance. [PLACEHOLDER: the team size band this engagement is built for (minimum and maximum)] [PLACEHOLDER: whether the ninety days are delivered fully remotely, partly on site in Islamabad, or either]
The price
What it costs, and what it does not come with.
The Build Sprint carries a first-week refund. This does not, and pretending otherwise would be the easier sentence to write: ninety days of a team's attention is not something money makes whole, so the honest protection is a first fortnight that is observation only and commits you to nothing structural.
Ninety days, one rebuilt workflow and a standard that outlives it
[PLACEHOLDER: Team engagement price]
90 days
Exit terms: [PLACEHOLDER: exit terms for the 90-day engagement (notice period and treatment of fees already paid)]
The objections
Four challenges worth answering properly.
Our engineers already use it every day. What is left to adopt?
I approved this spend. Bringing someone in makes it look like I got it wrong.
We cannot put company code into a third-party model.
Ninety days is longer than our planning horizon.
Next step
Start with the call, not with a proposal.
Thirty minutes to work out whether your gap is workflow, specification or something that has nothing to do with either. If it is not this engagement, I will say so on the call; it is the largest thing I sell and the one I most often talk people out of.
P.S. If you take one thing from this page without ever speaking to me, take the ordering. Watch for two weeks before you teach anything, and change exactly one workflow before you change a second. Most rollouts that failed did the content right and the sequence backwards.