Most engineering organisations do not need to be convinced to use Claude Code. Their engineers already are. What they need is a rollout that turns forty private workflows into one team standard.
Left alone, Claude Code adoption produces real individual gains and no institutional capability. Prompts live in scratch files, nobody shares a skill, and each reviewer quietly invents their own position on agent-written code. The sequence below is how we move a team from there to a standard that holds.
1. Start with one team and one repository
Pick a team that already uses Claude Code and a repository that matters. A pilot on a toy project teaches nothing about your build, your tests or your review culture. A pilot on a real repository surfaces all three in the first week.
2. Write the conventions the agent reads
Claude Code reads project instructions from a CLAUDE.md file at the repository root. Put the stack, the structure, the commands to build and test, and the rules that must not be broken in it. This single file does more for consistency than any amount of individual prompting, and it is reviewed like code.
3. Turn private prompts into shared skills
The prompt one engineer spent three weeks refining for your migration pattern is worth more to the other engineers than to its author. Package the recurring ones as skills, commit them, and they survive that person changing projects.
4. Decide permissions and connections once
Agree which actions run unprompted and which always stop and ask, using permission modes. Allowlist the tools and MCP servers each repository may reach — issue tracker, staging data, CI output — rather than letting each developer connect whatever they like.
5. Enforce the standard with hooks
A convention nobody checks is a suggestion. Hooks encode the parts that matter — formatting, forbidden imports, a required test run before a commit — so the standard holds without a reviewer remembering to enforce it.
6. Agree the review bar, and plan for volume
The review bar should not drop, but what reviewers look for shifts: generated code tends to fit the file and miss the constraint that lives elsewhere. Just as important, output rises faster than review capacity. Decide deliberately how you will handle that — capping work in progress, an automated first pass, or excluding some categories of change — before the queue becomes the bottleneck.
The failure mode
Output rises, review capacity does not, and review quality quietly drops to keep pace. Plan for review throughput before you scale usage.
7. Measure, then expand
Before rolling out to the next team, check what held: which skills are actually used, whether hooks run without complaint, whether review queues are healthy, and whether a new joiner can find and follow the standard. Then repeat with the next team, reusing what worked.
How to measure Claude adoption
What Claude Code changes in an engineering team
Where Focus20 fits
Our Claude Code training is this rollout, run as a working bootcamp against your codebase: the conventions, skills, subagents, MCP connections and hooks are committed to your repository by the end, with an agreed review bar. For CTOs, we also plan the sequence across teams and the measures you will report.