Appendix E: 30/60/90 Day Adoption Roadmap

Two tracks: one for an individual engineer, one for a team of ten to fifty. Each phase ends with a gate, a short test of whether to move on.

Individual track

Days 1 to 7: Foundations

• Install, configure permissions, finish the first-day checklist (Chapter 2)
• Write and refine CLAUDE.md for your main repository (Chapter 4)
• Use plan mode on every non-trivial task
• Practice rewind instead of correction (Chapter 3)

Gate: you can complete a small feature using spec, plan, implement, verify without retyping project context.

Days 8 to 30: Habits

• Create three skills from your most repeated prompts (Chapter 5)
• Add a formatter hook and a test-on-stop hook (Appendix C)
• Create a code-reviewer subagent and use it on every change
• Run /security-review before every push
• Keep a plan file for any task longer than a day

Gate: most of your changes pass review without requests for basic fixes.

Days 31 to 60: Extension

• Connect your issue tracker and one other system through MCP (Chapter 7)
• Install one plugin and read all of its code first
• Run two parallel sessions with worktrees (Chapter 12)
• Script one batch task with claude -p

Gate: you can take a ticket ID to an open PR with tests in one supervised session.

Days 61 to 90: Mastery and contribution

• Package your best skills, hooks, and subagent as a team plugin
• Run the writer and reviewer pattern on a large feature
• Present one win and one failure at the team review
• Mentor one teammate through their first two weeks

Gate: something you built is in daily use by people other than you.

Team track

Weeks 1 to 4: Pilot

• Pick two or three volunteer engineers and one non-critical repository
• Record baselines: lead time, change failure rate, review time (Chapter 13)
• Agree on data handling rules with security and legal
• Pilot engineers keep a short log of what worked and what broke

Gate: pilot engineers report clear time savings and no quality regressions.

Warning signs: pilot engineers have stopped using it, or a bug traced to unreviewed AI output reached production.

Weeks 5 to 8: Structure

• Commit team CLAUDE.md, .claude/settings.json, and shared hooks to pilot repos
• Name a champion per team with protected time (Chapter 14)
• Stand up an internal plugin marketplace with the first shared skills
• Add the security review Action and CODEOWNERS for high-risk paths
• Start the weekly fifteen-minute review

Gate: a new engineer can set up and complete a task using only the team's shared configuration.

Warning signs: each engineer maintains a private setup; shared skills go unused.

Weeks 9 to 12: Rollout and governance

• Expand to all teams, champions first
• Enforce organization-wide managed settings: deny rules, approved MCP servers
• Publish the engineering policy: ownership, mandatory review paths, data rules
• Add Claude Code to onboarding (the five-day plan in Chapter 14)
• Compare metrics against the baseline and share results openly

Gate: lead time improves and change failure rate holds steady or improves.

Warning signs: lead time improves while change failure rate rises. Thicken the verification stack before expanding further.

Metrics dashboard

Metric	Source	Direction you want
Lead time, commit to production	Deploy pipeline	Down
Change failure rate	Incident tracker	Flat or down
Escaped defects per release	Bug tracker	Flat or down
Security findings, High and Critical	Scanners and reviews	Down
Median PR review time	Git host	Down
PR size, lines changed	Git host	Flat or down
Engineer-reported toil hours	Quarterly survey	Down