# Raise the Ceiling, Not the Floor

*Seven things I've learned about getting teams to actually use AI, from my first few months running tech consulting at Every*

Sam Parr asked a question on X recently that I've heard, in one form or another, from almost every company I've walked into this year:

> "How is everyone getting team adoption for Claude? I spent a lot of time on Twitter, as do you. We see all this AI stuff popping up. We're on top of it, or at least sorta... 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?"

It's the right question. If you're reading this, you are by definition the person at your company who spends too much time on Twitter. You've seen the demos. You have the $200-a-month subscription. The problem is that you can't clone yourself, and the 40 people on your team have actual jobs to do that don't include "keep up with AI."

I recently joined Every as head of tech consulting, which means I now spend my days inside companies that bought the tools, told everyone to use them, and then watched nothing happen. I replied to Sam with a list of seven things that have actually moved the needle. Here they are in a bit more depth.

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

The first thing most companies do when they decide to "adopt AI" is run a vendor evaluation. They line up a dozen tools that all use Claude or Codex or Gemini under the hood, and they compare features. This is almost always a waste of time.

Every one of those tools has the provider's opinions baked into it: their hang-ups, their product decisions, their view of how your work should be done. Nine times out of ten it's quicker and easier to write a Claude skill that encodes *your* opinions and *your* way of working, and point it at the model directly. It's easier to configure, easier to operate, and you can change it on a Tuesday afternoon without waiting for a roadmap.

I don't see how the third-party tools keep up in the long run. The model companies know what releases are coming. They build their internal tools around those releases. They train the model itself on how to operate inside their own environment. I genuinely appreciate the effort a company like Cursor puts in, and they're a good product org, but I also don't know how you compete with Anthropic effectively handing you $5,000 worth of tokens a month for a $200 subscription.

There are exceptions, but as a general rule, third-party tools are less flexible, less cutting-edge, and more expensive. It's a real shift toward build, not buy.

## 2. Raise the ceiling, not the floor

The default corporate rollout goes something like: "We bought you AI tools. You all need to use AI now." Then leadership is surprised when three months later the usage dashboard is flat.

This doesn't work because for a lot of people, being told they *have* to use AI triggers something closer to self-preservation than curiosity. Even on pain of death, some of your team are just not emotionally ready to be told a machine can do their job. You can't mandate the aha moment. People have to get there on their own time.

What you can do is use the carrot rather than the stick. Instead of trying to drag the bottom of the distribution up to some minimum standard, find the people who are already AI-forward and remove every obstacle in their way. Every company has a few people quietly using Claude Code in their spare time. Get them out of the woodwork. Make it visible that this is encouraged. Give them the budget and the access they need.

Someone who is genuinely AI-pilled will get five or ten times more done than someone who hasn't seen the magic yet, so you get the productivity boost immediately, without having to convince anyone of anything. It is much easier to enable a believer than to convert a skeptic.

Then make the incentives legible. The people who use AI aggressively should be the ones who get promoted first and who get face time with senior management. We've even had success co-opting these people as TAs in the courses we run for the rest of the team. When their colleagues see that the TA is accomplishing more, getting ahead in their career, and sitting in meetings with leadership, that's a far more effective motivator than any mandate.

## 3. Workshops should be at least 50 percent build time

You should run workshops. But nobody wants to sit through two hours of slides on how transformers work. I didn't learn any of this from theory; I learned it by doing, and so will your team.

The single biggest complaint we hear in discovery is not "I don't believe in AI." It's "I don't have time." People don't have room in their day to check out a new tool, learn something unfamiliar, build something with it, and stretch themselves. So the workshop's real job is to *give them that time*, with permission attached.

Our format is a bit of guided theory to motivate the exercise, then the majority of the session is building. Everyone is expected to make something new, ideally outside their normal domain. The facilitator's job beforehand is to make sure the tool is set up, the connectors they need are working, and there's synthetic data ready to go so nobody spends 45 minutes on access requests. That's where the aha moment happens: not when they're watching, but when they're two hours in and the thing they didn't think they could build is sitting in front of them.

## 4. Assign impossible tasks

By "impossible," I mean tasks that simply couldn't be done without AI.

Boris Cherny, who created Claude Code, has said something similar: slightly under-resource most teams, and they'll work out for themselves that the only way to hit the target is to use AI. I like to make it more explicit and choose the tasks strategically.

If your goal is one blog post a week, you can do that manually, and you will. If your goal is one blog post a day, you're going to have to use AI heavily in research, drafting, and editing, and you'll have to think about *where* it fits. The task forces the question.

The important nuance is how you set the goal. You don't say, "Starting today, you're producing one a day." You say, "Our goal is to get to the point where you can produce one a day. What needs to happen for that to be true, and what's your progress toward it?" It might take a while. But once people know that's the destination, they start thinking strategically about how to get there and start experimenting on their own.

## 5. Mandatory AI note-taking, plus an MCP connector

This is a surprisingly big unlock, and it's cheap. Everyone on our consulting team has Granola and the Granola MCP, which means every meeting we've ever had is available to Claude as context.

What that looks like in practice: "We just had a meeting on X. Write an update email on that topic and send it to Y." Done. Or I'm putting together a proposal or a curriculum, I realize I need something a client said three weeks ago, and rather than digging through my notes I just pull it from the MCP.

If I'm honest, 80 to 90 percent of the value of AI in a business context comes down to one thing: extracting information from unstructured data and structuring it in a way that's useful. Meetings are the largest pile of unstructured data in most companies, and until recently they evaporated the moment they ended. Make note-taking mandatory, connect it to the model, and you've given every prompt your team writes a memory.

## 6. Map workflows and systematically automate them

Most AI adoption is ad hoc. Someone tries something, it works or it doesn't, and nobody writes it down. We take a more boring, and much more effective, approach.

We run a discovery call with each person or team: what do you do day to day, what tools do you use, where are the pain points? We turn that into a structured Google Sheet listing every task that needs solving. Then we work down the list, systematically, building a skill for each type of task.

The working assumption is that we're trying to take 100 percent of the work off the human. We won't get there. But if every task on the list at least gets a good first pass from a skill, that person can do five or ten times the throughput they do today.

You'd expect that to lead to layoffs. So far, it never has. What actually happens is one of two things: either the team puts far more effort into each task, or the team expands its throughput and revenue without hiring anyone new.

Here's an example of the first. When we used to run courses for a team, we'd prepare one exercise for the whole cohort, or at best one per pod. Now we use Claude Code to generate an individual project for each participant, based on their role and their data. That simply wasn't possible before. We're not using AI to do less work. We're using it to do work that wouldn't have been worth doing.

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

The last one is the one I think about most.

Every individual contributor is now a manager. They're managing a team of AI tools, and they've never had a day of management training. They're not used to context switching between five parallel tasks. They're not used to setting up systems and rules for someone else to follow. And they're really not used to evaluating work they didn't do themselves, and having to form a strong opinion about whether it's good.

The interesting thing is that actual managers adapt more readily than ICs once they have the aha moment. ICs enjoy the craft. They care how the problem gets solved. Managers, for the most part, got past that a long time ago; they just want the problem solved to spec. That mindset turns out to be exactly what working with agents requires.

The funny corollary is that managers are becoming individual contributors again, because they can often manage a team of agents more effectively than they can manage a team of humans. Briefing a human is lower bandwidth and has a longer feedback loop. By the time you've written up the prompt, you have a choice: send it to Claude and get the result in five minutes, or send it to a person, wait for them to send it to their Claude, and get the result in a couple of days. More and more, managers are just opening Claude Cowork and doing it themselves.

So companies need more management training, not less. Specifically, people need to be taught how to context switch, how to run evals, how to develop the taste to decide what's worth working on, and how to train the AI in specific skills: how do you systematically build a really good PowerPoint skill, or a really good daily update report skill? Those are management problems, and most of your team has never had to solve them.

Two years ago I wrote in this newsletter that every manager is a prompt engineer. The update is that every employee is now a manager. The companies pulling ahead aren't the ones that bought the most tools. They're the ones that realized adoption is a people problem, found their believers, gave them time and impossible goals, and taught everyone else how to delegate.

---

*Notes on this draft (not part of the post):*

- *Natalia's post on Every consulting was referenced in the brief but wasn't in the working folder, and web access is blocked in this environment, so I couldn't read it. The description of the consulting work is drawn only from your transcript. If her piece uses specific language for the offering or process, it may be worth aligning the intro and section six with it.*
- *The tweets are quoted from the text you pasted rather than fetched from X. The line "I recently joined Every as head of tech consulting" uses the title exactly as you gave it; adjust if the official title differs. No one else at Every is named, per your note.*
- *Transcription artifacts were corrected: "Mobile Direct" to "model direct," "cloud skill" to "Claude skill," "Boris Cheney, a vendor of Cold Code" to Boris Cherny, creator of Claude Code, and "Cloud Cowork" to Claude Cowork. Boris's point is paraphrased rather than quoted, since the transcript paraphrased it too.*
- *The "$5,000 worth of tokens for $200" figure and the "80 to 90 percent" and "five to ten times" claims are your estimates from the transcript, kept as-is.*