Rollout that works: one workflow, one team, one measurable outcome

The pack from Lessons 12.1 and 12.2 exists. It is committed, claude plugin validate passes, and it works on your machine. Nine people now have to start using it, and none of the mechanics you just learned decide whether they do.

What decides it is duller: how much you changed at once, whether anyone can tell afterwards that it helped, and whether the thing you shipped had a way to fail loudly. The docs give you enforcement mechanisms, measurement surfaces, and the pilot-then-baseline sequence for exactly one question — what it will cost. The rest of the sequencing here is this course's, resting on documented behaviour that is quoted where it carries weight.

Pick one workflow, not a platform

The failure mode is announcing "we're adopting Claude Code". That is a platform rollout: everyone, everywhere, with no before-state and nothing that could be judged to have worked. Nobody can disagree with it, which is the tell.

"One workflow" is load-bearing. A workflow is open a bug-fix PR, or write and run the migration, or triage the failing nightly: it has a beginning, an end, and a person who currently does it and can tell you what is annoying about it. That person is the pilot. The reason to be this narrow is not caution — a narrow rollout has a control group by construction, the other workflows and the other teams, and a platform rollout does not.

Advisory, invocable, or deterministic

Every convention in the pack has to be delivered at some enforcement level, and the levels are different things, not degrees of one thing.

The line between the first and third is documented, not stylistic:

Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens. — Best practices

The middle row is the one teams skip. Skills carry knowledge specific to your project, team or domain; Claude applies them automatically when relevant, or you invoke them directly with /skill-name (Best practices). That is the right home for most of a conventions pack, and the cost column is why: CLAUDE.md is loaded every session, while Claude loads skills on demand "without bloating every conversation" (Best practices).

On demand is not free, though, and the difference decides how a nine-convention pack lands. In a regular session skill descriptions are loaded into context so Claude knows what is available; only the full content waits for invocation (Skills). Nine skills means nine descriptions in every session whether anybody uses them or not, and once a skill does load, its content stays in context across turns — "every line is a recurring token cost" (Skills).

Lesson 6.2 argued about what belongs in CLAUDE.md, Lesson 7.1 covers skills, Lesson 9.1 covers picking a hook event. What is new here is the routing decision, and it has one honest test: does this rule have to hold every time, or does it need to be right most of the time? Only the first kind earns a hook.

The pressure runs the other way too. When the shared instruction file grows, the documented fix is to prune ruthlessly, and to delete an instruction Claude already follows correctly or convert it to a hook (Best practices). Both halves matter: a rule that must hold gets promoted out of prose rather than shouted in it. Lesson 6.6 has the evidence that a long file makes results worse.

Give the workflow a check it can run

If the workflow you picked has no check, you are about to distribute the Level 5 problem to nine people at once:

Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it. — Best practices

At team scale "you" becomes whoever reviews the PR — a worse place for the loop to live than your own session, because the reviewer never watched the work happen. Lesson 5.1 made this case for one person; the rollout version is stricter. A workflow with no runnable check is not ready to be distributed, because you are multiplying the number of people who cannot tell a good run from a plausible one. The same page names the deliverable: have Claude show evidence rather than asserting success — the test output, the command it ran and what it returned, or a screenshot (Best practices). Write that into the workflow's skill, not into a rollout email. The email is read once.

Baseline before you change anything

The rule is trivial to state and almost always violated: the measurement must exist before the change does. The docs give the ordering for one question outright — to estimate spend, "start with a small pilot group and use the tracking tools below to establish a baseline before wider rollout" (Manage costs). That is written about money, but the shape is the argument: a pilot, then a baseline, then widening. Two further documented facts make the ordering non-negotiable rather than merely tidy for everything else you want to claim.

First, switching the measurement on has latency of its own. For the contribution metrics that connect Claude Code to merged PRs, "Data typically appears within 24 hours after enabling, with daily updates" (Analytics) — a lag that is nothing across a four-week pilot and fatal on the morning you decide to check.

Second, the dashboard is not meant to be the whole answer. The docs say to read these numbers alongside the engineering KPIs your team already trusted before Claude Code existed — cycle time, escaped defects — which means the baseline you take now is a baseline of that number too, not only of the Claude Code one. Lesson 12.4 owns that argument and the sentence it rests on; read it on what these figures do and do not count before quoting one at anybody.

Piloting with a group, and where the tooling will not help

Here is the trap, and it is specific. The obvious way to give one squad a different configuration is the admin console. It does not work that way:

Server-managed settings from the admin console apply to every user in your organization, so they can't carry a per-group assignment. — Plugin marketplaces

The limitations page states it as a present-tense gap, not an architecture: server-managed settings "apply uniformly to all users in the organization. Per-group configurations are not yet supported" (Server-managed settings). Re-check that before your next rollout; plan this one as though it still holds. Push the pilot through that path today and it stops being a pilot — a fleet change with no control group, delivered to people who were never briefed, and the comparison the exercise existed to produce is gone before it starts.

Per-group targeting is documented, just not there. In the release-channel setup the docs name two ways to give each user group its own marketplace through managed settings: deploy separate endpoint-managed settings, such as a managed settings file or an MDM profile, to each group's devices; or define one Claude apps gateway policy per group, since the gateway applies the first policy whose match rule fits a user (Plugin marketplaces). Both are plumbing somebody owns, and both have a documented way to misfire: on a device that also carries an organization-wide source, precedence within the managed tier decides whether the per-group file wins, and a group policy's extraKnownMarketplaces replaces the catch-all policy's map instead of merging with it, so the group policy must list every marketplace that group needs (Plugin marketplaces).

For most teams the first row is the answer. A shared project settings file applies to "everyone working in the folder that contains it", and in a git repository you commit it so teammates get it (Settings) — so if the pilot team owns a repository, the repository is the cohort. It is not free, though, and Lesson 12.1 is the reason: some of what you commit waits until each teammate trusts the folder, and a few keys never take effect from a repository file at all (Settings). Budget a day of week one for finding out which of yours did.

If the pilot is a plugin rather than a settings change, a staged release means two marketplaces pointing at different refs of the same repository — with one constraint that quietly breaks it:

Each channel must resolve to a different version. If you use explicit versions, plugin.json must declare a different version at each pinned ref. If you omit version, the distinct commit SHAs already distinguish the channels. If two refs resolve to the same version string, Claude Code treats them as identical and skips the update. — Plugin marketplaces

Read the third sentence before you invent a version-bump ritual: on a git source, leaving version out lets the distinct commit SHAs distinguish the channels for you. Declare one at each ref and forget to bump it, and the two channels are one channel wearing two names — the pilot group silently receives nothing.

Onboarding the rest of the team

Widening is mostly two things: proving the configuration actually loaded on other people's machines, and not writing first-day material that already exists.

After configuring managed settings, have a developer run /status inside Claude Code. On the Status tab, the Setting sources line shows Enterprise managed settings followed by the source that won in parentheses. — Set up Claude Code for your organization

Read the subject of that sentence. Not you, on the machine where you built the thing — a developer, on a machine that received it. Your machine is the one that cannot tell you anything, because everything on it is there for reasons you put there. Lesson 12.5 covers reading that line when a policy is missing, overridden, or never arrived at all.

The same line serves a repository pilot, and it is weaker than it looks. It answers did my file arrive, not is my value the one in force — Lesson 12.1 has that caveat and the claude doctor check that goes beside it.

For first-day material, the docs hand you resources to share: Quickstart, a "first-session walkthrough from install to working with a project"; Common workflows, for everyday patterns like code review, refactoring and debugging; and two self-paced Anthropic Academy courses, Claude 101 and Claude Code in Action (Set up Claude Code for your organization). Write the part nobody else can — your repository, your workflow, your check — and link out for the rest. The dashboard has one documented use here that is not about proving value: the Leaderboard helps you find team members with high Claude Code adoption who can share prompting techniques and workflows and help onboard new users (Analytics). As a target it is the trap in Lesson 12.4; as a directory of people to ask, it is fine.

Reading the first two weeks without lying to yourself

Decide in writing, before the pilot starts, what result would make you stop. A rollout with no failure condition is not an experiment; it is an announcement with a review meeting attached.

Workflow:  opening a bug-fix PR in payments-api
Team:      the four people who own that repo
Baseline:  median PR cycle time over the last 6 sprints — already in our
           dashboard, recorded 2026-09-09, before anything changed
Claim:     after 4 weeks, median cycle time for bug-fix PRs is lower and
           escaped defects have not risen
Falsified if: cycle time is flat or worse, OR reviewers report more rework,
           OR two of the four stop using the workflow unprompted

That last line is the one people leave out, and Level 5 was practice for it: insisting on a signal that is allowed to come back negative. A claim that cannot be falsified is not a finding about your team; it is a sentence about your enthusiasm.

Watch usage as a friction detector rather than a scoreboard. Of the three things the docs tell you to track on the Adoption chart, one points downward — "Dips in usage that may indicate friction or issues" (Analytics) — and note the hedge in may. A dip is a question, not a verdict. Someone hit a hook that blocks work they needed to do, or the skill fires on the wrong phrasing, or the check takes four minutes. All three are fixable and none of them show up in a number that only goes up. Go and ask.

The honest report at week four has three parts and they are separate claims: what moved in the pre-existing KPI, what the Claude Code numbers show with their caveats attached, and what the four people say. Give all three, and if they disagree say so — that disagreement is the finding. A rollout report containing only good news is the same failure as a session that only reports success.