Claude Code Team Rollout: 30/60/90-Day Plan 2026

A Claude Code team rollout is a quarter of disciplined work, not an afternoon of installs. The 30/60/90-day plan below is the cadence we run for client engineering teams — three sprints, fifteen milestones, eight reusable templates, and a quarterly review that keeps the gains from drifting back to install-only. The plan assumes seats are bought and access is provisioned on day zero; everything in the calendar after that is about turning a per-engineer tool into a team capability.

The shape of the plan is deliberate. Days 1-30 land the base layer — settings, permissions, the first skills, the first hooks, a tight starting CLAUDE.md. Days 31-60 build leverage — a shared skill library, hook templates the team actually uses, a productivity-signal panel that makes engagement visible. Days 61-90 wire governance — subagent design, security review, documented quarterly cadence. By day 90 the team has the artefacts and the rhythm to stay there.

This guide walks through each phase as a list of milestones with named owners and concrete deliverables, the RACI for who does what, the templates the rollout depends on, and the four most common reasons rollouts stall before they reach day 90. The companion piece is the 50-point adoption scorecard — run it on day 0 to set the baseline and on day 90 to measure progress.

Engineering tool rollouts have a characteristic curve. The first week looks great — installs land, sessions open, eng-leadership sees activity and reports success up the chain. Week three is quieter. By week six the dashboard still shows licence usage but the artefacts that would indicate real adoption — shared skills, wired hooks, pruned CLAUDE.md files, subagents — are still absent. By month six the project has been declared a success on paper and the actual capability of the team has barely shifted.

Ninety days is the horizon that defeats that pattern, for three reasons. First, it is long enough that the easy wins (install, settings, first skill) have time to compound into the harder wins (shared library, hook habit, security review). Second, it is short enough that the urgency stays in the calendar — a year-long rollout drifts because every milestone is far away. Third, it maps cleanly to a quarter, which is how engineering organisations already plan, budget, and review.

The three sprints inside the quarter each have a different character. The first sprint is install and configuration — concrete, mechanical, mostly individual work. The second sprint is leverage and habit — collaborative, more ambiguous, where the team has to invest time in artefacts whose payoff is two or three weeks away. The third sprint is governance and durability — security review, subagent design, documented cadence. The skill of running the rollout is matching effort and attention to the shape of each sprint rather than treating all three as one continuous installation project.

One nuance worth surfacing early. The plan below assumes a team of roughly ten to fifty engineers on a shared stack. Smaller teams (one to five) can compress the calendar to forty-five days because coordination overhead drops. Larger teams (a hundred plus) usually need to run the plan per-squad in parallel rather than centrally, because per-team variance in stack and workflow tends to be the dominant signal at scale. The shape of the plan is the same in every case; the cadence adjusts.

The first sprint is concrete. Every milestone has a binary done/not-done state, every artefact lives in a known location, and every engineer can complete their portion inside a normal working day. The intent is to land the base layer cleanly so that the leverage work in sprint two has a foundation to sit on. Cutting corners in sprint one is the single most reliable way to stall sprint two — the team ends up rebuilding configuration mid-rollout, which is expensive and demoralising.

Five milestones, ordered by dependency. Each has a default owner; the RACI matrix in Section 05 names the broader responsibility set.

The single most-skipped milestone in sprint one is the audit baseline. Teams move into the leverage sprint without a snapshot of where they started, which means the productivity signals shipped in sprint two have no reference point and the day-90 review has no quantitative story to tell. Spend the half-day on day 29 to run the scorecard. It compounds every subsequent sprint.

The other consistent stumble is over-scoping the starter CLAUDE.md. Engineers reach for completeness — every project convention, every key file, every gotcha — and the file lands at 1,200 lines on day 12, which the model then skims rather than reads. The 400-line cap is a discipline, not a target. Tight memory in sprint one pays back through every interaction in sprints two and three.

The second sprint is where the rollout earns its keep. The base layer from sprint one is necessary but not sufficient — what turns Claude Code into a team capability rather than a per- engineer tool is the shared library of skills, hooks, and subagents that everyone contributes to and everyone uses. This is the sprint with the highest variance across teams: the ones that invest land at Stage 3 Leveraged on the day-60 audit, the ones that coast stay at Stage 2 Configured.

Five milestones, weighted toward leverage and measurement. The tone shifts from individual work to team work — pairs and small groups owning artefacts rather than individuals owning milestones in isolation.

The leverage sprint introduces a role that did not exist in sprint one — the skill captain. One or two engineers who take ownership of the skill library: ensuring scoping discipline (one job per skill), documentation quality, and invocation reporting. The captains are not necessarily the most senior engineers; in the audited cohort, they are most often mid-level developers who have personally fallen in love with the tool and want to spread that experience to the team. Surfacing and supporting those people is the highest-leverage move a rollout lead makes in sprint two.

The productivity-signal panel is the artefact most often built badly. Teams reach for vanity metrics — total tokens spent, total sessions opened — that licence telemetry already covers. The panel is useful precisely when it tracks the metrics licence telemetry cannot see: subagent invocations, skill use, time-to-value. The companion piece on the 50-point adoption scorecard covers the panel design in detail.

The third sprint is governance — the unglamorous but essential work that turns a productive rollout into a durable one. Subagent design discipline, security policy that has caught up with the new tool surface, the documented cadence that keeps the artefacts current after day 90. Teams that skip sprint three usually find themselves redoing it in an unscheduled emergency one or two quarters later — typically triggered by an incident rather than a calendar.

Five milestones, weighted toward review and durability. The character is different again from sprints one and two — more cross-functional, with security and platform engineering usually contributing more than they did in earlier sprints.

Subagent design is the milestone teams either embrace or ignore in sprint three. The ones that embrace it land at Stage 4 Optimised on the day-90 audit — under ten percent of audited teams reach that stage in 2026, and they almost all get there through scoped, well-documented subagents that act as durable team capabilities rather than ad-hoc agentic runs. The walkthrough on building a Claude Code custom subagent is the operational layer underneath this milestone.

Security review is the milestone teams most often under-resource. It looks like a checklist exercise — confirm permissions, scan for secrets, check the MCP registry — but done well it is also an opportunity to catch the drift that has accumulated through sprints one and two as the surface expanded. The pattern that has held across the client base: block a half-day with the security partner on day 75, walk through the artefacts together, sign off in writing. Compress it to an hour and the sign-off is theatre.

The plan only works with named owners. Implicit ownership in tool rollouts collapses to no ownership inside a fortnight — every engineer assumes someone else is driving the next milestone, and the calendar slips. The RACI below is the allocation we use as the default; adjust for team shape but keep the principle that every milestone has a single named R (responsible) and a single named A (accountable).

Four roles cover the plan. The rollout lead is the single accountable owner — typically a tech lead or an EM-grade engineer with the time to drive the calendar. The tech lead owns the per-repo artefacts — CLAUDE.md, settings.json, sub-doc structure. Skill captains own the library — one or two engineers per team. The security partner is named in sprint one but most active in sprint three. The platform / devops function supports hooks and MCP work across all three sprints.

One pattern worth calling out: the rollout lead role is the most often under-allocated. Teams treat it as a 5% nice-to- have on someone's plate and the calendar slips inside three weeks. Twenty to thirty percent of one engineer's week for the quarter is the realistic allocation. Less than that and the rollout becomes a part-time project with a full-time drift problem.

The skill-captain role is the most often missing. Teams assume skills will emerge organically from a culture of sharing, and on rare engagements they do. The default assumption should be the opposite — name one or two captains explicitly in sprint two, give them the air-cover to write skills on company time, and the library compounds from there.

Eight templates form the reusable backbone of the rollout. They are the artefacts a new team can clone from a previous engagement rather than re-deriving from scratch. The starter kit is approximate — every team adapts — but having a starting point is the difference between a sprint one that ships base-layer artefacts and one that spends three weeks discussing what shape they should take.

The directory layout below is a sketch of what the repo looks like by day 30. Skills, hooks, and the productivity dashboard config all sit under .claude/ with the exception of the dashboard renderer, which usually lives in a separate platform repo.

The directory layout that crystallises across the audited cohort looks like the snippet below. It is not a standard — Claude Code itself does not require a particular structure under .claude/ — but the convention makes audits faster and onboarding cleaner.

Eight templates is the minimum. The reusable assets that tend to accumulate over the second and third sprint — additional skills, hook variants, dashboard refinements — are usually team-specific and not worth templating until a pattern is observed across two or three engagements. The starter kit covers the day-30 milestones; sprint two and three additions stay in-team.

Across the 2026 rollout cohort, four failure modes account for almost every stalled rollout. They are visible in sprint one or sprint two; spotted early, each has a cheap remediation. Left to develop, each turns the day-90 review into an explanation of why the rollout did not land rather than a celebration of the new capability.

The first pitfall — no named rollout lead — is the easiest to fix and the most-often unfixed. Name a single person on day zero. The other three pitfalls follow from sprint-one and sprint-two execution. Skill captains emerge if the rollout lead names them; CLAUDE.md stays tight if the tech lead enforces the 400-line cap in PR; security review lands on time if it is calendared on day one rather than negotiated on day seventy.

One pattern across the audited cohort: rollouts with zero pitfalls are rare. The realistic goal is to hit zero or one pitfall by day 60 and use sprint three to remediate anything that emerged in sprints one and two. Teams that carry two or more pitfalls into sprint three almost always finish at Stage 2 Configured rather than Stage 3 Leveraged — recoverable in the next quarter, but only with explicit follow-up work.