What you need to know
Giving every engineer access and letting each one configure Claude Code alone produces forty different setups, uneven results and no way to enforce anything. Team setup is an architecture decision with four parts: shared configuration, distribution of reusable assets, spend posture and rollout.
Shared configuration: guidance versus enforcement
Claude Code reads configuration at several levels, and the difference between them matters.
| Layer | What it does | Use for |
|---|---|---|
| Organization-managed settings | Set by administrators; override user and project settings | Rules that must hold everywhere: denied commands and paths, allowed tools, approved model choices |
| Project settings (in the repository) | Shared by everyone working in that project | Project permissions, hooks, MCP servers the project needs |
| Instruction files (CLAUDE.md) at organization, project and user level | Load standing context and conventions into every session | Coding standards, repository layout, how to run tests |
| User settings | Personal preferences | Editor habits, personal shortcuts |
Instruction files are guidance: Claude follows them, but they cannot prevent an action. Permissions, managed settings and hooks are enforcement. Anything that must never happen ("never read .env files", "never push to main") belongs in permission rules or hooks, not only in an instruction file.
Distributing reusable assets
| Mechanism | Reaches | Versioning and rollback | Fits |
|---|---|---|---|
| Project Skills in the repository | Everyone working in that repository | Versioned and rolled back with the repository | One team's procedures and conventions |
| Plugins managed for the organization | Chosen groups or the whole organization | Version-controlled updates; can be required, installed by default or optional | Governed procedures and tool sets for specific teams |
| Organization-provisioned Skills | Everyone in the organization | Central availability, more limited version control | Capabilities everyone should have |
| API Skills | Your own products, programmatically | Version pinning in the calling system | Machine-to-machine reuse |
Choose by who needs it and how much control over updates and rollback you need. A shared asset with no way to roll back can push one bad change to every engineer at once.
Spend posture
Decide the limits before usage grows: default model and allowed models, guidance on effort or thinking levels, per-user and per-team spending caps, rate limits, and usage reporting. Track usage and outcomes with analytics so spending can be tied to results.
Rollout: champions, then batches
- Pilot with a champion in each team, who adapts the shared setup, finds the useful workflows and writes them down.
- Expand in batches, team by team, with the champion supporting each batch.
- Measure and adjust: usage, outcomes (cycle time, review findings), costs and feedback, before the next batch.
Two failure patterns to avoid: lumpy adoption (a few heavy users, everyone else idle, so practice never standardizes) and stalling at chat (teams use it to ask questions but never adopt repository-aware workflows, Skills or tool integrations, because nobody enabled them).
In the exam
Team-configuration questions ask where a rule belongs, which distribution mechanism fits a Skill, how to control spend, or how to roll out. Enforce must-never rules in settings, permissions or hooks; use instruction files for conventions; match distribution to audience and rollback needs; set spend limits up front; and roll out through champions and batches.
Check your understanding
Security requires that Claude Code never read files matching .env* in any repository. Where should this live?
Show answer
Answer: D. A rule that must hold everywhere belongs in enforced, organization-managed settings. Instructions and training guide behaviour but cannot block a read.
A release procedure must run identically in six departments, and the platform team must be able to update or roll it back centrally. What fits best?
Show answer
Answer: C. Group targeting with central, version-controlled updates and rollback is what organization-managed plugins provide. Copies in many repositories drift.
Which TWO practices prevent "stalling at chat" during a rollout?
Show answer
Answer: A, C. Adoption beyond chat needs enablement: people who demonstrate the workflows and a setup that includes Skills and integrations.
Apply it: Plan Quillstone's Claude Code rollout
Plan how Quillstone rolls Claude Code out to 420 engineers in 38 teams, using the case constraints (SOC 2, secrets incidents, restricted production access, $40 per engineer per month).
- Split the rules into enforced settings and instruction-file guidance.
Done when: every rule tied to a past incident or SOC 2 is enforced. - Choose distribution mechanisms for: the secrets checklist Skill, the release procedure, each team's own conventions, and the logging-migration guide.
- Set the spend posture.
- Write the rollout plan with dates relative to day 1, and the measures that gate each batch.
Show model answer
1. Rules
| Enforced (managed settings, permissions, hooks) | Guidance (CLAUDE.md) |
|---|---|
Deny reading .env*, key files and the secrets directory | Commit message format |
Deny git push to protected branches; deny force-push | Test conventions per language |
| No production credentials or write access in any session | Service layout and where things live |
| Approved MCP servers only | How to run the local stack |
| A hook that scans staged changes for secrets before commit | When to ask for a security review |
2. Distribution
| Asset | Mechanism |
|---|---|
| Secrets checklist Skill | Plugin required for all engineering groups, owned by security |
| Release procedure | Plugin for the teams that release services, versioned by the platform team |
| Team conventions | Each repository's project instructions and project Skills |
| Logging-migration guide | Project Skill in the monorepo, plus a plugin for the 40 other repositories during the migration window |
3. Spend posture. Balanced tier as default, the top tier allowed on request for specific work; per-user monthly cap at $60 with an alert at $40; team-level reports weekly; analytics tracking usage alongside pull request cycle time.
4. Rollout. Days 1 to 30: one champion per team (38 people) on the shared setup; they record workflows and issues. Days 31 to 60: first batch of 10 teams, supported by their champions. Days 61 to 120: remaining teams in three batches. Each batch starts only if the previous one shows weekly active use above 60%, no secrets or permission incidents, spend within the cap, and no rise in review rework.