03 writeup

How to get your team to actually use Claude

Seven things I've learned since joining Every as head of tech consulting

Sam Parr asked a question on X last week that I've been hearing, in one form or another, on every discovery call I've run since I joined Every Consulting:

"I spent a lot of time on Twitter, as do you. We see all this AI stuff popping up... But how are all you people getting 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 be?"

That's the whole problem in one paragraph. The founder is AI-pilled. They've bought the tools. And yet most of the team is still doing their job the way they did it in 2022, because nobody has time to learn something new on top of the job they already have.

I replied with a list, but a tweet doesn't give you the reasoning behind each point, and the reasoning is the useful part. So here's the longer version: seven things that have actually moved the needle for the companies we work with, and what I think is going on underneath each one.

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

The first thing that happens at most companies is a tool evaluation. Someone gets a budget and goes off to compare a dozen products that all have Claude, Codex, or Gemini running under the hood. I'd skip most of that.

Every third-party tool comes with its vendor's product decisions, hang-ups, and opinions baked in. Those opinions are rarely your opinions. More often than not, it's quicker to write a Claude skill that encodes your own approach to the work than it is to learn a tool, fight its defaults, and then pay for the privilege. Once you own the skill, it's yours to configure and change. This is a real shift toward build over buy, and it's driven by flexibility rather than ideology.

There's also a structural reason I don't think the wrappers can keep up. The model companies know what releases are coming. They build their internal tools on that schedule. They train the model itself to operate well inside their own environment—Claude is literally trained on how to work within Claude Code. I have a lot of respect for what a company like Cursor has done to keep pace, and they're a genuinely good product org. But I don't know how you compete with Anthropic putting something like $5,000 worth of tokens a month behind a $200 subscription.

So as a general rule (not always, but usually): third-party tools are less flexible, further from the cutting edge, and more expensive. Go direct.

2. Raise the ceiling, not the floor

The default adoption strategy is a mandate. "We bought you AI tools. You all need to use AI now." I've never seen that work.

A surprising number of people are emotionally unwilling to use AI, and especially unwilling to be told they have to. It's a self-preservation instinct, and you can't override it on pain of death. You need the carrot, not the stick.

What does work is finding the people who are already AI-forward and pouring support into them. Every company has a few—the person who's been using Claude Code in their spare time and hasn't told anyone—and when you make it visible that this behavior is encouraged, they come out of the woodwork. Someone who's genuinely AI-pilled will get five or ten times more done than someone who hasn't seen the magic yet, so you get an immediate productivity boost just from unblocking the believers. That's much easier than converting a skeptic.

The secondary effect is the one that matters for the rest of the team. People need to have their own aha moment in their own time, but you can speed that up by making it obvious that the people using AI aggressively are the ones getting promoted first and getting time with senior management. We've had good results co-opting those early adopters as TAs in the courses we teach to the rest of the team. When a colleague sees that the TA is accomplishing more, getting ahead, and getting face time with leadership, that's a far more effective motivator than any all-hands announcement.

3. Run workshops that are at least 50 percent build time

You should be running workshops. But the workshop most companies run—two hours of slides about what a large language model is—doesn't change anyone's behavior.

The way I learned AI was by doing it, and I've never met anyone who learned it any other way. A bit of guided theory is useful to motivate people and give them a frame, but the session needs to be at least half hands-on building.

This also solves the complaint we hear most often, which is exactly the one Sam raised: people don't have time. They don't have two free hours in the week to poke at a new tool, stretch themselves, and build something. So give them the two hours. Put them in a room where they're expected to build something new, ideally outside their normal domain. Make sure they have access to the tool. Have the facilitator prepare synthetic data to work with, or confirm ahead of time that everyone has the connectors they need, so nobody spends the session fighting permissions. That's where the aha moment happens, and once someone has had it, they start finding time on their own.

4. Assign impossible tasks

By "impossible" I mean tasks that could not have been done without AI.

Boris Cherny, who created Claude Code, has said something similar: slightly under-resource most teams, so the only way they can hit their goals is by using AI. I like to make it more explicit and choose the stretch strategically.

Here's the shape of it. If the goal is one blog post a week, you can do that by hand, so nothing changes. If the goal is one blog post a day, you're going to have to use a lot of AI—in the research phase, in the editing phase, everywhere. The trick is in how you set the goal. You don't say, "Starting today, you have to produce one a day." You say, "Our goal is to get to the point where you're producing one a day. What would need to happen? What's your progress toward that?" It might take a while to get there. But once the team knows that's the target, they start thinking strategically about where AI saves time, and they start experimenting without being told to.

5. Mandatory AI note-taking, plus the MCP connector

This one is a bigger unlock than it sounds. Everyone on the consulting team has Granola and the Granola MCP, and it's a requirement rather than a suggestion.

The reason is that 80 to 90 percent of the value of AI, honestly, is extracting information from unstructured data and restructuring it into something useful. Meetings are the largest pile of unstructured data in any company. Once that data is at your fingertips, a whole class of tasks collapses to a sentence: "We just had a meeting about X. Write an update email on it and send it to Y."

I can't count how many times I've sat down to do something and realized I needed context from a conversation we had two weeks ago. Now I pull it from the MCP. I include meeting context every time I'm building curriculum or putting together a proposal, and the output is better for it. If you only do one thing from this list, do this one—it's the cheapest and it compounds.

6. Map workflows, then systematically automate them

Most AI adoption is opportunistic: someone discovers a use case, tells a colleague, and that's the process. We try to make it systematic instead.

Our discovery calls are built around a simple set of questions. What do you do day-to-day? What tools do you use? What's painful? We turn the answers into a structured Google Sheet that lists every task, and then we work down the list, one by one.

The operating assumption is that we're trying to get 100 percent of the work off the person's plate. We rarely get there, but if Claude is at minimum doing the first pass on every task, and there's a skill for each type of task they handle, that person can be doing five to ten times the throughput they're doing today.

The question everyone asks next is whether that leads to layoffs. So far, it hasn't. What actually happens is one of two things: people put far more effort into each task, or the team expands its revenue or throughput without hiring. A concrete example from our own work: when we ran courses for a team, we used to prepare one exercise for the whole cohort. Maybe, with effort, one per pod. Now we use Claude Code to build an individual project for every single participant. That simply wasn't possible before, and it's a much better course. We're using AI to invest more in each person, not to cut people.

7. Train people to be managers (of agents)

This is the one I think is most underrated, and it explains a lot of the friction in the other six.

Every individual contributor is now a manager. They have a team of agents reporting to them, and nobody gave them management training. They're not used to context switching between several things in flight at once. They're not used to setting up systems and rules so the work comes out right without them doing it. And they're especially not used to evaluating work they didn't do themselves and having a strong opinion about whether it's good.

Interestingly, actual managers take to this more readily than ICs once they've had their aha moment. ICs enjoy the craft. They care how the problem gets solved. Managers gave that up a long time ago; they just want the problem solved to spec, which is exactly the posture you need with an agent.

And here's the funny inversion: managers are turning back into individual contributors, because it's often easier to manage a team of agents than a team of humans. Briefing a human is lower bandwidth and a longer feedback loop. By the time you've written the prompt, you can send it to Claude and get the result in five minutes, or send it to a person, wait for them to put it into their own Claude Cowork, and get it back in a couple of days. So it's frequently faster for a manager to just vibe code the task themselves.

That's why the training these companies need looks a lot like management training. Teach people how to context switch. Walk them through what's changed now that they're effectively in management. Teach them how to write evals. Help them develop taste for what's worth working on. And teach them how to train the AI on specific skills: how do you systematically build a really good PowerPoint skill? A really good daily-update-report skill for Claude? Work through those with them, one at a time.

The pattern underneath

If you squint, the seven points are really one point. The teams that adopt AI aren't the ones that were told to. They're the ones where someone made it structurally easier to use AI than to not use it: the model is one step away instead of three, the believers are rewarded and visible, the goals can't be hit by hand, the context is already in the tool, the work is written down as a list, and people have been taught the new job they've been given.

None of this requires your team to spend their days on Twitter. That's the point. Sam is right that they won't and shouldn't. The learning has to happen inside the work, and the job of whoever's leading adoption is to set the work up so that it does.

---

Notes for you (not part of the post):

• I wrote this as you (Michael Taylor, matching the sample and the @hammer_mt tweet). The Natalia post on consulting at Every wasn't in the folder, so I didn't borrow any framing or facts from it—everything about Every Consulting comes from your transcript. I also didn't name whoever runs consulting, per your note.
• Transcription fixes I applied: "Boris Cheney, a vendor of Cold Code" → Boris Cherny, creator of Claude Code; "cloud code/cloud skill/Cloud Cowork" → Claude Code / Claude skill / Claude Cowork. Worth double-checking the Cherny paraphrase and the "$5,000 of tokens for $200" figure before publishing, since both are from memory in the transcript.
• "Last week" in the intro and "since I joined" are placeholders for timing you'll know better than I do.