Claude Code for teams: the rollout playbook_
Installing Claude Code takes a developer ten minutes. Rolling it out to a team of twelve — past the security review, without someone's agent rewriting a payment module unsupervised, with conventions that make the tool better every week instead of noisier — is a different job. This is the playbook for that job: deployment options, permission scoping, the pilot, the phases, and the question nobody budgets for, which is who owns it afterward.
Two very different "Claude Code setup" problems
If you are one developer setting up Claude Code for yourself, you do not need this page — install it, point it at a repo, and learn by doing. We keep a shorter solo setup guide for exactly that.
This page is for the other situation: you are the platform lead, engineering manager, or staff engineer who has been handed "get the team on Claude Code" as a project. You have a dozen engineers with a dozen different ideas about AI tools, an infosec team with questions, at least one codebase that touches money or customer data, and a hunch that letting everyone configure their own agent from scratch ends badly. That hunch is correct. The difference between teams where Claude Code compounds and teams where it quietly gets abandoned is almost never the model — it is the rollout.
One page version
A rollout that works has four phases, and the order is load-bearing:
- 0.
Decide the plumbing before anyone installs anything. Deployment route, credential audit, permission defaults. One afternoon of decisions that prevents a month of infosec escalations.
- 1.
Pilot with 5–10 developers for two weeks. Real tickets, real repos, one shared CLAUDE.md per repo, deliberately mixed enthusiasm levels.
- 2.
Expand to the department, 10–20 developers. This is where ad-hoc convention breaks and central management starts to matter: managed settings, a reviewed MCP server list, approval gates in front of anything that ships.
- 3.
Go org-wide with a named owner. Rollout is not a finish line. Someone curates the setup on an ongoing basis or it decays.
The rest of this page walks each phase in enough detail to actually run it.
Before anyone installs anything
Pick the deployment route
Claude Code can run three ways, and the right one is usually decided by your compliance situation rather than by preference. Buying seats on Anthropic's Team or Enterprise plan is the least setup and gets central billing and admin controls. Running it against AWS Bedrock or Google Vertex AI keeps inference inside a cloud tenancy your security team has already reviewed, which can turn a three-month vendor review into a configuration ticket. If your company already has an approved Bedrock or Vertex footprint, start there; if not, the Team plan is the shortest path. Decide once, centrally — a team split across routes cannot share settings cleanly.
Run the credential audit
An agent that can execute shell commands can read whatever the shell can read. Before the pilot, walk through what actually lives on a developer laptop: cloud credentials in home directories, .env files with production keys, database URLs in shell history, tokens in dotfiles. The goal is not to make laptops perfect — it is to know what the agent could reach, move the worst of it (production credentials do not belong in plaintext on laptops regardless of AI tools), and write down what you decided. This one document is most of what infosec will ask for, produced before they ask.
Set permission defaults centrally
Claude Code has permission modes ranging from ask-before-every-change to fully autonomous. The mistake teams make is leaving this to individual choice, which yields one developer running unattended full-access sessions next to another who approves every semicolon. Decide the tiers up front — default mode for new repos and new users, auto-accepted edits with gated shell commands as the earned tier, autonomous modes reserved for sandboxed environments — and enforce them with managed settings files deployed by your device-management tooling rather than by memo.
The two-week pilot
Pick 5–10 developers. The composition matters more than the count: at least one person who is excited, at least one who is skeptical, spread across two or three repos with different shapes — a well-tested service, a legacy area, something frontend. If the pilot only contains enthusiasts working on clean code, it will succeed and teach you nothing.
Write the shared CLAUDE.md before day one. Every repo in the pilot gets an instruction file committed to git: how to build and test, the conventions that are not obvious from the code, the areas the agent should not touch. No single hour of the rollout pays back harder than this one — it is the difference between ten developers teaching the agent the same lessons ten times and the repo teaching every session once.
Give it real work. Pilots that route only toy tasks to the agent produce a verdict about toy tasks. Use it on actual tickets — small, well-scoped ones first — and let the normal review process judge the output. Code an agent wrote goes through the same pull request review as code a person wrote. No exceptions during the pilot, and honestly, few after it.
Measure three things, all cheap: how often agent-authored changes survive review without rework, where each developer stopped trusting it (specific task, specific repo), and what people wired up on their own — the unofficial MCP servers and skills that appear during a pilot are a map of what the team actually needs.
Department rollout — where it usually breaks
Going from eight users to twenty is where informal agreements stop working. Three things need to become explicit at this stage.
Central configuration replaces convention
At pilot scale, "we all agreed to use acceptEdits" holds. At department scale it does not. This is what managed settings are for: a policy file deployed to every machine that pins the permission defaults, allowed tools, and the settings individuals cannot override. Ship the baseline centrally and leave room for personal preference above it, not below it.
The MCP server list gets reviewed
MCP servers are how Claude Code reaches your real systems — databases, ticketing, internal APIs. They are also, from a security perspective, integrations with real credentials that need the same review as any other integration. Collect what the pilot group adopted organically, review it once, and publish an approved list with shared configuration in each repo. New server requests go through the owner (phase 3) rather than through whoever finds a GitHub repo first. If MCP is a new concept for part of your team, our plain-English MCP explainer and skills vs MCPs pages exist for exactly that conversation.
Approval gates in front of production
The rule that keeps engineering leadership comfortable at scale is boring and absolute: nothing an agent writes reaches production without a human approving it, and the gate is enforced by the platform — branch protection, required reviews, CI — not by individual discipline. Claude Code's hook system can add checks at the tool level (blocking classes of commands, requiring confirmation on sensitive paths), which is useful defense in depth. But the load-bearing gate lives in the same place it always has: the pull request.
Org-wide, and the ownership question
The org-wide phase is mostly repetition of phase 2 with better documentation: onboarding notes, the approved server list, the CLAUDE.md patterns that worked, usage metrics flowing into your observability stack so the ROI conversation runs on data instead of vibes.
The part that determines whether the rollout still matters in six months is ownership. Agent tooling changes monthly — models improve, features ship, defaults shift, yesterday's workaround becomes today's footgun. A rollout with no owner decays: CLAUDE.md files go stale, permission requests pile up, developers drift back to whatever they used before. Every serious playbook in this space lands on the same answer — a named senior engineer spending a real, budgeted fraction of their time as the Claude Code owner. Curating configuration, reviewing what the tool learned this month, being the person who answers "can we wire it up to the billing database?" with a decision instead of a shrug.
If nobody on the team can carry that fraction — or nobody wants to — that is the gap our fractional AI lead service exists to fill: same ownership, bought by the slice instead of the headcount.
Common questions about Claude Code for teams
Does Claude Code have a team or enterprise plan?
+
Yes. Anthropic sells Claude Code seats on its Team and Enterprise plans, and Claude Code can also run against models you already buy through AWS Bedrock or Google Vertex AI. Which route makes sense depends on where your compliance and billing already live: if your company runs on AWS and infosec has already approved Bedrock, pointing Claude Code at Bedrock is usually the shortest path through review. If you have no cloud-provider relationship in the way, the Team plan is the least setup.
Is Claude Code safe to use on a private codebase?
+
The honest answer is: as safe as you configure it to be. Your code is sent to the model provider you choose (Anthropic directly, or your own Bedrock or Vertex tenancy), so the data-handling question is a vendor-review question, and Anthropic publishes its compliance posture through its Trust Center. The riskier surface is usually local: what the agent is allowed to run, edit, and read on the machine. That is controlled by its permission settings — which is why permission scoping is phase zero of this playbook, not an afterthought.
What is a CLAUDE.md file and why does every rollout guide mention it?
+
CLAUDE.md is the instruction file Claude Code reads at the start of every session — project conventions, build commands, architecture notes, things it should never touch. It is the difference between an agent that acts like a new hire on day one and one that acts like a new hire in month three. It layers: an enterprise-level file for company-wide rules, a project file committed to git that the whole team shares, and a personal file for individual preferences. Writing the shared project file well is the highest-value hour of the whole rollout.
What permission mode should a team default to?
+
Start stricter than you think you need. The default mode asks for approval before edits and commands, which is right for a pilot. Once trust is established on a repo, acceptEdits — auto-approve file edits, still gate shell commands — is the sensible team tier. The bypass mode that skips all prompts has legitimate uses in sandboxed CI, and almost none on a developer laptop with production credentials in the environment. Set the team default centrally with managed settings rather than hoping twelve laptops agree.
How many developers should be in the pilot?
+
Five to ten. Fewer than five and you learn nothing about how conventions collide between people; more than ten and you are running a rollout without the lessons of a pilot. Pick a mix: at least one enthusiast, at least one skeptic, at least two codebases with different shapes. Two weeks is enough to surface the real issues — permission friction, CLAUDE.md gaps, which MCP servers people actually need.
How do we measure whether Claude Code is paying off?
+
Do not start with company-wide dashboards. In the pilot, track three things that are cheap to collect: how often agent-written changes survive review unchanged, where developers say they stopped trusting it (be specific — which task, which repo), and whether cycle time on small well-scoped tickets moves. Claude Code exports usage metrics over OpenTelemetry, so the quantitative side can feed the observability stack you already run once you scale past the pilot.
Who should own Claude Code after the rollout?
+
Someone specific, by name — not "the platform team" in the abstract. The published playbooks in this space converge on a fraction of one senior engineer's time as the steady state: curating CLAUDE.md files, reviewing permission and MCP requests, tracking what changed in the tool that month. If nobody inside the team wants to carry that, it is a natural thing to bring in fractionally — which is, not coincidentally, a service we offer.
Running this rollout is a job. Want it done by someone who has done it?
Everything on this page is doable in-house — that is why we published it. What we sell is the version where it happens faster and the mistakes are ones we already made somewhere else: the deployment decision argued once instead of quarterly, CLAUDE.md files that read like they were written by someone on their fortieth repo, a pilot that produces a verdict your CTO believes. Tell the duck where your team is stuck. You will leave with a plan either way.