Thirty days. Here's what actually happens.
By the end of this lesson, you'll have walked through the full activation arc: from pre-kickoff discovery to the Day 30 showcase, the weekly rhythm that holds it together, and what a clean handoff looks like in practice.
Five phases. Each one has a clear job and a clear exit condition.
The activation arc is not a project plan with tasks. It is a rhythm with phase gates. Knowing when to exit each phase is as important as knowing what to do in it.
Two recurring touchpoints. Both on the calendar before Day 1.
The weekly rhythm is what separates an activation from a deployment. Deployments happen once and drift. Activations have a structured weekly cadence that holds the adoption curve in place.
CoE touchpoint (30 minutes, consultant-led). Runs on Day 8 and Day 15. Agenda is consistent: review usage data from the previous week, identify any developers stuck in supervised mode, agree on one concrete coaching action per stalled developer, and check the CLAUDE.md for needed updates. This meeting is with the champion candidate or engineering lead, not the full cohort. Keep it tight. The decision coming out of this meeting should be a specific intervention or a green light to proceed.
Office hours (60 minutes, open attendance). Developer Q&A format. No fixed agenda. Developers bring real tasks, real friction, and real code. The first session is consultant-led. The champion candidate co-facilitates from session two onward. By session three, the champion runs it and the consultant observes. This is the primary handoff mechanism: not a conversation about owning office hours, but doing it while still supported.
Both touchpoints should be calendar items with video links created before the kickoff meeting. Scheduling them after kickoff introduces friction and signals that the structure is not fixed. Treat them as immovable until the Day 30 showcase is complete.
Three parts. Thirty minutes. Sponsor in the room.
The Day 30 showcase is not a project update. It is a business case presentation with a live demo. Structure it accordingly.
Part one: Live demo (10 minutes). Two or three cohort developers show Claude Code on a real task from the pilot. Not a prepared script. Not a polished recording. Real code, real friction, real workflow. The rawness is the point: it shows the sponsor what a developer's day looks like six weeks after deployment. Pick developers who are at Stage 3 or 4 on the adoption curve. Stage 1 developers demo supervised mode interactions, which undersell the capability.
Part two: Metrics readout (10 minutes). Lead with the headline number: "PR cycle time dropped 36% for the migration cohort over 30 days." Present the supporting data: adoption metrics, GitHub contribution metrics, developer sentiment. Frame every metric against the success criteria that were agreed before the pilot started. If the criteria weren't met, name them and explain why before the sponsor asks.
Part three: Renewal conversation (10 minutes). What phase two looks like: broader cohort, additional use cases, or deeper integration. Who the champion is and what their role entails. The 90-day health check. A specific next step. The sponsor should leave the room with a decision to make, not a follow-up to schedule.
This lesson walked you through every phase of a Claude Code activation. Use this as your working reference for the next engagement: five phases, two recurring touchpoints, and the exit conditions that tell you when to move.
You've covered the full arc of a Claude Code activation — from qualifying the use case to equipping the champion for handoff. To put it to work: take a sample client brief and run it through each stage. Qualify the use case, sketch a pilot design, define the ROI scorecard with real baselines, and draft a champion plan with a named candidate. If you can hand that document to a client's CIO and engineering lead and have both nod, the engagement is ready to start.