03 writeup

How to Get Your Team to Actually Use Claude

By Mike Taylor

Sam Parr asked a question I hear on almost every consulting call:

How is everyone getting team adoption for Claude? We see all this AI stuff popping up. We're on top of it, or at least sorta. But how do you get your team to actually use it effectively without spending all their time on Twitter and learning—which we know they won't, and probably shouldn't?

I spend a lot of time on Twitter. That's part of my job. The people you're trying to get to use Claude do not have that job, and they shouldn't. If your adoption plan requires everyone to become a power user of the timeline, you don't have an adoption plan. You have a hobby, and you've mistaken it for an operating system.

I recently joined Every as head of tech consulting, working with Natalia Quintero, who built the practice. We sit with companies that are already supposed to be good at this—hedge funds, PE firms, tech companies, Fortune 500s—and watch what actually transfers from the people who live on the frontier to the people who have real jobs. The work is less "here's a tool" and more "here's how Tuesday changes."

A few months in, the pattern is consistent enough to write down. I posted a compressed version of this as a list. Here it is with the reasoning.

1. Buy the model direct, not third-party tools
2. Raise the ceiling, not the floor
3. Workshops with 50%+ build time
4. Assign impossible tasks
5. Mandatory AI note-taking + MCP connector
6. Map workflows and systematically automate
7. Train people to be managers of agents

Use these as a checklist. If you only do the first two, you'll still be ahead of most companies I talk to. If you do all seven, adoption stops being a campaign.

1. Buy the model direct, not third-party tools

One of the first things I watch companies do is evaluate a pile of tools that have Claude, Codex, or Gemini running underneath. The demo looks great. Then you live in the product, and you inherit someone else's hang-ups: their product opinions, their lag on new model features, their idea of what a "workflow" is.

It's usually faster to buy the model and write a Claude skill that encodes your opinions about how the work should be done. A skill is just a document plus some tools. You can read it, change it, and version it. You cannot do that to a vendor's roadmap.

There's a real move toward build-not-buy here, and it isn't ideological. It's about flexibility. I don't know how companies that aren't the model labs keep up. The labs know what release is coming. They build internal tools on that schedule. They train people to operate inside Claude Code before the rest of the market has a wrapper for it.

I appreciate the effort Cursor puts in. They're a good product org. I also don't know how you compete with Anthropic putting something like $5,000 of tokens a month behind a $200 subscription. Third-party tools tend to be less flexible, less on the cutting edge, and more expensive. That's not always true. As a general rule, it is.

If you want people to actually use the thing, give them the thing—not a product that is one layer removed from the thing, with a UI that will be wrong the week a new model drops.

2. Raise the ceiling, not the floor

The most common adoption program I see is: we bought you seats, you all need to use AI now. Sometimes it's even tied to performance reviews.

It doesn't work. Even on pain of death, a lot of people are unwilling—emotionally—to be told they have to use AI. I think it's self-preservation. If your current value is that you are the person who does the work a certain way, a mandate that the work should be done another way feels like an attack. You can call that irrational. You can also notice that it keeps happening.

Use the carrot, not the stick.

Nominate the people who are already AI-forward. You'll be surprised how many of them are sitting in the org already, using Claude Code at night, slightly embarrassed about it. Give those people support, tokens, and cover. Someone who is actually AI-pilled will do five or ten times more than someone who hasn't seen the magic yet. You get a productivity win immediately, which is already more than the mandate delivered.

Then make the social part explicit. The people who use AI aggressively should be the ones who get promoted first and the ones who get time with senior management. We've had success co-opting them as TAs in the courses we teach the rest of the team. When everyone else sees that this person is shipping more, getting ahead, and sitting in the room with leadership, that's a more effective motivator than a Slack announcement from IT.

People need to come to the aha moment on their own timeline. You can accelerate that by making it obvious that the ceiling is where the career is. It is much harder to convince someone to believe than it is to make belief look like the winning strategy.

Raising the floor is a compliance exercise. Raising the ceiling is a talent strategy. Only one of those produces adoption.

3. Workshops with 50%+ build time

You should run workshops. I mean that. Don't skip straight to "we hired an AI person, they'll figure it out."

But the workshop has to be at least 50% build time. People do not want to sit and look at slides. I didn't learn how to do this from a deck. I learned it by doing, with just enough theory to know what to try next.

The biggest complaint we hear is not "I don't believe in AI." It's "I didn't have time to check these tools out." People do not have a blank afternoon sitting in their calendar labeled become a different kind of knowledge worker. If you don't give them that time on purpose, they will not find it.

So you put a couple of hours on the calendar, you make it expected that they will build something outside their normal domain, and you remove the setup tax. Give them the tool, already logged in. Give them synthetic data so they aren't waiting on security. Give them the connectors they actually need. Then get out of the way for half the session.

That's where the aha moment happens. Not on slide 14. On the first thing they build that would have taken them the rest of the week.

Guided theory is useful as motivation. Build time is where the belief gets installed.

4. Assign impossible tasks

By impossible, I mean a task that would not have been possible to complete without AI. Not "do your current job a bit faster." Something that doesn't fit in the old week.

Boris Cherny, who built Claude Code, has made a similar point: slightly under-resource most teams, and they figure out that the only way through is to use AI. I like to make it more explicit than that. Don't just starve the team and hope. Pick the goal on purpose.

If your writers are supposed to produce one blog post a week, they can do that by hand. They will, and they will never need Claude for anything that matters. If the goal is one post a day, they have to use a lot of AI in the research phase, the drafting phase, the editing phase. The old process cannot absorb that volume.

You don't set the goal as "starting today, one a day, no excuses." You set it as: our goal is to get to one a day. What's the gap. What's your progress toward closing it. It might take a while. If they know that's the destination, they start thinking strategically about where AI saves time, and they start experimenting without being asked.

The reason your team doesn't use Claude is often not that they haven't watched enough demos. It's that their job still makes sense without it. Impossible work is how you make the old job stop making sense.

5. Mandatory AI note-taking + MCP connector

This one is a bigger unlock than it looks.

Everyone on our consulting team uses Granola, plus the Granola MCP. After a meeting I can say: we just talked about X, draft an update email, send it to Y. That's not a party trick. It's the job.

I think 80–90% of the value of AI, for most knowledge workers, is extracting information from unstructured data and putting it into a shape you can use. Transcripts, messy notes, a half-remembered decision from last Thursday. There are so many times I sit down to write a curriculum, or a proposal, or a follow-up, and realize I need context from a meeting. Now I pull it from the MCP instead of reconstructing it from memory or pinging someone to ask.

If you only mandate one behavior, mandate this. Not "use AI." "Your notes are captured, and Claude can see them." Once the model has the raw material of the week, people start asking it to do things with that material. That's adoption, and you didn't have to teach anyone a prompting framework to get it.

Most companies skip this because it feels like a small ops decision. It isn't. It's how you give the model a memory of the business.

6. Map workflows and systematically automate

We run discovery by asking people what they actually do all day: the tools, the repeating tasks, the pain. Then we dump that into a structured Google Sheet and work down the list. The assumption is that we're trying to get 100% of it off the person—or at least the first pass of it, with a skill for each type of task.

If you do that seriously, that person can run at five to ten times their current throughput.

So far, that has not led to people being let go. What it leads to is one of two things: they put way more effort into each task, or they expand the revenue and throughput of the team without hiring. Both are better than the fantasy where you buy a tool, usage is mediocre, and then someone asks why headcount didn't drop.

A concrete example from our own work. When we used to run courses for a team, we'd prepare one task for the whole cohort. Then we got to one task per pod. Now we can use Claude Code to generate an individual project for each person in the room. That wasn't possible before. We're not using AI to fire the person who designed the exercises. We're using it to put more care into each student than we could afford to put in by hand.

Map the work. Automate down the list. Spend the slack on quality, or on volume, or on both. Do not skip the mapping step and hope a seat license finds the workflows for you.

7. Train people to be managers of agents

Here's the shift I didn't fully expect, even though I should have.

Everyone who was an individual contributor is now a manager. They're managing a fleet of tools they didn't hire, they don't fully trust, and they were never trained to run. They're not used to context switching. They're not used to putting systems and rules in place. They're not used to evaluating work they didn't do themselves, or having a strong opinion about whether it's good.

That's management. We just used to reserve it for people with direct reports.

Managers often take to this more readily, once they get the aha moment, than ICs do. ICs care about the craft. They care how the thing was made. Managers got over that years ago. They want the problem solved to spec. An agent is a very obedient, very fast report if you can brief it.

The funny inversion is that managers are becoming ICs again, because they can often manage a team of agents more effectively than they can manage their human team. Bandwidth to a human is low. The feedback loop is days. Sometimes it's easier to vibe-code the task in Claude Cowork than to brief a person who will then brief their own Claude. By the time you've written the prompt, you can send it to Claude and have an answer in five minutes, or send it to a human and wait two days for them to send it to Claude.

If that's the physics, you need to train for it. Teach context switching. Teach evals. Teach taste—how to decide what "good" is when you didn't make the artifact. Teach people how to train the AI in a specific skill: a really good PowerPoint skill, a really good daily-update skill, whatever the job actually runs on.

Look around at your coworkers. Everybody you work with is, by definition, already capable of using a computer in English. That was supposed to be enough. It isn't, because giving direction, specifying a format, providing examples, and checking the work is a management skill. We used to call the AI version of that prompt engineering. I don't think the name matters. The job does.

The companies that get this will stop sending ICs to a chatbot 101 lecture and start teaching them how to run a team whose headcount is mostly software.

What this adds up to

None of these seven things require your team to live on Twitter. That's the point.

Twitter is how a handful of people find the frontier. The rest of the company needs something else: the model itself, a few believers with air cover, a workshop where they actually build, a goal they can't hit by hand, notes the model can read, a list of workflows to chew through, and the management skills nobody taught them because last year they were still individual contributors.

I used to think the hard part was the tools. After a stretch of this work, I don't. The tools are the easy part, and they keep getting easier. The hard part is changing what people are asked to do, and who gets rewarded for doing it.

If you change the work, people use Claude. If you don't, they will nod in the all-hands, log in once, and go back to the job that still fits in a normal week.

---

Assumptions

• Authorship: written in Mike Taylor’s voice, as Head of Tech Consulting at Every. Natalia Quintero (@NataliaZarina) is treated as the person who built and runs Every’s consulting practice (from public Every material; not named in the interview).
• The March 2026 tweet is the spine; the interview transcript is the source of the arguments and examples. Natalia’s consulting post is used only for scene-setting, not as a source of tactics.
• Transcript names corrected: “Boris Cheney / Cold Code / Cloud Code / Cloud Cowork” → Boris Cherny / Claude Code / Claude Cowork. “buy the Mobile Direct” → buy the model direct.
• Granola is kept as the note-taking tool named in the interview.
• Form: an Every.to-style essay, matching the sample in The Ultimate Guide to Prompt Engineering (first person, numbered principles, concrete examples, analogy back to management/prompting).