Rolling Claude Code out to a team without it stalling at three people
Table of Contents
Every rollout looks the same. Three people try it in week one, two of them get something impressive out of it, and adoption stops there. Six weeks later someone asks why the licences are not being used.
The tool is not the problem. The problem is that the three enthusiasts figured out what good looks like privately, and nobody wrote it down. Everyone else tried it once, got a mediocre result, and concluded it was overhated.
The failure is social, not technical
An engineer who has spent ten years being paid for knowing how to do things does not enjoy being visibly bad at a new tool in front of colleagues. So they try it alone, get a mediocre result on the first attempt, and quietly stop.
That first attempt is almost always mediocre, because effective use is not obvious. Nothing tells you that the model needs the failing test output pasted in rather than described. Nothing tells you to give it the file you already know is relevant instead of asking it to go looking.
None of that is intuitive, all of it is learnable in about twenty minutes, and none of it happens by handing out licences.
Standardise the context before the prompts
The single highest-leverage thing is a project instructions file that is actually correct. Not aspirational. Correct.
It should carry the things every new person asks in their first week: how to run the tests, which directories are generated, what the deploy path is, which conventions are real versus aspirational, and what is off-limits.
Most teams have this knowledge distributed across three senior engineers’ heads. Writing it down helps the humans too, which is the argument to use when someone objects to the time.
Get this right and everyone’s results improve at once, with no change to how anyone prompts. Skip it and every individual re-derives the same context every session, badly.
Run a working session, not a demo
A demo produces admiration. A working session produces adoption.
The format that works: everyone brings a real ticket from their own backlog. Something annoying, well-defined, and not urgent. You work through them together, out loud, in the same room.
What people learn is not the syntax. It is calibration - which tasks are worth delegating and which are faster by hand. That judgement is the actual skill and it transfers by watching someone else make the call, including the calls that go wrong.
Do not curate the tasks. A session where two of six attempts fail teaches more than one where everything works, because it shows what failure looks like early and how to recover. A rollout built on cherry-picked wins collapses the first time someone hits a real one.
Capture the wins as skills immediately
When someone gets a genuinely good result, that result is perishable. It lives in a terminal buffer and disappears.
Capture it the same day as a skill, in a shared repo, installed by everyone. That is the mechanism by which a rollout compounds instead of plateauing: the best result any one person got becomes the baseline everybody starts from.
Without it you get four people who are individually good and no collective improvement.
Answer the security question before it is asked
Someone will ask what the tool sends where, and if the answer is a shrug the rollout stops in legal.
Have it ready: where the code goes, what is retained, how it authenticates, how access is revoked when someone leaves, what is logged. If you run in a regulated environment, know your deployment options - the model can run through your own cloud account rather than a vendor endpoint, and that single fact resolves most objections before they escalate.
Getting ahead of this is cheap. Reacting to it after a security review has already flagged it is not.
Measure the right thing
Not licences activated. Not lines of code accepted, which rewards accepting slop.
The useful signals are: how many people used it this week without being reminded, whether cycle time on well-defined tickets moved, and whether the number of “how do I get it to…” questions is falling. Falling questions means the shared context is working. Flat questions six weeks in means everyone is still solving the same problem alone.
What to expect
Weeks one to two, the enthusiasts. Three to four, the pragmatists, if and only if you have run a working session and written the context file. Beyond that, the sceptics, who convert when a colleague they respect solves something in front of them that they know was hard.
The sceptics are not a problem to be managed. They are the people who will find the real limitations, and you want those found early by someone careful rather than late by someone shipping to production.
What to read next
- Claude Code skills and plugins - how to capture the wins so they compound.
- Enterprise deployment - SSO, SCIM, and the security review.
- Auth for agents - the identity model underneath.