Claude Code Rollout Plan: A 90-Day Playbook for Eng Teams

A Claude Code rollout goes better when it's run like any other engineering change: set the guardrails first, pilot with a small group, check what actually changed, then expand. This playbook lays out a 90-day plan for engineering teams, with an assessment checkpoint at day 60 so the decision to expand rests on evidence rather than enthusiasm. The phases are our recommendation; the technical details come from Anthropic's Claude Code documentation.

The 90-day Claude Code rollout plan at a glance

Want the full plan with worksheets? Download the free 90-day rollout playbook (PDF), or talk to us about running the pilot.

Why the plan has an assessment checkpoint

Two findings make a checkpoint worth the effort. Google's 2025 DORA report, based on nearly 5,000 technology professionals, found that AI adoption has a positive relationship with delivery throughput but still a negative relationship with delivery stability. Its summary is that AI "doesn't fix a team; it amplifies what's already there."

And people's own sense of the gain is unreliable. In METR's 2025 study of 16 experienced open-source developers, tasks took 19% longer with AI tools, yet the developers believed afterwards that AI had sped them up by 20%. METR is clear that this doesn't mean AI slows most developers down. It does mean you shouldn't decide a company-wide rollout on how the pilot felt.

Days 0–14: how to prepare the rollout

• Write a short usage policy. Which repositories are in scope, which are off-limits, what must always be reviewed by a person, and how secrets are handled.
• Use managed settings for the rules that can't bend. Claude Code reads settings from several places, and managed settings sit at the top: they apply to everyone your organisation deploys them to, and Anthropic's docs say nothing a user sets overrides them, apart from a few security-sensitive exceptions. Shared project settings live in .claude/settings.json, checked into the repository.
• Decide permissions up front. Choose the permission mode, allowlist the commands you trust and consider sandboxing, as described in Anthropic's permissions guide.
• Turn on telemetry. Claude Code exports OpenTelemetry metrics once CLAUDE_CODE_ENABLE_TELEMETRY=1 is set, and administrators can set it for everyone through managed settings. See how to measure Claude Code impact for what to track.
• Record a baseline. Before anyone starts, capture the delivery numbers you already have: pull request cycle time, review turnaround, deployment frequency, change failure rate and rework.

Days 15–45: how to run the pilot

• Pick 10 to 20 engineers who work in live repositories, including at least one reviewer per team, rather than only the most enthusiastic volunteers.
• Agree a shared CLAUDE.md. Anthropic recommends checking it into git so the team can contribute, keeping it short, and including commands, code style that differs from defaults, testing instructions and repository conventions.
• Adopt one review standard. Use a checklist for agent-written diffs, like our Claude Code review checklist, and add it to the pull request template.
• Make non-negotiable checks deterministic. Anthropic describes hooks as deterministic, unlike CLAUDE.md instructions, which are advisory. Use them for things like running a linter after edits or blocking writes to protected folders.
• Hold a short weekly review. What worked, what went wrong, and which rules belong in CLAUDE.md, a hook or the policy.

Days 46–60: how to run the assessment checkpoint

This is the step most rollouts skip. Check two things separately:

• Skills. Can each pilot engineer scope a task, direct Claude Code through it, review the resulting diff for scope creep and new dependencies, and explain the permission boundaries? Observe this on a real task, not with a quiz. Our Claude Code certification track is built for exactly this checkpoint, with a proctored task in a live repository reviewed by a human assessor. If you'd rather not run the cohort yourself, see our Claude Code training for teams. Deciding between a kickoff workshop and an assessment? See Claude Code workshops vs assessed certification.
• Delivery. Compare the pilot's numbers with your baseline. Look at shipped changes, review time, rework and change failures, not lines of code.

Then make one of three decisions:

• Expand if skills are solid and delivery improved without worse stability.
• Adjust if gains came with more rework or incidents: tighten review, permissions or hooks, then re-run the checkpoint.
• Pause if neither skills nor delivery moved. Find out why before spending more.

Days 61–90: how to expand

• Roll out by repository and role, not by licence count. Start where review practices and tests are strongest.
• Use pilot engineers as reviewers and mentors for the next cohort.
• Move proven rules into managed settings so they apply everywhere.
• Keep the dashboards running and repeat the checkpoint for each new cohort.

Common rollout mistakes

• Buying seats and calling it adoption. Usage shows who opened the tool, not who uses it well.
• Measuring lines of code. More code is not the same as more shipped value.
• Skipping the baseline. Without one, every result is a guess.
• Letting each team invent its own rules. Shared settings, a shared CLAUDE.md and one review standard prevent drift.
• Relying on how the pilot felt. As METR found, perceived speed-ups can point the wrong way.

For the budget side of the same decision, read should companies certify their Claude Code teams and how to build the business case. To see how other teams ran their cohorts, see our case studies.

Sources: Claude Code settings; Configure permissions; Best practices for Claude Code; Monitoring usage; 2025 DORA report announcement; METR, July 2025. Checked 6 October 2026.