# How to Get Your Team to Actually Use AI: 7 Learnings from Every Consulting

Whenever someone tells me their team won't adopt AI, I assume they haven't been given a reason to.

I just joined Every as head of tech consulting. I've spent the last few weeks inside companies that are struggling with the exact problem Sam Parr tweeted about last week:

> I spend all day on Twitter. I see all this AI stuff popping up. I'm 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?

He's right. They won't. And they shouldn't have to.

Good adoption isn't about making everyone an AI researcher. It's about setting up the conditions where normal, busy people get that first aha moment, and then can't go back. Just like prompting, it's a management skill, not a technical one.

Here are the seven principles that have actually worked.

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

Most teams start by evaluating tools that just wrap Claude or Codex or Gemini under the hood.

When you do that, you're inheriting someone else's opinions about how work should be done. Their product decisions, their hang-ups, their abstractions. Quite often it's quicker and easier to just create a Claude Skill that has *your* opinions baked in and run it directly.

This is why I'm increasingly in the build, not buy, camp. It's not ideological, it's practical:

1. **Flexibility.** It's easier to configure and operate your own skill than to fight a third-party UI.
2. **Cutting edge.** The core model companies know what's coming. They build their internal tools to line up with those releases. They train the model to operate inside e.g. the Claude Code environment.
3. **Cost.** I appreciate what companies like Cursor are doing — they're a good product org. But I don't know how you compete with Anthropic offering $5,000 worth of tokens a month inside a $200/month subscription.

That's not always true. Sometimes a vertical tool is worth it. But as a general rule: buy the model direct, then build thin.

### 2. Raise the ceiling, not the floor

A lot of leaders come in and say: you all need to use AI now. We bought you the tools. Go adopt it.

Even on pain of death, that doesn't work. People are unwilling emotionally to be told they have to use AI. It's a self-preservation thing.

Use the carrot, not the stick. Nominate people who are already AI-forward.

Every team has them — the person who's already using Claude Code in their spare time. Get them out of the woodwork. Make it explicit that it's encouraged. Give them support.

Someone who's really AI-pilled will do 5-10x what someone who hasn't seen the magic yet will do. And when you promote those people first, give them time with senior management, make them TAs in the workshops you're running for the rest of the team, everyone else notices.

That's a more effective motivator than a mandate. You get the productivity boost of enabling the believer, and you don't waste time trying to convince someone to believe before they're ready.

### 3. Workshops should be 50%+ build time

You should do workshops. But people do not want to sit and look at slides and theory.

The way I learned AI was by just doing. You need some guided theory to motivate people, but the biggest thing we hear is: I just didn't have time in my day to check out these tools.

So give them time.

A couple of hours in a workshop where they're expected to build something new, outside their normal domain, with the tool already provisioned, with synthetic data to work with, with the connectors they need already installed — that's where they get the aha moment.

If you run down this checklist and they still don't get it after building, you probably have a motivation problem, not a training problem. Go back to principle 2.

### 4. Assign impossible tasks

By impossible, I mean tasks that wouldn't have been possible to do *without* AI.

Boris Cherny [has said something similar](https://x.com/bcherny): slightly under-resource most teams, and the only way they can deliver is if they use AI. I like to make it more explicit.

If your goal is to write one blog post a week, you can do that manually. If your goal is to write one a day, you're going to have to use AI in the research phase, in the editing phase, etc.

Don't set the goal as: starting today you have to produce one a day. Set it as: 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 goal?

It might take time to get there. But once they know that's the direction, they'll start thinking strategically about how to save time and start experimenting on their own.

### 5. Mandatory AI notetaking + MCP connector

This is a really big unlock.

Everyone on the consulting team has Granola and the Granola MCP. It's so much easier when you have that data at your fingertips to say: we just had a meeting on X, draft the update email on that topic and send it to Y.

Honestly, 80-90% of the value of AI right now is extracting information from unstructured data and structuring it in a way that's useful.

So many times I've come to a task — writing curriculum, putting together a proposal — and realized I need context from a meeting we had two weeks ago. Now I just pull it from Granola via MCP.

Mandatory notetaking sounds heavy-handed, and it is. This is the one mandate that works, because the payoff is immediate and it compounds. No notes, no context. No context, no leverage.

### 6. Map workflows and systematically automate them

We have a process for discovery calls where we ask: what do you do day-to-day, what tools do you use, what are the pain points?

Then we turn that into a structured Google Sheet — a list of everything that team does — and we just systematically work down the list. The assumption is we're trying to get 100% of the stuff off people, or at minimum do the first pass, with a Skill for each type of task.

That person can then do 5-10x the throughput.

And so far, that doesn't lead to people being let go. What it leads to is either they put way more effort into each task, or they expand the revenue / throughput of their team without hiring.

Example: when we were doing courses, we used to prepare one project for the overall cohort. Then we got to one project per pod. Now we're at a point where we can use Claude Code to create an individual project for each person taking part. That wasn't possible before AI.

We're using AI to put way more effort into each course, not to fire someone.

### 7. Train people to be managers (of agents)

Everyone who was an individual contributor before is now a manager, and they're struggling because they've never had management training.

They're not used to context switching. They're not used to setting up systems or rules. They're not used to evaluating work they didn't do themselves, or having a strong opinion about whether something is good when they didn't craft it.

Funny thing is, managers often take to this more readily than ICs once they have the aha moment. ICs enjoy the craft — they care about *how* something is done. Managers got past that a long time ago. They just want the problem solved to spec.

At the same time, managers are now becoming ICs, because they can manage a team of agents more effectively than they can manage their human teams. Sometimes it's lower bandwidth to explain something to a human with a longer feedback loop than to just vibe-code it yourself in Cowork.

By the time you've written the prompt, you can send it to Claude and get a response in five minutes, or send it to a human and wait for them to send it to their Claude and get back to you in a couple of days.

So you need to teach management: how to do evals, how to develop taste about what to work on, how to context-switch, how to systematically write a really good PowerPoint skill or a really good daily-update-report skill for Claude.

Every manager is a prompt engineer. Now every IC is, too.

---

That's how I think about it. You don't get adoption by telling people to spend more time on Twitter. You get it by buying direct, spotlighting the believers, giving people paid time to build, setting goals that force AI use, wiring up their meeting memory, mapping the work, and then training them to manage.

If you do that, they don't need to follow AI Twitter. They'll feel it in their own throughput.

---
*Notes on sources & assumptions: The X posts linked in the prompt were inaccessible at writing time, so I used the learnings list and Sam Parr paraphrase from prompt.md. The Every Consulting / Natalia post referenced in the prompt was not present in the workspace (only prompt.md, sample.md, transcript.md), so no names or internal Every programs are cited beyond the transcript. Transcript typos corrected (e.g. "Mobile Direct" -> "model direct", "cloud/code code" -> "Claude / Claude Code", "Boris Cheney / Cold Code" -> Boris Cherny / Claude Code). Voice modeled on sample.md (The Ultimate Guide to Prompt Engineering).*