"We rolled out Claude Code to the whole team. People can use it whenever they want."
I hear a version of this sentence often, usually from a founder or eng lead trying to explain why adoption looks patchy three months in.
The sentence is the problem. "People can use it whenever they want" is not a plan. It is the absence of one.
Why "just use it" fails quietly
It fails quietly because it does not look like a failure. Nobody objects to the rollout. Nobody complains about the tool. The team just... does not change how it works, except for the two or three engineers who were always going to figure it out on their own.
"Just use it" assumes the barrier to adoption is awareness. It is not. Every engineer on the team knows the tool exists by week two. The barrier is not knowing what to use it for in a way that is worth the risk of trying and failing in front of a reviewer.
Left with no specific guidance, most engineers make a rational choice: stick with what already works. Trying a new workflow on a task that matters, without knowing whether it will actually help, is a bad trade for someone who is already busy.
What is actually missing
A real adoption plan answers questions that "just use it" leaves open:
- What specific tasks should the team try this on first? Not "anything," but a short, concrete list.
- What does a good AI-assisted PR look like here, so an engineer knows the bar before they submit one?
- Who notices if adoption stays concentrated in a few people, and what do they do about it?
- Is there time carved out to build the habit, or is this expected to happen in the margins of an already full sprint?
Without answers to these, "just use it" defaults to "the people who were already going to figure it out will figure it out, and everyone else won't."
The lunch-and-learn does not fix this either
A kickoff meeting or a demo session helps people understand what the tool can do. It does not build a habit. Habits form from doing something repeatedly in the actual flow of work, not from watching someone else do it once in a conference room.
If your rollout plan is "announcement, then let people use it," you have covered awareness and skipped habit formation, which is the part that actually determines whether adoption spreads.
What a real plan looks like
It does not need to be complicated. It needs to be specific:
- Pick one or two workflows the whole team will use first. PR description drafting, test triage, or first-pass code review comments are good starting points because the risk is low and the value is visible fast.
- Write down what a good output looks like for that workflow, so engineers have a bar to aim for instead of guessing.
- Give it a real timeline, not an open-ended "whenever people get to it."
- Check in after a few weeks and ask who has and has not adopted the workflow, and why.
That is a plan. "Just use it" is a hope.
What good looks like
A team with a real adoption plan can describe, in a sentence, what the team standardized on and how they know it is working. A team running on "just use it" usually cannot, three months later, name more than a couple of specific things that changed.
If your rollout has been "the tools are available" for a while now and adoption still looks the same as it did in month one, book a call. If I'm not the right person to help, I'll say so.