Case Study: Claude Code Adoption at a 30-Dev Shop

Claude Code adoption at a thirty-engineer product shop is the kind of rollout that either compounds or quietly stalls, and the difference is rarely about the tool. This case study walks through one engagement that landed cleanly — install on day zero, twenty-two shared skills by day ninety, a productivity panel the team built rather than inherited, and a 35% productivity lift that held into month four because weekly retros caught the friction before it became attrition.

The team in question is a Series-B SaaS product organisation, a single shared monorepo, mostly Node and TypeScript with a sliver of Go. Thirty engineers across six squads, a tech lead per squad, one staff engineer carrying the rollout, and a head of engineering who agreed to the cadence but did not drive it. The engagement spanned the calendar quarter that ended in late April 2026, with the post-90 review running at month four in mid-May.

What follows is the play-by-play. Situation, approach, skill kit design, hooks and memory discipline, the productivity panel, the outcomes that landed, and the lessons that generalise. The companion piece is the 30/60/90-day rollout plan — this case study is what happens when that plan meets a real engineering organisation with real constraints.

The team had Claude Code seats for the better part of a year before this engagement started. Adoption was real but shallow — roughly half the engineers used the CLI weekly, mostly for individual workflows, with no shared skills, no committed settings, and no hooks. The CLAUDE.md files that existed had been written once and never revised; two of the six squads had no project memory at all. Licence telemetry looked healthy, which had let leadership believe the tool was landing. The day-zero audit told a different story.

That gap — between licence telemetry and actual capability — is the single most common situation we walk into. The pattern is unambiguous: a team installs Claude Code, individual engineers find it useful, leadership reports the rollout as a success on paper, and the artefacts that would indicate real team adoption never accumulate. The first conversation in this engagement was re-framing the problem from "are we using Claude Code" to "what does our team know how to do with Claude Code that it could not do six months ago" — and the honest answer in March 2026 was very little.

Three constraints shaped the engagement. The team could not pause product work to focus on the rollout — every milestone had to be absorbed into the normal sprint cadence. The staff engineer running the rollout had roughly 30% of their week, no more. And the head of engineering wanted a quantitative story by day ninety that would justify the time spent. The 30/60/90-day plan was adapted to those constraints rather than imposed on them.

The baseline 50-point audit on day zero scored a 19 out of 50. Install and licence (full marks), individual settings (partial), zero project-scope settings, three CLAUDE.md files of wildly varying quality, no committed skills, no hooks, no subagents. The team described that score as deflating on the day; by the day-30 retro it had become the most-cited artefact of the engagement, because it gave the rollout a quantitative spine that licence telemetry could not.

The rollout was structured as three ninety-day sprints plus a sustain phase that started at day 90 and continued through the month-four review. Each sprint had a distinct character — install, leverage, governance — and the sustain phase carried forward the weekly retro and quarterly audit cadence. The four phases below are how the team referred to the work internally; the underlying plan is the 30/60/90 cadence with the post-90 sustain phase made explicit.

One named owner per phase. The staff engineer carried accountability across all four; the per-phase owners were the engineers most invested in the work for that sprint. Friday retros — thirty minutes per squad — caught the per-week friction. The cross-squad retro on the last Friday of each sprint surfaced the patterns worth lifting into the next phase.

The choice to make sprint four explicit rather than implicit was the biggest deviation from the textbook 30/60/90 plan. Earlier engagements had treated days 91 onward as a fall-back-to-normal phase with a vague quarterly review; this engagement put the sustain phase on the same calendar as the active sprints, with the same owner and the same cadence, and the difference in month-four metrics was substantial. Adoption that holds is a property of the cadence the team commits to, not the install they completed.

Friday retros earned their place in week three. Two squads had been hitting the same permissions friction — the project settings allowlist was missing a tool that a recurring task needed, and engineers were silently working around it by invoking with broader permissions in personal sessions. The retro surfaced it in week three; the fix landed on the Monday; the working-around stopped that week. Without the retro the pattern would have stayed in the dark for the rest of the sprint, and the productivity panel would have shown a slowly widening gap between licence usage and skill invocations with no obvious cause.

The skill library is the single artefact whose presence most reliably predicted productivity gains in this engagement and across the broader 2026 cohort. Twenty-two skills landed by day 90 with authorship spread across nine engineers — meaning the library was not a single-author project that decays if one engineer leaves. The captains in each squad enforced two disciplines: one job per skill, and documentation written before the skill is merged.

The skills clustered into four categories. Workflow skills wrapped recurring multi-step tasks (commit, code-review, scaffold-route, scaffold-component, run-migration). Quality skills enforced standards (lint-fix, test-gen, dep-audit). Knowledge skills surfaced team conventions (explain-this-pattern, find-owner, history-of-this-file). Operational skills moved artefacts between systems (release-notes, changelog-update, deploy-staging). The breakdown is illustrative rather than prescriptive — every team's mix is different — but the principle of distinct categories with explicit naming helped discovery once the library passed roughly ten entries.

One skill in the workflow category — commit — accounted for roughly a third of all invocations by month four. That kind of skewed distribution is normal in mature libraries and not a sign of poor design; it tells the captains where to invest in iteration, and it tells leadership which workflow is actually being changed by the rollout. The companion piece on the 50-point adoption scorecard covers the scoring rubric for library breadth, depth, and invocation distribution.

The discipline that earned its place was the one-job-per-skill rule. Two skills in week six bloated into multi-step workflows that overlapped — a ship-feature skill that overlapped with commit, code-review, and deploy-staging. The captain in that squad decomposed it back into three smaller skills in week seven, and invocation counts rose afterwards because the smaller skills were easier to remember and reach for. Big skills look efficient on paper; small composable skills win in practice.

Hook design was the sprint-two milestone with the widest variance across squads. Three squads embraced hooks enthusiastically and shipped four each; two squads shipped one or two; one squad shipped none until sprint three. The squads that engaged tended to be the ones where the tech lead personally wrote the first hook in sprint one — once that existence proof landed, the rest of the squad found patterns to wrap. Where the tech lead waited for someone else to write the first hook, the wait usually outlasted the sprint.

The eleven hooks broke down across three archetypes. Five notification hooks (Slack pings on long-running tasks completing, audit summaries to the on-call channel). Four audit-log hooks (write-to-disk records of bash invocations, file writes outside the repo, MCP server tool calls). Two gate hooks (PreToolUse hooks that vetoed bash commands matching destructive patterns, and write operations to specific protected paths). The gate hooks were the most interesting in retrospect — they emerged in week six from a near-miss where an engineer almost shipped a destructive migration through Claude Code. The hook turned the near-miss into a documented policy in the same sprint.

The CLAUDE.md hygiene rule had a measurable effect on engagement depth. The two squads that drifted past 800 lines in sprint two had visibly lower skill-invocation rates than the four that stayed under 400 — the panel showed a roughly 40% gap by the end of sprint two. The hypothesised mechanism, validated in two follow-up retros: bloated memory caused the model to skim the file rather than internalise it, which produced more generic responses, which made engineers reach for the tool less often, which lowered invocation rates further. The cycle is self-reinforcing in either direction.

The prune at month four cut the average CLAUDE.md line count from 520 to 340. Three sub-docs were created during the prune in the typical squad — usually one for stack details, one for conventions, one for a runbook reference — and the corresponding sections in the main file collapsed to one-line summaries with links. The prune itself took roughly an hour per squad. The productivity-panel response in the two weeks after the prune was a 12% lift in skill-invocation rate across the team, consistent with the hypothesis.

The first version of the productivity panel was wrong, and that mistake taught the rollout more than any single milestone after it. Version one tracked the vanity metrics that licence telemetry already covered — total sessions opened per week, total tokens spent, average session length. The panel read flat for six weeks even as the underlying capability of the team was visibly shifting in retros and PRs. The signals it tracked were uncorrelated with adoption depth, and so it could not see the rollout that was happening.

Version two, rebuilt in week eight, weighted around engagement signals — skill invocations split by skill, subagent runs per week, time-to-first-meaningful-output for new contributors, audit-score deltas from the quarterly scorecard, and one team-specific signal (PR-to-merge time on Claude-Code-assisted PRs versus baseline). The pattern of shipped artefacts and retro reports suddenly tracked the panel rather than diverging from it. The shape below is what the panel looked like by month four, with the relative weight each signal carried in the engagement composite.

The headline productivity number quoted to leadership and the board — a 35% productivity lift sustained at month four — was an engagement-weighted composite of the five signals above, not a single measurement. The composite is defensible because each component signal correlates with adoption depth in a different way: skill invocations measure breadth of tool use, subagent runs measure depth, time-to-first-meaningful-output measures onboarding effect, PR-to-merge time measures workflow impact, and audit-score delta measures the structural artefacts that make the others sustainable.

The 35% number was deliberately not framed as "engineers ship 35% more code." That framing invites scepticism because it is not what the panel measures, and it is not how the productivity lift actually compounds. The honest framing — used in the month-four memo to leadership — is that the team's measured engagement with Claude Code increased 35% from the panel-v2 baseline, and that this engagement increase corresponds to the shipped artefacts (the 22 skills, 11 hooks, 3 subagents), the audit-score delta, and the retro-reported satisfaction shift. That triangulation is what made the number stick rather than be debated.

The outcomes that landed by day 90 fell into three buckets. Artefacts that the team built and now maintains. Metrics that quantify the capability shift. And cultural shifts that do not appear in either category but were the most-cited in the day-90 retro and the month-four review. All three held into month four with no measurable decay; the quarterly review cadence is what kept them in place.

The audit-score progression is the cleanest quantitative signal. The day-zero baseline of 19 out of 50 moved to 41 by day 90 — a 22-point shift, taking the team from late Stage 1 / early Stage 2 to mid-Stage 3 Leveraged on the scorecard rubric. Roughly ten percent of audited teams reach Stage 4 Optimised in their first quarter; this team did not, and the day-90 retro explicitly named the next quarter as a push from Stage 3 to Stage 4 through deeper subagent governance and a security cadence that catches drift before it accumulates.

One outcome worth singling out is the new-hire effect. Three engineers joined the team during the engagement; the third was hired in late sprint two and onboarded entirely against the new artefact layer. Their week-two time-to-first-meaningful-output was 45% faster than the baseline established by the previous five new hires under the old onboarding pattern. The skills they used most in the first fortnight — find-owner, explain-this-pattern, history-of-this-file — were specifically the knowledge-category skills that emerged from sprint-two retros as the artefacts most likely to compound the team's institutional knowledge into the onboarding flow.

The month-four hold is the harder result to attribute. By month four, plenty of three-month rollouts in the broader cohort have started to drift — skill libraries stagnate, CLAUDE.md files bloat again, hook noise rises. This team's month-four numbers were essentially flat against day-90 with a small upward shift on PR-to-merge time, which the team attributed to the new-hire effect compounding. The difference between holding and drifting was almost entirely the Friday retro cadence — the artefacts stayed live because the team kept talking about them.

The five lessons below generalise — they have shown up across several engagements in the 2026 cohort, not just this one. The team-specific details (the particular skills, the squad shapes, the monorepo structure) do not, and any other team replicating this case study should expect their library and hook mix to look meaningfully different. The cadence and the shape of the artefacts replicate; the contents adapt.

One non-obvious lesson: the staff engineer carrying the rollout was the right shape of role, but it could have been done by any senior IC or EM-grade engineer with the same time allocation. The role shape that matters is not the title but the combination of three things — enough seniority to enforce milestone discipline across squads, enough engineering depth to actually write skills and hooks rather than just steward them, and enough calendar discipline to keep the cadence intact when product work pushes back. Title is a proxy for these, not a substitute.

For teams replicating this case study, the operational order matters. Run the day-zero audit before naming the rollout lead — the audit is what makes the case for the engagement internally, and the lead role is easier to fill once the score is visible. Name the skill captains in sprint two, not sprint one — they emerge from the work rather than being appointed. Build the productivity panel deliberately badly in sprint two and rebuild it in sprint three; the version-two rebuild is structural rather than incremental, and trying to ship the right panel on the first try usually delays the cadence rather than improving the signals.

The companion 50-point adoption scorecard is the right starting artefact for any team considering this replication. Run it on day zero, treat the score as the baseline, and re-run quarterly. The structural shape of the scorecard maps cleanly onto the four-phase plan above and gives leadership a defensible quantitative spine for the rollout that licence telemetry cannot provide. Our AI transformation engagements run this exact pattern with client engineering teams — the phasing, the audit, the panel, the cadence.