Lesson 7.1
Rolling Out Claude Code Across Teams
How to take Claude Code from a few enthusiasts to an organisation-wide standard, with the access, governance, security, training and measurement decisions that make the rollout stick.
Claude Code adoption usually starts with individual engineers and a personal subscription. Turning that into an organisational capability is an architecture and change problem: how engineers authenticate, where model traffic flows, what the tool may do on a corporate machine, how configuration is shared and enforced, and how impact is measured. The professional exam treats the rollout as a designed programme with phases and gates.
Access and traffic routing
Decide how engineers get access before anything else:
| Option | Fits | Considerations |
|---|---|---|
| Team or Enterprise plan with seats | Organisations that want managed seats, single sign-on and usage dashboards | Per-seat licensing; admin controls through the plan |
| API access through the Console | Organisations that want usage-based billing and workspace-level control | Keys or federated identity; Console analytics for Claude Code usage |
| Cloud platform (Bedrock, Vertex AI, Foundry) | Mandated cloud routing for all model traffic | Environment variables select the platform; some features depend on first-party services |
| LLM gateway | Central credential handling, logging and policy | Claude Code points at the gateway's base URL; gateway forwards to the platform |
Many enterprises combine a gateway with a cloud platform so that no developer machine holds a long-lived model credential and every request is logged centrally. Claude Code supports an API key helper so that credentials can be fetched from a secret manager at runtime rather than stored.
Governance through managed settings
Claude Code reads settings from several layers; the organisation's managed settings file, deployed by device management to a system location, takes precedence over everything a user or project sets. Use it to enforce:
- Permission deny rules for dangerous commands and sensitive paths, and to disable the mode that bypasses permission prompts.
- Allowed and denied MCP servers, so developers can use approved connectors and nothing else.
- Telemetry export settings and the environment variables that select the platform or gateway.
- Login constraints such as requiring the organisation's account.
- Pre-registered plugin marketplaces and enabled plugins where the organisation curates them.
Everything not enforced centrally should be shared by convention through project configuration, which the next lesson covers.
Security review
The security team will ask what the tool can do on an engineer's machine and with the company's code. Answer with the controls: permission modes and rules, hooks that block or log commands, sandboxing options, denied access to secrets paths, the MCP allowlist, the data flow to the platform and its retention terms, and the fact that the code itself stays local unless sent as context. Agree a baseline permission policy for the organisation and stricter profiles for sensitive repositories.
Phased rollout
| Phase | Participants | Activities | Gate to next phase |
|---|---|---|---|
| Discovery | A few champions | Try realistic tasks; record what works; draft usage guidelines | Clear list of high-value use cases and risks |
| Pilot | Two or three teams | Managed settings deployed; shared project config; training; baseline metrics captured | Pilot metrics meet targets; security sign-off |
| Expansion | Volunteer teams organisation-wide | Champions network; office hours; plugin and skill library; support channel | Adoption and satisfaction thresholds; cost within budget |
| Standard | Everyone | Part of onboarding; configuration in templates; measurement in engineering dashboards | Ongoing review cadence |
Resist the temptation to skip the pilot. The pilot is where the permission policy is tuned, where CLAUDE.md conventions are discovered, and where the usage guidelines meet reality.
Training that changes behaviour
Engineers do not need a tutorial on typing prompts. They need: how to give the tool context (CLAUDE.md, pointing at files, planning before coding), how permissions work and why the defaults are set as they are, how to review generated changes critically, when to use subagents and skills, how to stop and roll back, and what must never be pasted into a prompt. Teach with the organisation's own codebases and real tickets. Pair champions with teams for the first weeks.
Usage guidelines
Short and specific beats a policy document nobody reads:
- Review every generated change as you would a colleague's pull request; the author is accountable.
- No secrets, customer data or regulated data in prompts unless the repository is approved for it.
- Use the organisation's MCP servers and plugins; request additions through the registry process.
- Commit shared configuration through pull requests; keep personal preferences in local settings.
- Report surprising behaviour and injection attempts through the support channel.
Support and feedback
Create a channel where engineers share prompts, skills and failures, and where the platform team answers questions. Capture recurring questions as skills or CLAUDE.md guidance. Track friction: permission prompts that are always approved become candidates for allow rules; commands that are always denied become candidates for enforcement.
Measurement from day one
Capture the baseline before the pilot: cycle time, review time, defect rates and satisfaction. Enable telemetry export from the start so that adoption and cost are visible by team. The measurement lesson covers the metrics; the rollout lesson's point is that you cannot measure impact without a baseline, and the baseline must be taken before the tool arrives.
Exam focus
- Decide access and traffic routing first: plan seats, Console API access, cloud platforms via environment variables, or an LLM gateway, often combined for central credentials and logging.
- Managed settings take precedence over user and project settings and are the enforcement point for permissions, MCP allowlists, telemetry and login constraints.
- Security review is answered with controls: permission rules, hooks, sandboxing, denied secret paths, MCP allowlists and documented data flows.
- Roll out in phases (discovery, pilot, expansion, standard) with gates; the pilot tunes policy and conventions.
- Training focuses on context-giving, permissions, critical review and what never enters a prompt.
- Capture baseline metrics and enable telemetry before the pilot begins.
Check yourself
5 questions
1.A 400-engineer organisation wants to roll out Claude Code. The CTO proposes announcing it to everyone on Monday and 'letting adoption happen'. The architect is asked for a better plan. Which approach is MOST likely to succeed?
2.An enterprise security team must decide how engineers authenticate Claude Code and how usage is governed. The company already runs its Claude API traffic through Amazon Bedrock with IAM and has a central LLM gateway. Which setup is MOST consistent with their existing controls?
3.During a rollout, several engineers run Claude Code with all permission prompts disabled on their laptops because 'the prompts are annoying'. The architect must set a policy. Which policy is MOST appropriate?
4.Teams in a rollout report inconsistent results: Claude Code follows the conventions in some repositories but not others, and new joiners do not know how to set it up. Which action addresses both issues?
5.Three months into a rollout, usage is high in two teams and near zero in five others. Interviews reveal the low-usage teams worry about code quality, fear being blamed for AI-introduced bugs, and are unsure what is allowed. What should the rollout lead do?