How to get a skeptical teammate to actually try Claude

Every team Claude rollout has the same person. They have been around long enough to have seen productivity tools come and go. They tried an AI tool once and found it generated confident-sounding nonsense. They are not hostile — they just do not think it is going to change their work, and they are not going to pretend otherwise.

If you push them too hard, they comply performatively and then revert. If you ignore them, they become the visible non-adopter who makes the rollout feel like a failure even when the rest of the team is getting real value.

Here is what actually works.

What does not work (first)

Sending articles and videos. People do not change their minds from reading general content about AI capabilities. They change their minds from doing something specific and having it work.

Assigning use cases. "Use Claude to write your weekly update" — given as a directive — feels like extra work with a new tool added on top of the actual work. It is experienced as a burden, not an opportunity.

Showing them impressive demos. Demos of other people's workflows are not credible. The skeptic has already heard about the impressive things AI can do. That is not the reason they are skeptical. They are skeptical about whether it will do those things reliably for their specific work.

Framing it as a company initiative. The more the rollout is positioned as a top-down mandate, the more the skeptic's resistance is about the mandate, not about Claude. You want their first real use of Claude to be something they chose.

What actually works

Start with their actual frustration, not your use case.

The most effective approach is to ask the skeptic what they find most tedious or repetitive in their current work — not "what could AI help with?" but "what do you find yourself doing that you wish someone would just do for you?"

Then try Claude on exactly that, together, with real data. Not a demonstration of what it can do generally — a direct attempt on the specific thing they find annoying.

If it works, they experienced it themselves. If it does not work well the first time, that is also fine — troubleshoot it together. "What would make this output actually useful?" is a useful conversation that builds their understanding of what good prompting looks like.

Give them something that saves time today, not something that might help in the future.

The best first use case is something that has an immediate, measurable time saving: draft a document they have been putting off, summarize a long thread they need to respond to, prepare talking points for a meeting they have this afternoon. The value needs to be felt in the same session, not promised for the future.

Let them own the prompt.

When you work through the first use case together, let them write (or heavily modify) the prompt. People trust outcomes they had a hand in producing. If you run the prompt and show them the output, they are watching a demo. If they run the prompt themselves, they produced the output.

Do not oversell the result.

The skeptic's radar is tuned for hype. If you say "wow, that would have taken you an hour!" when the draft is actually mediocre, you lose credibility. Acknowledge what was good, acknowledge what needs fixing, and let the time comparison be real. "That gave you a starting point in two minutes instead of fifteen — is that useful?" is more persuasive than enthusiasm.

The specific conversation that usually works

Pick a moment when they have a concrete task in front of them — something they need to produce today. The opening that works best is not "can I show you Claude?" — it is something like: "Hey, what's the most annoying thing you have to write this week? I want to try something quickly." That framing is about their problem, not about the tool.

Paste the relevant context and ask Claude to produce a draft. Watch together. Ask: "Is that useful, or is it off?"

If it is off: figure out why and try again. One round of iteration is more instructive than a perfect first result.

If it is useful: ask what they would need to change to send it. Let them edit it. Note how long the whole thing took.

That is the proof of concept. Not a demo, not a mandate — a 10-minute experiment with real work, producing something real.

The people who stay skeptical

Some people will remain resistant after good-faith attempts. A few honest observations:

The people who are most resistant to trying Claude are often the highest performers on the team — they have strong workflows, they are fast at their current approach, and the switching cost is genuinely higher for them. This is not perversity. They are correctly assessing that their existing workflow is good.

For high performers, the right framing is not "Claude will help you do your job" — it is "Claude frees up your time for the work only you can do." The value proposition is different. It is about offloading the parts of their work that do not require their specific judgment, so they can spend more time on the parts that do.

The people who never convert are usually fine. One visible holdout does not undermine a team rollout if the rest of the team is getting real value. Trying to force adoption from someone who has genuinely evaluated Claude and decided it does not help them is not a productive use of your time.

---

If you are managing the broader rollout question — sequence, metrics, what success looks like — running your first AI pilot covers the structural side. For the CS team context specifically, the CS manager workflow guide shows what the practical day-to-day looks like once adoption is working.

Further reading

• How enterprises are driving AI transformation with Claude — adoption patterns that prevent plateaus