Team Adoption

Why Your Team Is Pushing Back (And They're Not Wrong)

Before you evangelize, understand the resistance. It's rarely about the tool.

• "It will replace me." The unspoken fear. Address it directly: Claude Code makes devs faster, not unnecessary. The people who adopt AI tools become more valuable, not less.
• "I don't have time to learn another tool." Totally valid. If onboarding takes more than an hour, your rollout plan is broken.
• "AI code is sloppy." Often true, when there's no config. Without a shared CLAUDE.md, Claude Code guesses at your conventions. With one, it follows your exact standards. The "sloppy" complaint is almost always a configuration problem.
• "I tried ChatGPT once and it was useless." Claude Code is fundamentally different from a chatbot. It reads your codebase, runs commands, and has persistent context. That comparison doesn't hold, but you need to show that, not argue it.

Don't Roll Out to Everyone. Start with Champions.

This is the strategy that actually works. Forget the all-hands demo.

Step 1: Pick 2-3 champions. Curious about AI, respected on the team. They don't need to be senior, just people others listen to.

Step 2: Give them a week to build their workflow. Real work, not artificial exercises. Let them set up CLAUDE.md, create memory files, and integrate Claude Code into their actual tasks.

Step 3: Champions demo real wins. A 10-minute show in a team meeting. Concrete examples: "I debugged this production issue in 15 minutes instead of 2 hours" or "It wrote all the test scaffolding for my feature." This is worth more than any slide deck.

Step 4: Open it up with a ready-made setup. Once champions have proven the value, give the rest of the team a shared config to start with. Zero guesswork on day one.

The Shared CLAUDE.md Is Everything

This is the single most important thing for consistent adoption. Without it, every developer gets a different experience. Some love it, others think it's broken. The difference is almost always configuration.

Your shared CLAUDE.md should cover:

• Coding standards: Naming conventions, file organization, import ordering
• PR conventions: Commit format, review checklist, branch naming
• Testing rules: Minimum coverage, framework, what to test vs skip
• Architecture patterns: Where things live, how modules connect
• Forbidden patterns: Things Claude Code should never do (suppress lint, use any, add console.log in production)

Store it in .claude/CLAUDE.md in your repo. Version-controlled. Everyone gets the same config automatically.

Onboarding Checklist (Under 1 Hour)

When someone new needs to get started:

• Install Claude Code CLI
• Clone the repo (shared CLAUDE.md comes with it)
• Create personal memory: role, current focus, one preference
• First task: ask Claude Code to explain a file they're unfamiliar with
• Second task: have Claude Code write a test for existing code
• Pair with a champion for 30 minutes to see their workflow

The goal is a working setup, not mastery. Mastery comes from daily use.

How to Know It's Working

Do not measure lines of code generated. That metric is meaningless and encourages the wrong behavior.

Mistakes That Kill Adoption

Forcing it. Making Claude Code mandatory before people see the value creates resentment. Let results pull people in.

No shared config. The number one reason people think the tool is "bad." It's not bad. It just doesn't know your conventions yet.

No champions. Rolling out to everyone at once means nobody is an expert. Questions go unanswered, frustrations pile up, tool gets abandoned.

Overcomplicating the setup. Start with a simple CLAUDE.md covering your top 5 conventions. A 500-line config file on day one scares people off.

Ignoring the skeptics. Long story short: the loudest critic often becomes the strongest advocate once they see a real demo. Invite them to watch a champion work. Don't argue in the abstract.