How to introduce Claude Code in your company, from the first decision to team training

What to decide before the first developer installs Claude Code

Decide two things first: which accounts developers sign in with and which provider receives their requests. Anthropic's guide for administrators lists five providers, and the choice determines billing, sign-in, the compliance terms you inherit and the available features.

The provider also decides which features exist. Cloud sessions, Code Review and Remote Control, among others, need a claude.ai account and are not available with cloud provider credentials alone. On Bedrock and Google Cloud, pin the model versions before you roll out, so that you choose when the team moves to a new model.

Work should run on company accounts only. On the consumer plans Free, Pro and Max, Anthropic trains on the data when the user has that setting switched on, and this includes Claude Code. The managed settings forceLoginMethod and forceLoginOrgUUID, which you set centrally, restrict sign-in to one method or to your Anthropic organisation.

What happens to code and prompts

Claude Code runs on the developer's machine and sends prompts and model outputs to the provider, encrypted in transit with TLS 1.2 or higher. For Team, Enterprise and API customers, Anthropic states that it does not train generative models on code or prompts from Claude Code, and it keeps the data for 30 days as standard. Zero data retention exists for qualified Enterprise accounts, and Anthropic enables it per organisation.

On Amazon Bedrock and Google Cloud, retention follows those platforms' terms. AWS documents that model providers have no access to the accounts in which Bedrock runs the models, and therefore none to customer prompts and completions. With every provider, session transcripts also stay on the developer's machine in plain text under ~/.claude/projects/, for 30 days by default, and cleanupPeriodDays changes that period.

Which settings and permissions to set centrally

Put everything that must hold on every machine into managed settings, because user and project settings cannot override them, apart from a few security-sensitive exceptions. A Teams or Enterprise organisation sets them in the Claude admin console. With any provider, device management can deliver them as a macOS configuration profile or Windows registry policy, or as a managed-settings.json file, under /etc/claude-code/ on Linux.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}

This file blocks reads of .env and of a secrets directory, switches off the mode that skips permission prompts, and makes managed settings the only source of permission rules. Rules are evaluated deny first, then ask, then allow, and a deny at any level cannot be lifted by another. Decide on these controls as well:

• Network and filesystem: a Bash rule matches the command text and is no security boundary, since Bash(curl *) does not stop /usr/bin/curl. Limits that hold come from the sandbox with a list of allowed domains.
• MCP servers, which connect Claude Code to external tools such as the ticket system: allowedMcpServers and deniedMcpServers restrict which servers developers can add.
• Hooks and models: a hook is a shell command that Claude Code runs at a fixed point, and allowManagedHooksOnly restricts which hooks run. availableModels limits the models developers can pick.

After deployment, have a developer run /status. If the line "Setting sources" shows "Enterprise managed settings", the policy is in force.

What goes into the repository

Commit everything the whole team should share, so that it goes through review like code.

• CLAUDE.md in the root holds the team's instructions, such as build and test commands and conventions. The /init command drafts one from the codebase. Claude treats the file as context and does not enforce it, and Anthropic advises staying under 200 lines per file.
• .claude/settings.json holds the project's permission rules and hooks, for example a formatter that runs after every file edit.
• .claude/skills/ holds procedures that the team calls as slash commands. Each skill is a SKILL.md file whose body loads only when it is used.
• .mcp.json lists the project's MCP servers. Claude Code asks each developer for approval before it uses servers from this file.

Personal preferences stay out of the repository, in CLAUDE.local.md. An existing AGENTS.md for other coding agents stays, and CLAUDE.md imports it with the line @AGENTS.md, because Claude Code reads CLAUDE.md. Who owns these files is covered in our guide on Claude Code team instructions.

How to run a pilot with one team and what to measure

Start with one team whose repository has working tests and CI, and let it use Claude Code on its normal tickets. Anthropic's advice for new users is modest: begin with questions about the codebase and smaller bug fixes, and ask for a plan first. Write down beforehand which result would make you extend the pilot and which would make you stop.

Measure the work at team level and compare it with the same figures from the months before the pilot:

• Time from first commit to merge for comparable tickets
• Review findings and rework per merged pull request
• CI failures and reverted changes
• Spend per merged pull request, from the provider's usage export

The analytics dashboard on Teams and Enterprise shows lines of code accepted, the suggestion accept rate and daily active users. These are adoption figures and say nothing about whether a change was good.

Designing a fair coding agent pilotWhat a rollout costs for 50 engineers

Why training should use the team's own tickets

Train on the team's own repository and backlog, because the questions that decide results only come up there: which task to hand over and how much context the ticket needs. The basics are covered by Anthropic's free self-paced courses, Claude Code 101 and Claude Code in Action.

A session on real tickets should cover these points:

• Plan mode, in which Claude reads the code and proposes a plan without editing files
• Reading the diff and the test run before accepting a change
• Permission prompts, and which approvals belong in the shared settings file
• When to add a line to CLAUDE.md, for example when Claude makes the same mistake a second time
• What must not go into a prompt, according to your own data classification

What the works council and the data protection officer will ask

The works council will ask what the tool can record about individual developers. Section 87(1) no. 6 of the Works Constitution Act (BetrVG) gives it co-determination over technical devices designed to monitor employees' behaviour or performance, and the Federal Labour Court held on 8 March 2022 (1 ABR 20/21) that it is enough for a device to be objectively suitable for recording such information. How this applies in your company is a question for your employment lawyer. This is not legal advice.

The export of usage data to your own monitoring through OpenTelemetry stays off until CLAUDE_CODE_ENABLE_TELEMETRY is set, which administrators can do for everyone in managed settings. Once on, the metrics cover sessions, lines of code changed, commits, pull requests, cost and active time. They carry the account ID and the user's email address unless you switch these off or filter them out in the collector. Prompt text is not exported by default. On Teams and Enterprise, admins and owners also see a leaderboard of individual users in the analytics dashboard.

A works agreement can therefore fix whether the export is enabled, which attributes are removed before storage and who holds the admin role. Our guide on works council logging goes through the fields.

The data protection officer will ask where the data is processed, how long it is kept and on what contractual basis, and the answers follow from the provider decision above. Under Article 28(3) GDPR, processing by a provider on your behalf needs a contract, and Article 35 requires a data protection impact assessment where processing is likely to result in a high risk. Settle with your data protection officer whether it does.

What the works council sees in AI system logsWorks councils

When outside help makes sense

A team with its own platform group and time to read the documentation can do most of this alone. Outside help pays off in these situations:

• Nobody has the time to own the settings, the repository setup and the pilot next to their normal work
• Security, data protection or the works council have open questions, and the project waits for answers
• One team already uses Claude Code, and its way of working does not carry over to the next team

In Claude Code consulting we fit Claude Code to your codebase, permissions and review process and run the pilot with one team. In Claude Code training your developers practise on tickets from their own backlog. Both start the same way: talk to an engineer, a free 30-minute call that needs no access to your systems or data. After that we agree a fixed price for each step in writing.

Claude Code consulting and rolloutClaude Code training for teamsCoding agent adoption