Phase the Rollout: Pilot, Cohort, Scale — with Kill Criteria at Every Gate

Workflow area: Org Design & Change · Tier: Core · Hands-on time: ~40 minutes

The big-bang rollout fails because it treats adoption as a licensing event instead of a behavior change. Twenty percent of engineers self-serve, thirty percent try it once and bounce off a bad first experience, and half never start — and by the time the usage report lands, the org has already concluded "AI doesn't work here." The phased rollout exists to catch problems while they are cheap: a pilot that fails quietly teaches you something; a company-wide launch that fails teaches everyone cynicism. Writing kill criteria up front is what makes the phases honest — a rollout that cannot fail is a rollout nobody believes.

When to use — and when not to

• Use it for any tool or practice touching most of the orgcoding assistants, agentic workflows, AI review norms; anything where "everyone should use this" is the goal.
• Use it when a previous rollout fizzledthe phase structure plus visible feedback loops is specifically the antidote to "we tried that and nobody used it."
• Use it when leadership pressure says "roll it out by Q3"the phases give you a credible plan to show; the gates give you a defensible pace.
• Skip the full machinery for single-team experimentsa team lead trying a tool with five volunteers needs pb-38's measurement, not a champions program.
• Don't run it as a compliance exerciseif the kill criteria are decorative and Phase 3 is preordained, engineers will detect it in about a week and treat every future rollout as theater.

The recipe

1. 1.

   Write the phase plan with gates before Phase 1 starts. One page, circulated openly:

   Copy

   ROLLOUT PLAN — [tool/practice]
   PHASE 1 — PILOT (4-6 weeks, 8-12 volunteers, 2-3 teams)
   Success: ≥60% of pilots active 3+ days/week by week 4; measured
     task-time delta positive on ≥2 workflow types; no security
     incidents; pilots would recommend (≥7/10 median).
   Kill: <30% weekly activity by week 4 despite enablement; a
     data-handling incident traced to tool defaults; time deltas
     negative across workflows after prompt/config iteration.
   PHASE 2 — COHORT (6-8 weeks, 25-40% of org, whole teams)
   Success: pilot results replicate outside the enthusiast pool;
     champions handling ≥80% of questions without escalation.
   Kill: replication failure — enthusiast results don't transfer.
   PHASE 3 — SCALE (org-wide, ongoing)
   Entry requires: Phase 2 success + usage policy published (pb-24)
     + review standards updated (pb-25) + budget model set (pb-40).
   A kill is a finding, not a failure: we write up why, fix or
   re-scope, and re-pilot. Nobody's performance is implicated.
   

2. 2.

   Pick the pilot for evidence, not enthusiasm. Two or three teams that are representative — one enthusiastic, one neutral, ideally one skeptical — across different work types (product feature work, platform, legacy maintenance). An all-enthusiast pilot produces results that will not replicate, and everyone knows it; a skeptic whose measured experience turns positive is your most credible Phase 2 asset.

3. 3.

   Name champions and give them real jobs. One champion per 8–10 engineers, volunteers with credibility, not just seniority. Their job: run office hours, collect friction into a shared log, maintain the team's prompt patterns (feeding pb-51's library), and escalate blockers weekly. Give them protected time — two to four hours a week, said out loud to their managers — because an unfunded champions program is a t-shirt, not a program.

4. 4.

   Enable in workflows, not features. Replace the generic vendor demo with 60-minute sessions built on your own code and tickets: "here's how we use it on a legacy bug in our monorepo," followed by paired practice. Record them. The difference between "training" and enablement is that enablement uses your codebase and ends with each attendee having done the workflow once.

5. 5.

   Run the feedback loop where everyone can see it. Weekly during pilot, biweekly after: a 3-question pulse (used it for what? where did it fail? what would make you use it more?) plus the champions' friction log. Then — the part most rollouts skip — publish "you said, we changed" notes: You said the assistant is useless in the data pipeline repo; we added a CLAUDE.md context file and re-tested. Feedback that visibly changes the plan generates more feedback; feedback into a void stops in two weeks.

6. 6.

   Gate each phase in a real decision meeting. At each gate, review the criteria against the data (pb-38's measurement supplies it), decide advance / extend / kill, and publish the decision with the numbers. An "extend 3 weeks to fix X" decision, honestly made, builds more trust than a hollow green light.

Make it yours

• Startup or small team: compress to two phases — a 3-week pilot with a third of the team, then everyone — but keep the written kill criteria and the "you said, we changed" notes; at 15 people, trust damage from a fake pilot travels instantly.
• Mid-size org: run cohorts by team, not by individual sign-up, so review norms and prompt patterns develop with the whole team present — a half-adopted team develops two code-review cultures.
• Large org or GCC: Phase 2 becomes a wave plan (one business unit or account cluster per wave), champions get a formal community with a monthly cross-wave call, and the gate reviews include your security and client-compliance stakeholders — in a GCC, a client-account team may need contractual clearance before entering any wave, which is a gate input, not an afterthought.

Quality check

• Kill criteria existed in writing before Phase 1 data existedcriteria written after the results are conclusions wearing a costume.
• The pilot contained at least one skeptical teamcheck the roster; an enthusiast-only pilot predicts nothing about Phase 3.
• Champions' time is realask a champion's manager what got de-prioritized to fund the hours; if the answer is "nothing," the program is unfunded.
• At least one "you said, we changed" note shipped per cyclezero notes means the feedback loop is a suggestion box.
• Gate decisions cite numbersadvance/extend/kill with data attached; a gate decided by vibes trains the org that the gates are decorative.