"Use More AI" Is Not a Plan

Published November 11, 2026

A Field Guide entry in “AI-Native Ways of Working.”

A lot of leaders have told their organizations to use more AI. Many of them have used it only a little themselves, or not at all, and the instruction usually arrives with nothing else attached: nothing about what the use is for, how long the budget will last, or what kinds of problems people should point it at. I'm already seeing what comes next. Some of the organizations that pushed hardest are pulling back, because they spent far more money than they expected and never had a plan for what the spending was supposed to produce.

Uber is one of the companies that pulled back on spending. The Information reported that people there had been encouraged to use AI as much as possible and were ranked on internal leaderboards by how much they used, and that the company's AI budget for the whole year was gone in about four months. After that, Uber capped every employee at $1,500 a month for each AI coding tool, which the company confirmed to Bloomberg in June 2026. Uber didn't stop using AI, and the company has said people can go over the cap with permission.

I don't think spending heavily at the start is a mistake, and if a leader's first goal is to explore, I'd coach them to do that. I'd also have that leader say on the first day how long the high limits will last, so that people are expecting the cap when it arrives. But if you rank people by how much they use, using more is what you've asked of them.

If you have already told your organization to use more AI, ask a few of the people who heard it what the plan is. I'd expect a lot of them can't tell you. As of May 2026, Gallup found that 47% of U.S. employees said their organization had adopted AI tools, and 25% of U.S. employees said their organization had shared a clear plan for fitting AI into the way it already works.

If they can't, tell them the plan. To write a good plan, though, you have to have used AI past the beginner level yourself.

Three kinds of sponsor

I've watched this happen with other changes. In eighteen years of agile, lean and DevOps work I've seen three kinds of sponsor. The partner helps people understand what the change means and works it out with them, so when part of it doesn't fit the team, they talk about it and adjust.

The bystander says the right words and lets everything carry on as before, until the change is a checkbox that nobody follows. The team gets new terminology while the work still has to be done the old way, and when the new practice comes up, the bystander says something like “this doesn't matter that much” or “we're not going to do that.”

The enforcer keeps the change alive and makes it worse. I always picture the CEO who read the executive summary of a Harvard Business Review article on the plane and shows up at work the next morning saying we have to do this. They didn't read the whole article, let alone anything else about it, but they believe they understand it well, and so the rule becomes “this is what the framework says,” whether or not it fits the company, the work or the people. The framework might be the Spotify model, or Scaled Agile, or Scrum. People go along with it without really buying in, so the change does less good than it could have. Even Spotify never fully used the Spotify model, according to Jeremiah Lee, who wrote in 2020 about his time there, and other companies were making their teams follow it anyway.

With AI, the enforcer is the leader who has had AI write a status deck and now tells the whole company to use more of it.

What leaders do with AI themselves

Leaders don't say much about how they use AI in their own work, so I can only go on what I see. What I see is leaders using it at a beginner's level. They have it write a status deck or manage their calendar, or they point it at their email and ask it in chat what's going on. They ask for a document and expect one to come back. All of that is useful, but it doesn't teach them much about how these systems work, how to give an AI the background it needs to do a job well, or how to build a tool of their own that keeps working after the chat is closed.

The things I hear leaders get most excited about are at the same level. Someone took a spreadsheet and now manages it with AI. A long, awkward process that people used to run by hand got a little AI added and went from three hours to thirty minutes, and everybody is thrilled. Those are real gains. They are also the first and most obvious things anyone does with AI, and there is a lot more past them that a leader who stops there never sees.

I know what a leader can't see from the chat window because I couldn't see it either. When I started, whichever assistant I was using, I kept a session open and treated it as the place where the information lived and the work got done. I don't work that way anymore. Take a weekly status report. The first few times, I work through it with the agent and give it several rounds of feedback. What I want now is for the agent to write that feedback down as we go, as templates and rules saved in files I own, so the next report starts from everything I said about the last one. A leader who has only used the chat has no reason to think about any of that, and the decision that follows is “everyone use this one product.” If the company later wants to change vendors, or someone has to hand their work to a colleague, what they built is sitting in a chat history that belongs to somebody else.

Those files are ordinary documents in a folder I control, such as a report template and a page of written rules, and other AI products can read them too.

What to say in place of “use more AI”

If you are about to tell your organization to use more AI, I'd coach you to write the plan down first and tell people all of it. If you want people to explore, say so, give them high budgets to begin with, and tell them you know it will cost a lot. Then tell them how many months the higher spending limits will last, that the limits will come down gradually after that, and that anyone who needs more will have a way to request an increase.

Many people who are told to use AI and figure it out take their normal job and do pieces of it with AI, and a lot of the ones I've seen stop when they don't get the result they wanted right away. Technical people tend to run with a mandate like that, while many others don't know how to start or what is possible. So tell people what kinds of things to experiment with and what kinds of problems you would like them to solve.

A training session on using the assistant to check your email will get people started, but it also limits them, and they get less creative about what else the assistant could do. People go further when you show them creative uses, like a tedious chore a colleague no longer has to do.

Ask in both directions

A partner sponsoring AI asks people what problems they are facing, whether AI could help, and who wants to take those problems on. The same partner asks what people are already using AI for, what they have solved, and how and why they did it. Most leaders I've seen do only one of the two.

When I've seen leaders ask what people are already doing with AI, it has often been as a show-and-tell. They give people access and set up a session where everyone shows what they are using it for, and thirty people come. Each use is specific to the person who built it, so most of the room isn't interested, even when the work is valuable. The leader in the room has one thing on their mind, perhaps a sales spreadsheet full of estimates. When someone says “I automated this spreadsheet,” the leader lights up and stops listening to everyone else. If you run a session like that, ask about the work that has nothing to do with your own problems.

Ten people in that room may be building similar tools, each one a little different. The leader who called the session should pull them together, because otherwise the company pays for the same work ten times.

The case against asking leaders to build anything

I am asking leaders to build something of their own with AI, even if it is only a weekly report. Plenty of good leaders would tell me that isn't their job.

They would say that nobody wrote code to sponsor DevOps, and that a leader's work is direction, funding and people, none of which requires building anything. Research on DevOps supports them. In 2017 the DORA research team, which studies software delivery, measured five leadership traits that, taken together, predicted high performance in technology teams. None of the five is technical skill, and the report describes good leaders as helping to build great teams “indirectly.”

Executive hours are scarce, and every hour a leader spends building something with AI is an hour away from leading. A leader with a strong technical person they trust can learn what they need from that person without building anything. The tools are also improving quickly enough that what a leader learns hands-on this year may soon be out of date.

I agree that setting direction and funding it is the leader's job, and a written plan with a budget and dates is that kind of work. I disagree about the comparison to DevOps, because with AI, using it and building something of your own with it is the only way I know to really understand how it works, what it can't do and what it is best for. A leader who hasn't learned some of that will ask for things that aren't possible, won't understand the costs, the risks or the trade-offs in what they approve, and will be guessing when they write the plan.

For weeks my own work went to my most expensive AI models when a cheaper one would have done, and I found out only by running out of usage far sooner than I should have. A tool I had built to track my to-dos and follow-ups told me it could record them, and when I tried it quickly it seemed to work. When I gave it a real message listing several follow-ups, it filed the whole list as one item. I found both problems only by using the tools on my own work.

Leaders may need to use AI themselves less and less as it gets more capable and more trustworthy. Once leaders can trust what they're told about AI's costs and limits without testing it themselves, the people who say leaders shouldn't build anything will be right.

An executive who stays curious, and who really listens to and trusts the people who know more, could do fine without building anything. The risk is that many leaders are surer of their understanding than they should be, and many of them, once they have an idea, don't want to hear no, or hear why the idea is wrong. The CEO on the plane could have asked someone who had read the whole article, but that CEO was too sure they already understood it to ask.

No study has tested whether leaders who use AI hands-on make better decisions about it. You learn little from hours with AI unless you check what it gives you. In two experiments published in 2026, people who solved logic problems with an AI chatbot scored better than people usually do and still overestimated their own scores, and the ones who knew more about AI were less accurate about how well they had done. The experiments didn't study executives, but I'd expect leaders to overestimate themselves too.

For leaders

The next time you're about to tell your organization to use more AI, write a page to go with the instruction. Say what the AI use is for, how long the high limits will last and what happens after that, and what kinds of problems you want people to go after. Then ask people regularly what problems they have and what they've already solved, and when they show you what they've built, notice whether you're only paying attention to the one that fixes your own problem.

You will write a better page once you have gone past the beginner level yourself. Pick a piece of your own work that repeats, have the AI save what it learns from your feedback as documents in a folder you control, and run it on the real work more than once. Check what comes back each time against what you know to be true, and watch what the work costs.

If someone on your team asked you this week what the plan is, what would you tell them?

This is one pattern from a set I'm working through on human-agent teams. It draws on my own hands-on R&D rather than a production deployment, and on eighteen years of organizational change work.

Back to Field Notes