Rolling Out AI to a Two-Speed Team

Note: Statistics and figures reflect data available as of November 2026. Verify for latest figures.

Part 2 of the Playbook (tool evaluation) is coming. This part stands on its own.

Ten months after my team started using AI coding tools seriously, 81% of our commits carried an AI co-author tag. At the start it was 17%. On a slide, that line goes up and to the right and everyone nods.

The slide hides the real picture. Adoption did not rise evenly across 17 engineers. It rose fast for about half and barely moved for the rest. For months I had two teams wearing one name: a fast half that had changed how it worked, and a slow half doing exactly what it did the year before, quietly annoyed at being asked why.

There was no single moment. The split became visible slowly, in stand-ups and on the sprint board in Azure DevOps. The same kind of story would close in a day on one side of the board and sit in progress for most of a sprint on the other. My first diagnosis was awareness. I assumed the slow half had not seen enough of what the tools could do, so I scheduled more sessions for them. The sessions were well attended and changed almost nothing. I had reached for the one fix that works on only one of the four reasons below, and most of my slow half were not in that group.

Every team I know is now a two-speed team. This part of the Playbook is about the slow half, because the fast half does not need you.

The slow half isn't lazy

My first mistake was treating the slow half as one group. They are not. Resistance comes from one of four places, and the fix for each is different.

1. Identity. "My value is that I know this codebase." For a senior engineer who has spent eight years becoming the person everyone asks, a tool that answers those questions in seconds is not a convenience. It is a threat to what makes them valuable, and they are not wrong to notice.
2. Quality. "The code it writes looks right and isn't." This one is often correct. I will come back to it, because a manager who dismisses it loses the room.
3. Incentives. "I get appraised on hours billed and bugs closed, not on how I work." If the appraisal form rewards the old way, people do the old way. This is rational, not stubborn.
4. Never shown a win. They sat through a demo on someone else's code. It looked fine. It did not touch anything they do on a Tuesday, so nothing changed on Tuesday.

Mandates and adoption dashboards only deal with the fourth one, badly. The manager's job is to work out which of the four they are looking at, person by person. A team-wide message cannot do that. A one-to-one can.

Why "just mandate it" fails

Access is not adoption. The data on this is unusually clear.

Stack Overflow's 2025 Developer Survey, with over 49,000 respondents, found that 84% of developers use or plan to use AI tools. In the same survey, 46% actively distrust the accuracy of those tools, against 33% who trust it, and the most experienced developers were the most skeptical group.

DORA's 2025 State of AI-assisted Software Development report, from nearly 5,000 professionals, found about 90% using AI at work and still 30% with little or no trust in the code it produces. Its headline finding belongs on a wall: AI amplifies what a team already has. Teams with fast feedback loops saw gains. Teams with slow processes and tightly coupled code saw little or none.

So a mandate gives you seats. It does not give you belief, and it does not fix the process the skeptic is worried about.

I have my own small version of that finding. Of the 47 repositories my team works in, 25 carry an AI instruction file. Only 5 enforce anything through a hook or a CI gate, and those five are where behaviour actually changed. An instruction file nobody reads is a mandate nobody follows. A hook runs on every edit whether or not anyone remembers it.

The Skeptic Conversion Matrix

Here is the tool I use to stop treating the slow half as one group. Two questions, asked about each person, not about the team.

• Can they? Do they have the access, the setup and the basic skill to get a result on their own work?
• Will they? Do they believe it is worth doing, and does anything in their incentives reward it?

Most managers spend their energy in the bottom-left box, fixing access, then wonder why the top-right box has not moved. That box is where the senior people are, and they are the ones the rest of the team watches.

One rule for it: the skeptic runs the experiment. If you prove them wrong, you have won an argument and lost an engineer. If they prove themselves wrong on their own code, they tell the story for you.

What moved one engineer

One engineer, about eight years in, had tried the tools early and put them down. His working model was that AI meant text generation: useful for a snippet or a doc comment, limited beyond that, not worth changing a working routine for. He was in the top-right box. He could, he just did not believe it was worth it, and nothing I said in a group session moved him.

What moved him was seeing an agent work with a current model: not autocomplete, but a task taken from ticket to pull request, with tests, on the kind of work he did every week. His objection had been about a version of the tool that no longer existed. Once he saw what agentic tools could do, he went from skeptic to one of the people others ask for help. Nobody converted him. He updated his own model of what the tool was.

The conversions I trust most were never the ones I engineered. Some of the hook patterns that now enforce our conventions were written by engineers themselves and spread by copying from one repository to the next. The instruction file for our QA repository started as mine. Six other people have edited it since, over a hundred commits, because it was the fastest way to stop the agent making the same mistake twice on their work.

That is the signal I look for now: not seats activated, but who is editing the rules without being asked.

The one I misread

The one I misread was a front-end specialist with about seven years of experience, good at interface and design work, and clear that this was where he wanted to stay. He resisted the AI tools, and for a while I treated that as a tool objection and kept showing him better ways to use them.

It was a role objection. Any story that touched the back end needed someone else to assist: a handoff out, a handoff back, delays on both sides, and in the end nobody who owned the deliverable. The AI tools threatened that arrangement, because they made it realistic for one person to take a story end to end.

The fix was not a pilot or a demo. It was a team decision: everyone steps up to full-stack work, with AI assistance, and owns their delivery. That is a harder conversation than a tool rollout, and I should have had it months earlier instead of scheduling more sessions. The top-right box sometimes holds a resistance that has nothing to do with AI. The tool just made the real issue impossible to keep avoiding.

The 4-week pilot playbook

A pilot is how you turn a skeptic's objection into a measurement. Keep it small. One task, two people, one number.

Week 1: pick the task and take the baseline.
Choose one painful, recurring task the team already complains about: API tests for a new endpoint, porting a page object, reproducing a bug report as a failing test. It must be something the skeptic does regularly, or they will dismiss the result as irrelevant to real work. Record how long the last five instances took, from pickup to merged. That is your baseline. Without it you will have an "after" and nothing to compare it with.

Week 2: pair an adopter with a skeptic.
They do the task together, on the skeptic's own code, the adopter driving and the skeptic reviewing every line. Write the instruction file for that task as you go: what the agent must check, what it must never touch, which tests must pass. Keep batches small. DORA's 2025 report singles out small batches as the practice that matters most with AI, because a tool can produce a thousand lines faster than anyone can review them.

Week 3: the skeptic owns the gate.
Swap roles. The skeptic drives and decides what merges. Measure cycle time on that task only, and count bounce-backs: anything that goes to review and comes back. If quality drops, you want the skeptic to be the one who catches it. Then the quality worry is being taken seriously by the person who raised it.

Week 4: the skeptic presents.
Hold a retro. The skeptic, not the adopter and not you, presents the numbers: baseline, result, what broke, what they would change. If the result is bad, say so and change the task or the rules. A pilot that cannot fail is a demo, and the team knows the difference.

Then pick the next task and the next pair. Four weeks, repeated, is how a slow half becomes a team.

Incentives: read the appraisal form

If a skeptic's reason is incentives, no pilot will fix it, because the pilot ends and the appraisal cycle does not.

In Indian IT the appraisal form usually rewards utilisation, closed tickets and visible effort. The late-night fix that saved the release gets praised in the all-hands. The engineer who spent an afternoon writing a hook so nobody ships that bug again gets nothing, because there is no box for it. People optimise for the form. They are not being difficult. They are reading it correctly.

Three changes I would make, in order of how hard they are to push through:

1. Stop praising heroics in public. A midnight fix is a process failure that one person absorbed. Thank them privately. Fix the process publicly.
2. Add one line to the appraisal: "made someone else faster". Instruction files written, hooks contributed, pairing sessions run. If it is not on the form, it did not happen.
3. Measure the team's flow, not the individual's hours. I wrote in the ROI post about why hours saved is the wrong number. The same logic applies to appraisals. Cycle time on real tasks is harder to game than a timesheet.

Some skeptics are right

This series could read as "the resistant engineer is the problem". Often they are not.

AI-generated code on a legacy codebase with no tests is risky. The code looks right, reviewers skim it because it looks right, and the defect reaches production. I have had an agent invent a ticket ID that ended up in two published changelogs that cannot be edited. I wrote up that failure, and two others, in the six-month case study. The skeptic who says "it will make things up" is describing something that happened to me.

There is a bigger version. When I measured where my team's time went, a typical small story spent 4 days in development and 17 days in QA, and finished code waited a median of 90 days to be tested. Making developers faster did not get a single feature to a customer sooner. The skeptic who says "faster coding just makes the queue longer" is making the argument from the SDLC bottleneck post, and they are right.

So the honest pilot includes the skeptic's conditions. Tests first on legacy code. A review gate they control. Security review for anything an agent touches that holds credentials or customer data; the agent security post covers what to look for. If those conditions make the pilot slower, good. The number at the end is one the whole team will believe.

What's next in the Playbook

• Part 2, The 5P Framework: how to evaluate AI tools for your team without getting sold by vendors. Coming next.
• Part 4, Measuring AI ROI: why "hours saved" is the wrong number, and the Value Pyramid I use instead.
• Part 5, Hiring in the AI Era: the interview questions that separate AI-ready engineers from the rest.
• Part 6, Your Career as an EM: where engineering leadership is going in 2027 to 2030.

You can find every part, and what is coming, on the Playbook page. If you have run a pilot like this and it went differently, tell me. This playbook gets better when real engineering managers push back on it.

Now go and work out which box each of your skeptics is in. Then book the one-to-one.

Related Reading

• Who Is the Engineering Manager, Really?
• AI Made Coding Fast. Delivery Didn't Get Faster.
• How to Measure ROI from AI in Engineering Teams
• The 'AI Is Just a Fad' Mindset Is a Career Mistake in 2026