AI transformation is happening unevenly.
Some teams are moving fast. They’re experimenting with new tools, redesigning workflows, building agents, and changing what a small group of people can accomplish. Other teams aren’t, and when leaders run into that second group, it’s tempting to explain the difference with a simple diagnosis: “They’re resistant to AI.”
Sometimes that’s true. People can be resistant to change. But I don’t think it’s a particularly useful conclusion for a leader.
Extreme Ownership, by Jocko Willink and Leif Babin, has been one of the most influential books on how I think about leadership. Its central premise is simple: leaders own the outcome. When a team isn’t succeeding, you don’t get to stop at “the team isn’t executing.” You ask why.
Was the mission clear? Do they understand why it matters? Have they seen what good looks like? Do they have the right tools and training? Have we given them permission to experiment? Are our incentives actually aligned with the behavior we’re asking for?
AI transformation should be approached the same way. So when I hear that a team is resistant to AI, the question I find more interesting isn’t “Why won’t they adopt AI?” It’s this one:
“What conditions have we created that make not adopting AI the rational behavior?”
Once leadership owns the outcome, resistance stops being an excuse for why transformation isn’t happening. It becomes a problem to understand and solve.
Ownership moves the question to leadership
One chapter of Extreme Ownership, “No Bad Teams, Only Bad Leaders,” tells a story from SEAL training. Boat crews race each other through the surf, day after day. One crew kept winning. Another kept finishing last, and its leader blamed the team he’d been given. The instructors swapped the two leaders and changed nothing else. In the next race, the crew that had been losing won.
The people in the boat were the same. What changed was the person setting the standard for what the crew would accept.
I’m not suggesting that every stalled AI rollout comes down to one bad leader. The point is narrower. When adoption stalls, leadership owns the conditions that adoption depends on: access to tools that are actually approved, training on real work, permission to experiment, examples of what good use looks like, incentives that reward it, and enough clarity that people know what is being asked of them.
If people aren’t experimenting, don’t know where AI fits in their work, can’t figure out what the security policy allows, or suspect that productivity gains will cost them their jobs, those are conditions. Leadership owns addressing them.
That doesn’t remove anyone else’s responsibility. Individuals still own their work and their willingness to learn. But leadership can no longer use resistance as the complete explanation for failure.
Resistance isn’t the conclusion. It’s information.
Leaders have to use it before they can lead it
“Believe” argues that a leader has to understand and believe in the mission before they can lead others through it. If you don’t understand why the mission matters, you keep asking questions up the chain until you do.
For AI, this means something specific. A leader who asks their organization to change how it works, while their own work stays untouched, is asking people to take a risk the leader hasn’t taken. Teams notice.
Leaders don’t need to become AI engineers. They do need firsthand experience of what these tools are good at, where they fail, how a workflow actually changes when AI is part of it, and why the change is worth the disruption. Without that, “we’re going to become an AI-first company” is an announcement. It doesn’t tell anyone what to do differently. It’s hard to explain the purpose of something you haven’t used, and it’s harder to tell a promising plan from an overconfident one.
You can’t effectively lead a transformation you don’t understand yourself. This is the reason our AI executive coaching has leaders build real tools on their own work before they set direction for anyone else.
Give teams a mission they can execute
The chapter called “Simple” argues that plans and orders have to be clear enough for the people executing them to understand. Complexity compounds when things go wrong.
Most AI mandates fail this test. “Become AI-first,” “use AI wherever possible,” and “10x our productivity” all express ambition, but none of them tells a team what to do on Monday morning. People fill the gap with their own guesses, which usually means a few enthusiasts experimenting on their own and everyone else waiting for clearer instructions.
A simpler mission sounds more like this:
Find repetitive knowledge work in your team’s workflow. Redesign one process using AI. Keep a human accountable for the final result. Measure whether it improves speed, quality, or cost.
At the level of a single workflow, the change should fit in one line:
When X happens → use AI to do Y → a person verifies Z.
When a support ticket arrives, AI sorts it and attaches relevant past answers, and an agent approves the reply on anything sensitive. When a sales call ends, AI drafts the CRM update from the notes, and the rep confirms it. Each line names the trigger, what the tool does, and who is accountable for the result. “Use AI more” names none of those, which is why it isn’t an operating strategy.
Prove one workflow before planning twenty
“Prioritize and Execute” is the book’s answer to being overwhelmed: identify the highest-priority problem, put your effort there, then move to the next one. Trying to solve everything at once usually means solving nothing.
The AI equivalent of trying to solve everything at once is a roadmap with forty initiatives, a steering committee, and no single workflow that anyone can point to as better. The alternative is a smaller loop: find one painful workflow, change it, measure it, show the result, then move on to the next.
The first goal is evidence. To make that concrete, here is an illustrative example, not a result from a specific engagement: a team takes a reconciliation process that used to take two days and gets it to two hours. That number alone isn’t the evidence. You also need to know whether quality held, how much review effort the new process takes, and whether the people doing the work would choose to keep it. A two-hour process that needs a day of cleanup afterward hasn’t saved anything.
When the evidence is real, something useful happens. Other teams start asking how that team did it and whether they can do the same. Successful AI transformations create pull. Evangelism from the top tends to produce compliance. A working example from a peer team tends to produce questions, which is what you want.
This is how we run AI transformation work: we start from the outcomes a company wants, go through each function with its leader, and ship the first changes with the people who do the work before deciding what to expand.
Push decisions to the people closest to the work
“Decentralized Command” is where the book introduces commander’s intent. Leaders explain the purpose of the mission and the boundaries around it, and the people closest to the problem decide how to carry it out. No leader can direct every action, and an organization that waits for the leader to decide everything can only move as fast as one person’s calendar allows.
A central AI team can enable transformation, or it can become its newest bottleneck. If every use case needs central approval, the teams that know their workflows best spend their time filing requests and waiting. The central team ends up inventing use cases for work it doesn’t do.
The structure that works better is intent + capabilities + guardrails:
- Leadership defines the outcomes the organization is after and why they matter.
- Security and legal define the boundaries: which data can go where, which tools are approved, and what needs review before it ships.
- Platform and IT teams provide the capabilities: approved tools, access, and the infrastructure that makes the safe path the easy path.
- The teams doing the work redesign their own workflows inside those boundaries, without waiting for permission on each idea.
Each group still owns something. What changes is that no group sits in the path of every decision.
Make it everyone’s mission, not the AI team’s
“Cover and Move” makes the case that teams within a larger unit have to support each other toward the shared mission instead of optimizing for their own piece. One element moves while another covers it. A team that wins its own fight while the larger mission fails hasn’t won anything.
AI transformation breaks down the same way when it belongs to one group. Engineering waits on security to approve tools. Security waits on someone to explain what the tools are for. Business teams wait on IT to tell them what to do. Everyone has a reasonable explanation for why they’re blocked, and the transformation stalls in the gaps between them.
The AI or platform team’s job is to enable everyone else. Leaders across the organization, in sales, operations, finance, and support, keep ownership of whether their function actually changes. When transformation lives only in the AI team’s backlog, the rest of the company can watch it happen without changing how they work.
Check your incentives before you blame culture
Go back to the central question: what conditions make not adopting AI the rational behavior? Incentives are often where the answer is. Ask what happens to someone in your organization when they become more productive.
- If saving ten hours a week only earns someone ten more hours of work, why would they advertise the improvement?
- If a failed experiment can hurt a career and doing nothing is safe, why experiment?
- If managers are measured on utilization rather than outcomes, why would they automate the work that keeps their team busy?
- If people believe adoption means helping to eliminate their own jobs, why would they participate with enthusiasm?
Treat these as explanations to investigate, about your organization rather than your people. Look at the less dramatic ones too: a security policy nobody can interpret, tools that don’t connect to the systems people work in, managers who don’t use AI themselves, and no shared examples of what good use looks like.
People respond to the system leadership creates. If the system quietly punishes adoption, culture will look like resistance.
Hold the tensions instead of resolving them
The last chapter of Extreme Ownership is “Discipline Equals Freedom: The Dichotomy of Leadership,” and Willink and Babin later wrote a full book, The Dichotomy of Leadership, on the idea. Leadership requires balancing opposing forces: confident but not arrogant, aggressive but not reckless, leading but willing to follow. Lean too far either way and things break.
AI transformation is full of these:
- Move fast, but manage risk.
- Standardize tools, but encourage experimentation.
- Automate aggressively, but keep a person accountable for the result.
- Drive the transformation from leadership, but decentralize how it’s carried out.
- Create urgency, but give people room to learn.
- Expect adoption, but leave room for skepticism.
No policy eliminates these tensions. A policy that only standardizes kills the experimentation that finds the best workflows. A policy that only encourages experimentation leaves security and quality to chance. Managing the tension, case by case, as the organization learns, is the leadership work.
The loop: own, believe, simplify, demonstrate, decentralize, learn
Put together, the sections above form a loop. The principles are Willink and Babin’s. The loop is our application of them to AI adoption:
Own → Believe → Simplify → Demonstrate → Decentralize → Learn ↻
- Own. Leadership owns the conditions adoption depends on, from access and training to incentives and permission.
- Believe. Leaders use the tools themselves, so they can explain the purpose and recognize the limits.
- Simplify. Teams get a mission they can execute, with a person accountable for every result.
- Demonstrate. One measured workflow, shown to peers, creates pull that announcements don’t.
- Decentralize. The people closest to the work redesign it, inside boundaries leadership and security set.
- Learn. Debrief what worked and what didn’t, spread the workflows that held, update the guardrails, and go around again.
The last step is the easiest to skip, and a team that doesn’t examine its results tends to repeat its mistakes. For AI, learning can change any earlier step. A debrief might show that the mission was still too vague, that a guardrail was blocking safe work, or that the outcome you started with was the wrong one.
So go back to the diagnosis from the start: “Our people are resistant to AI.” Maybe they are. But a leader’s analysis can’t stop there. What haven’t they seen yet? What don’t they understand about why this matters? Which incentives work against the mission? What risks have they been asked to take on their own? What permission are they still waiting for? What are their leaders modeling?
You don’t own whether someone loves AI. You do own whether you’ve built an organization capable of adapting to it.
If your rollout has stalled
If you’re leading an AI transformation that has stalled in one part of the company, start with one workflow. Walk us through it: what the work looks like today, where AI was supposed to help, and what’s getting in the way. We’ll tell you what we’d look at first to get a measurable first win, and whether we’re the right people to help.
If the gap is closer to home, and you want firsthand experience before you set direction, AI executive coaching is built for that. If you’re ready to work through the company function by function, see how we approach AI transformation.
