What happened when 200 engineers got Claude Code access with zero training

Last year we rolled out Claude Code to our entire engineering organization — roughly 200 people across 30 teams. No training. No guidelines. Just licenses and a Slack message that said "it's available, go try it."

Here is what actually happened.

The 10/60/30 split

Within six weeks, a pattern emerged that I have since heard repeated at four other companies:

• 10% became power users. These were the engineers who had already been experimenting with ChatGPT and Copilot on personal projects. They dove in immediately, built custom CLAUDE.md files, and started using worktrees and subagents within the first week.
• 60% tried it once or twice and then mostly stopped. They opened it, tried a vague prompt like "refactor this function," got a mediocre result, and concluded it was not ready for real work.
• 30% never opened it. Not hostile, just busy. They had a backlog, a way of working that was functional, and no obvious reason to change.

The cost nobody talks about

The 10% power users became a bottleneck. They were fielding 15-20 DMs per day. Their actual feature work slowed down. We had created a new kind of tech debt — knowledge debt — concentrated in a handful of people.

What structured onboarding changed

Three months in, we ran a structured pilot with 40 engineers from the 60% group. Four weeks after the pilot, the adoption rate in that group went from roughly 30% regular usage to 75%. Not because the tool changed — because the engineers' mental model changed.

The takeaway

Buying licenses is not adoption. The gap between "tool available" and "tool useful" is a training gap, and it is wider than most engineering leaders expect.