The Moment You Spin Up an AX Team, You’ve Already Lost

That Uneasy Sense of Déjà Vu

The moment a company decides to “do AX” by spinning up a dedicated AX task force, it has already failed.

That may sound harsh. But if you think about it for a second, haven’t we all seen this movie before? The DX task force. The Cloud Migration Division. The Big Data Innovation Team. “We’ll stand up a team and roll this out company-wide.” How many times have we watched this? It was never going to work.

In part one I wrote that “installing Claude Code at your company doesn’t get you AX.” The diagnosis was that adoption and transformation are two different things. There was plenty of response, and the question that came back kept landing in the same place.

“So what should we actually do?”

I’m trying to answer that question this time.

According to MIT NANDA’s research, 95% of enterprise GenAI pilots fail. Ninety-five percent. Near total wipeout. And yet the successful 5% shared a clear pattern. They weren’t organizations led by a central AI lab. They were organizations where line managers on the ground drove adoption. The ones that survived weren’t the ones that built a separate AI unit. They were the ones where the existing operational teams moved on their own.

If I’m being honest, I’ve seen this many times, and I’ve built one of these myself. The task force. The transformation division. That was hypocrisy on my part. It didn’t work then. It won’t work now.

Why doesn’t it work? And what the hell are we supposed to do instead?

We’re Supposed to Flatten Layers. We’re Stacking Them.

The essence of AX is reducing layers. AI absorbs the middle of the work, shortening the distance between decision and execution. Creating an AX task force does the opposite. It adds one more layer on top of the existing ones.

The most dramatic case of this paradox is Coca-Cola’s Project Fizzion.

Coca-Cola, a 139-year-old consumer goods company, went all-in on an AI-driven transformation. They co-developed Project Fizzion with Adobe and simultaneously pushed hard on an AI-generated holiday ad experiment. One of the oldest brands in the world declared it would lead the AI era.

What came back from the field first wasn’t applause. It was pushback. The AI holiday ad drew heavy backlash. CEO James Quincey stepped down, saying in his own words, “someone with the energy to pursue a completely new transformation” was needed. Roughly 75 positions at the Atlanta headquarters were on the chopping block in the first round of restructuring.

The point here isn’t that one ad failed. It’s that a 139-year-old company pushed AX like a single project, and leadership plus the whole organization paid the price together.

By coincidence, around the same time, Australia’s largest bank, Commonwealth Bank, hit the same kind of wall. This one was more naked. They laid off 45 customer service staff on the assumption that an AI voice bot would cut call volume. In practice, call volume went up. Managers had to start taking calls. The bank publicly admitted the misjudgment and rehired all 45. They’d also rolled out GitHub Copilot, got mixed results, and eventually pulled it. The union called it a full reversal. It took a month.

The Pentagon’s CDAO was folded into R&E (Research and Engineering). The AI function that had been elevated as a standalone org was pulled back inside the research-and-engineering structure.

Coca-Cola, Commonwealth Bank, and the Pentagon are in different industries and sizes. What they have in common is that standalone AI units or central task forces either didn’t work as hoped, or had to be redone.

Funny thing: Fortune reported in March 2026 that 76% of AI projects led by CFOs delivered “great value.” And yet only 2% of companies had given the CFO an AI role.

Put those two numbers side by side and the paradox shows up. When the person who knows the reality of P&L and cost leads AI, the results land. But most organizations create a new title (CAIO) and hand it to a separate org.

Intel’s CAIO left for OpenAI after seven months. Seven months. His business cards hadn’t even worn out yet.

And this isn’t just a problem inside AI orgs. It’s telling that big-company CEO turnovers like Coca-Cola’s James Quincey and Walmart’s Doug McMillon are happening right as AI transformation enters its critical phase. AX isn’t a project where you bring in one tool. It shakes leadership and the entire org design. The moment you create a separate org, the rest of the organization treats AX as someone else’s problem.

That’s the core of the AX task-force paradox. You’re piling a new layer onto work that requires fewer layers, so it’s structurally bound to fail.

The Limits of Tool-Talk: This Isn’t an Efficiency Problem. It’s an Identity Problem.

A lot of today’s AX discourse stops at demoing tools like Claude Code or Copilot. Here’s what’s possible, isn’t it cool, you can do AX too. The people writing those posts include startup founders, solo developers, and consultants.

I get it. They need to survive too. Tool demos look good. They get strong reactions.

But corporate reality is different. It’s conservative and slow. And if you, as the person in charge of AX, catch yourself asking, “why aren’t they using this great thing?”, your AX is basically over.

The problem isn’t tools. It’s people. More precisely, it’s a question of how each person understands their own job.

People treat their role as their identity.

“I’m a product planner.”

“I’m a marketer.”

“I’m a backend engineer.”

What AX asks for is the dismantling of that identity. A significant chunk of my job gets taken over by AI, and I have to play a different role than before. This isn’t an efficiency problem. It’s an identity problem. You don’t solve that by giving someone a new tool.

Take a marketer with 15 years of experience. That person has built expertise in writing weekly reports, polishing campaign copy, and summarizing results. One day they watch AI produce a week’s worth of reports in three hours. What’s the feeling that comes up? “Cool”? No. For most people, a different feeling comes first.

“Then what am I?”

Backend engineers go through something similar. When an engineer watches AI plausibly replicate patterns they’ve spent years learning, they’re not just looking at a productivity tool. They’re re-examining the boundary of their own expertise. What moves a person at this point isn’t a better demo. It’s a structure that lets them sit with the anxiety and move into a new role.

That’s why AX is harder at the transformation step than at the adoption step. Adoption is a matter of buying a license. Transformation requires rebuilding a person’s identity.

This isn’t a problem for one company. Demos are everywhere, but almost no company tells its people what to do on the Monday after. “Sixty percent of your job will be automated” is the part companies are willing to say. “Here’s what you’re now accountable for in the remaining forty percent” is the part almost no one gets to. The first sentence is a tech story. The second is a human story. AX built around tools is doomed to fail.

We aren’t failing at AX because we don’t know the tools. We’re failing because we don’t know the people and the org.

People Who Don’t Understand an Organization Can’t Change One

Steve Jobs, in his 1992 MIT talk, criticized consultants. His point was that people who don’t own the outcome and don’t own the execution produce only a tiny sliver of the value. It was a fundamental distrust of trying to change an organization from the outside.

I agree with that almost 100 percent. My situation was a little unusual, though. I was with them every day, functioning like I was already half-inside the organization. Most consulting doesn’t work that way. So mine was closer to an exception.

This is the first time I’m telling this story publicly.

I started as a consultant. A company asked me to audit their engineering organization. Four evenings a week, three hours at a time, I’d go to the office. After leaving my own job, I’d clock in at another company. It was called consulting, but really it was three hours every evening reading the codebase, joining meetings, and talking to the people.

The two engineers I worked with in those first sessions were effectively forced into overtime because of my consulting. With those two, night after night, we read code, debated architecture, and talked through the organization’s problems.

Over the course of a month, I got to understand the organization deeply. The state of the codebase, where technical debt sat, the bottlenecks between teams, people’s skills and frustrations and ambitions. A month sounds short. But four nights a week, three hours a night, for a month is almost fifty hours.

Along the way, I found myself wanting more. The scope was past anything a consulting engagement could finish. From the outside, by advice alone, some things were never going to change.

It wasn’t that I understood the backend architecture or the business deeply enough to make that call.

What mattered to me was who I’d be working with. The tech stack was made of technologies I’d never used. Node.js (I’d gone from Ruby and Python into a heavy Go phase, and had never handled Node.js in production) and Kafka, which was the consulting engagement’s main project, were both new to me. On technical grounds alone, there was no reason to join.

But after a month of meeting the same people every evening (those two engineers, and the other members of their team), I felt convinced that together we could change something.

Tech, you can learn. Domain, you can dig into. But if you don’t have the people to work with, nothing happens.

So I joined as CTO.

What I took away from that experience is one thing. To change an organization, you first have to understand it. And to understand it, you have to spend time. Throwing a framework over the wall from outside never works. Only after putting in three hours a night, touching the code, the people, and the culture directly, could I see what was broken and where to start.

Even that turned out to be nothing. Once I went full-time, problems that had been invisible during the consulting phase piled up like a mountain. From the org structure to server operations, for the first few months I was fighting several fires at once and almost never left on time.

AX is the same. Handing people an AI tool and saying “there, go do AX” doesn’t land. You have to carve a small piece off a new business unit or an existing team and experiment. And that experiment isn’t an experiment with the tool. It’s an experiment with how work gets done. The person leading that experiment has to know the organization’s people.

Giving advice is easy. Owning the outcome of that advice all the way through is a completely different thing.

That’s why I keep circling back to people whenever I talk about AX.

Reading Jack Dorsey’s piece “From Hierarchy to Intelligence,” one line stuck with me. Hierarchy was originally not a structure for managing people but a structure for routing information. From Roman armies to railroad companies to modern enterprises, organizations have always solved the same problem. Who knows what, who gets that information next, and who makes the decision? The layers we’ve accepted as given (team lead, director, department head, PM, middle manager) exist because they paid the cost of moving information around.

Seen through that lens, the nature of what’s happening now looks different. AI doesn’t just do work faster. The human middle layer whose job was to collect, summarize, tidy, and pass along information is itself being shaken. Before, the organization only worked if a person reported up, coordinated sideways, and cascaded down. Now AI takes part of that. It reads documents, drafts, organizes context, summarizes data. At that moment hierarchy stops being strictly necessary. In some cases, it becomes the thing that slows you down.

Most companies stop here. They attach an AI copilot to the existing org. Documents get written faster, meeting notes get tidied faster, reports come out faster. They leave the structure as it is and run it slightly better. There’s value in that. But Jack Dorsey’s question goes deeper. Do you want to run the company more efficiently, or do you want to redesign how the company runs? The first is automation. The second is org redesign. The distinction I keep making in this post is exactly that.

Reframed this way, everything I’ve said so far ties together on one line. Setting up an AX task force is adding a layer at the exact moment you need fewer layers. The reason people feel anxious is that the information-passing and coordination role they used to hold is shifting. The reason I spent a month reading the organization before joining as CTO was the same. An organizational problem is less about individual skill and more about how information flows and who owns what. If you can’t read that flow, you can’t change the org.

So the next question follows naturally. Does an AI-era organization need more layers, or does it need fewer handoffs and clearer ownership? The answer is already in the room, from where I sit. As people shift from being couriers to being decision-makers, teams get smaller, and ownership has to carry all the way to the end. At that point, AX becomes a story about End-to-End.

AX Ends Up as End-to-End

In part one I broke the organization down into five axes, and I named the most important one as the End-to-End Ownership Team. A structure where a single team owns Discovery (what to build), Delivery (how to build), and Distribution (how to sell) from end to end.

For readers who skipped part one, one more sentence. This isn’t an argument for a do-everything solo company. It’s an argument for a structure where ownership doesn’t break in the middle. A structure where you can always tell who defined the problem, who built it, and who saw it through.

What AI changed is simple. One person’s coverage. AI helps with the product spec, the code, and the data analysis. Work that used to require three teams ping-ponging can now be handled by a much smaller team. The need for division of labor itself has dropped.

What Abnormal Security’s CEO Evan Reiser calls “The Projection Problem” captures this well. Ideas are high-dimensional; language is low-dimensional. Every time the expert explains it to the PM, the PM writes the spec, and the engineer implements it, every handoff is lossy compression. Everyone looks at the same shadow and says “we’re aligned,” but they might be imagining different products. To fix that, Reiser put a CISO with 20 years of experience directly in the product owner seat and built a structure where AI interviews what’s in his head. Expert to AI. One handoff. The cleanest explanation of why End-to-End matters.

So the direction of AX naturally leads to End-to-End. Smaller teams. Shorter handoffs. Clearer ownership.

This might sound like an empty slogan. But organizations are already moving this way.

Lumen Technologies took a more fundamental approach. A 30-year-old legacy telco. What CEO Kate Johnson (formerly at Microsoft) did wasn’t deploy a tool. She redefined the company’s identity. From “legacy telco” to “the backbone of the AI economy.”

After piloting Microsoft 365 Copilot (a work AI assistant, different from GitHub Copilot) with the sales team, she rolled it out to the whole company, and used a “champion program” to assign AI evangelists in each department. The numbers are striking. Customer research that used to take a salesperson 4 hours dropped to 15 minutes. Across a 3,000-plus sales org, they saved an average of 4 hours per week, which over 12 months translated to $50M in revenue value.

JPMorgan Chase went deeper. The company treats AI not as a subtopic inside the tech department but as a core executive agenda. In practice, JPMorgan has seated CDAO (Chief Data & Analytics Officer) Teresa Heitsenrether on the Operating Committee. AI isn’t cordoned off into a separate org. It’s at the core decision-making table.

Walmart is moving in a similar direction. The company is consolidating fragmented AI capabilities into four super agents for customers, employees, partners, and developers. Then–Walmart U.S. CEO John Furner said at Fortune Brainstorm Tech, “Headcount in two to five years will be roughly the same as today.” The meaning is simple. AI will raise productivity, but they won’t turn that directly into headcount reduction. They’re going to run a bigger business with the same-size org and change what people actually do. That’s closer to a declaration than a prediction.

Lumen (telecom), JPMorgan (finance), and Walmart (retail). What they have in common is that they did not build a separate AX team. They’re directly changing the roles and structure of the existing organization.

The Maker vs. Closer distinction I drew in part one lives in the same context. The point wasn’t to add more people who only produce output. It was to add more people who carry work through to completion. MyRealTrip CEO Donggun Lee’s pivot (“grow the number of people who can sell directly” over “make it better”) lives on the same line. It’s a declaration that the wall between engineering and marketing, between product and sales, has to come down.

Before, getting past that wall meant filing a request with another team. You had to wait for assets, explain yourself, and justify the ask. That’s different now. An engineer can draft ad copy with AI, classify customer feedback, and even do basic data analysis on their own.

One more step in: this isn’t an argument for making engineers do sales. It’s an argument for letting engineers hear the customer’s voice directly, fold that feedback into the next sprint, and see the business impact of what they shipped in actual numbers. Same for marketers. Since AI can draft a product brief, marketers get more time for judgment calls about product direction. The energy that used to go into “when is the engineering team going to get to this?” can now go into “what does the customer actually need?”

This isn’t saying everyone should do everything. It’s saying that the wall you used to book a conference room to get past is lower now.

At that point the Maker becomes a Closer. The distinction I drew in part one is turning from an abstract concept into a real state. Someone who only produced output becomes someone who carries a result to the end. That’s what the individual-level transformation inside an AX organization actually looks like.

Where AX works, you find small teams organized around problems, not around job titles. Teams that own End-to-End. Teams with minimal handoffs. Teams where one group handles it from Discovery to Distribution. The goal isn’t a separate “AX task force.” It’s a structure where each existing team becomes AX on its own.

Don’t push the tool. Let the need pull the tool in.

When Layers Disappear, Roles Shift

Same organization, but this time we look at how individual roles change rather than at structure.

Lots of people see AX as IT’s job. The engineering team uses AI, designers write code, PMs run agents. Those changes matter.

But real AX happens outside of IT, in the field.

A recent example from the OpenAI Codex team shows this clearly. On that team, designers write code themselves, PMs work as builder-owners instead of messengers, and engineers focus on supervising the system rather than writing code line by line. You could say “well, that’s an AI company’s engineering team.” But the principle is general.

“Designers become builders. PMs become owners. Engineers become supervisors.” That principle doesn’t only apply to an AI company’s engineering team. It’s a universal pattern for an era in which role boundaries are being redefined, across every industry.

Look at retail. A store operations lead at Walmart isn’t just someone who files requests to headquarters anymore. They’re handling inventory, promotions, and customer signals directly in a much shorter loop. What the AI system created isn’t a fancy dashboard. It expanded the radius of judgment on the ground. Target too. The Enterprise Acceleration Office exists to raise enterprise-wide speed and agility. The goal is to shorten the distance between decision and execution in the stores.

Finance is even more dramatic. Bank of America’s Erica has handled over 3.2 billion cumulative interactions, and more than 98% of users find what they need. The real point isn’t the number. What Bank of America actually did was build Erica for consumers first, then reuse the same engine for employees, wealth management, and corporate banking. “Build Once, Reuse.” It’s a strategy of spreading one engine across the whole organization.

What did that change on the ground? Advisory, underwriting, and operations stopped being three teams passing documents around. They got closer to the customer’s problem and saw it through. With the AI handling repetitive queries, advisors got room to go deeper into complex financial problems. Underwriters gained the same kind of space. Time that went into document verification now goes into actual risk judgment.

The Bank of America CIO’s line is worth sitting with. “The discipline of slowing down early produces much faster acceleration over the long run.” Organizations racing to deploy tools should probably hear that one first.

Telecom tells the same story. At Lumen Technologies, salespeople cut four-hour research down to fifteen minutes and spent the rest of the time in deeper customer conversations. Before, gathering pre-meeting material ate up half a day. Now, fifteen minutes is enough to pull together industry trends, prior contracts, and likely needs for the customer. The salesperson’s role shifted from “material collector” to “customer problem-solver.”

Manufacturing is no exception. The UAE’s Emirates Global Aluminium (EGA) built a cross-functional execution model under its CDO (Chief Digital Officer) and retrained more than 3,000 employees. In 2025 it was named a WEF (World Economic Forum) Industry 4.0 Global Lighthouse. A first for the aluminum industry.

A common pattern shows up here.

In retail, in finance, and in telecom, jobs don’t disappear. The center of gravity of the job moves. From reporting to judgment. From passing things along to executing. From collecting to interpreting.

The point isn’t to teach everyone to code.

The point is letting each person keep their expertise while gaining a wider radius of judgment and execution. Someone who only reported now also executes one step further. Someone who only executed now also judges one step further. Someone who only judged now also carries the result through to the end.

This isn’t proprietary to tech companies. It’s an operating model that every existing organization has to translate into its own language.

A good AX team’s role converges here, too. Not promoting tools, but making these role transitions actually happen.

What Bank of America shows is that the transition doesn’t happen overnight. After launching Erica in 2018, it took seven years to extend it to employees and wealth management. But once the plumbing is in, it gets reused again and again. Better to lay it slowly and use it for a long time than lay it fast and watch it collapse.

More Tools Is Not the Same as Winning

A lot of organizations trip over this next part.

Once a company declares it’s doing AX, people start showing up with their own little tools. Non-engineers build small automations with Claude Code. They wire up agents to summarize reports, classify customer inquiries, and tidy meeting notes. Some even ship apps. At first it’s heartwarming. The feeling is, “Our organization is finally changing.”

That scene is genuinely moving. A non-engineer attaches an agent to their own work and makes something, however small. From the org’s point of view, it’s a good signal. At least the psychological resistance isn’t completely closed off.

But is that really AX?

Has AX actually taken hold in the organization?

Does personal work automation genuinely contribute to the organization’s performance?

Usually, no.

Because in most cases, the tool reduces friction at the individual level without touching the organization’s bottleneck.

A marketer can build a tool that generates their weekly report faster. A CS rep can hook up a bot that drafts replies faster. A finance person can write a script that makes reconciliation spreadsheets less painful. All fine. All productive.

But that’s not how a company wins.

A company wins not when individuals finish their own work a bit faster, but when the whole organization moves faster in the same direction. If personal automation doesn’t connect to organizational wins, it’s just another tool on the pile.

I’d call this local optimization at the individual level. The friction on your desk is lower. Your calendar has a little more room. But cross-team approvals are still stuck, priority conflicts are still unresolved, and the lack of goal alignment is untouched. The organization still slows down at the same places.

There’s a worse version. Once everyone starts making their own tools, the org gets more fragmented, not less. Even within one marketing team, A uses her own GPT, B uses a Claude project, C wires together Zapier and Notion. Engineering has its own agent workflows. On the surface, everyone looks innovative. But there’s no shared language, shared goal, or shared operating principle.

The tools multiply. The organization fits together worse.

That’s not AX. That’s “every person for themselves,” but more sophisticated.

At this point I find myself pulled back to a previous post, An Organization That Can’t Win Has No Future. The core of that piece was simple. If an organization can’t define what winning means, the way it works loses meaning. Effort without direction can be comforting, but it won’t become results.

Same for AX.

Changing how you work without aligning the organization’s goals is just adding one more tool to the stack.

The problem starts here. AX discourse too easily mistakes “tool utilization rate” for performance. How many people use agents internally, how many automations have been built, how many demo days have been held. Those are activity metrics. They are not outcome metrics.

The real questions are these.

• Did time-to-customer go down?
• Are we making better decisions faster?
• Are we closer to the organization’s winning conditions?

If the answer is unclear, the organization’s AX is still at the toy stage.

Here’s the distinction.

The left column is great for internal slide decks. Measuring real AX means looking at the right column.

I’d argue the leader has to get colder, not warmer, the moment employees start building their own tools. Don’t just applaud. Check where those tools are reducing friction, whether they expose a common bottleneck, and whether they contribute to the organization’s core value flow. An organization that cleanly removes one shared bottleneck is much closer to AX than an organization with twenty scattered personal tools.

Personal automation can be a signal. It’s not evidence.

Signals are welcome. Evidence is different.

The evidence of AX is always the same. Shorter processing time, fewer handoffs, clearer ownership, and most of all, a contribution to the whole organization’s business performance.

Miss that, and the org collapses the same way it always did, even in the AI era. Just with more tools.

So You’ve Already Set Up an AX Team. Now What.

Reality is reality. Plenty of organizations have already stood up an AX team. Leadership made the call, a team got assembled, and a mission was handed down. How, then, do you at least raise the odds of it working?

Think back to a previous organization. When introducing a new process, the most effective move wasn’t importing an outside expert. It was pulling in the person on each team who had the most complaints and who also knew the work best.

Those aces knew the real bottlenecks. People with the most complaints know best what’s wrong. People who know the work know what actually has to change for things to move.

An AX team has to start from there.

What an AX team needs isn’t an AI expert. You need the marketer who knows where marketing’s bottleneck is, the engineer who knows the real problems in the dev pipeline, the CS lead who knows where things break at the customer touchpoint. Those people come together and redesign how work is done in their own context, using AI as a tool, not the other way around.

The reason this matters is that an AX team that doesn’t know the field almost always turns into an “AI PR team.” They run internal seminars, introduce tools, and translate success stories. It looks legit. But the actual bottlenecks on the ground stay right where they were.

Order is everything. Most organizations run this order backwards. First they install the tool, then they think about where to use it. Nothing ends up planted deeply anywhere.

The mission also gets set wrong. “Drive AI adoption” isn’t a mission. It’s a slogan. The mission has to be a concrete business problem. Cut new customer onboarding time by 50%. Double customer inquiry resolution speed. Bring monthly report generation from 8 hours down to 2. That kind of thing. Then the team looks at processes, not tools.

It was the same in a previous org. When we moved from an abstract mission like “improve software quality” to a concrete one (“count issues and reduce them every week”), the team finally moved. We counted issues, tidied them, prioritized them, and focused on bringing the number down. This wasn’t only a developer’s job. PMs, QA, and designers all lined up on the same issue pipeline, which is why it worked. AI didn’t solve it. Looking at the same number and moving in the same direction did.

The more concrete the mission, the more the team looks at boring bottlenecks over flashy demos. Most of the time, real impact comes out of those boring bottlenecks.

There’s another trap here. Many organizations frame the mission as “reach 80% AI tool adoption.” The number is concrete. The direction is wrong. Utilization rate is an activity metric. It says nothing about which bottleneck gets fixed or which value flow it serves.

A proper mission looks like this. “Cut first-response time on customer inquiries from 24 hours to 4. AI is an assist; final accountability sits with the dedicated team.” This mission doesn’t force tool usage. It nails down the result and the ownership structure. The tool is just a means.

People don’t move on mission alone. They need to see the reason their role is changing and the path forward.

ServiceNow assessed all 28,000 of its employees. What matters isn’t the assessment itself. They had to redraw who could move into which role after AI, who needed what kind of training, and who was currently stuck in repetitive work. People aren’t afraid of AI itself. They’re afraid of being useless in an AI era. That’s why redrawing the role map comes first. You have to know exactly what someone can do now before you can design what they’ll learn next.

The AX team’s job is not tool evangelism. It’s laying the runway that lets people learn, switch roles, and run experiments in the field.

Execution authority doesn’t have to be grand. You don’t need sweeping org redesign power. You just need the authority to run tiny experiments. Skip one approval step. Try a different way to classify customer inquiries for two weeks. Put one specific report through an AI assist. If it doesn’t work, roll back. Without that much authority, AX lives and dies as a deck. With even that much, the organization actually learns something.

No experimentation authority, no innovation. That was it.

AX teams are the same. “Do it this way” has to become “we’ll try it ourselves first.” And then you have to show the result. In numbers. Successful experiments get handed off to the field. Failed experiments get logged so the next team makes fewer mistakes. What matters is that the result doesn’t stay inside the AX team. It becomes organizational learning.

In the end, an AX team’s success depends on its goal being its own disappearance. Once each field organization can run its own AX, a separate AX team is redundant.

A team whose reason for existing is to stop existing.

It’s paradoxical, but it’s the only design that works.

Walmart redesigned the org. Bank of America laid the plumbing. Lumen redefined identity. Commonwealth Bank reversed course.

The results are already in.

Closing

The first principle of AX isn’t tools. It’s the organization and its people.

Understanding AI matters. Knowing Claude Code matters. But before that, you have to understand the people in the organization that’s going to use the tool. Why they work the way they do. What drains them. What has to change for them to actually move.

At the end of understanding people lies direction. If the organization can’t define a direction, no matter how great the tool, people run toward different places. As I wrote before, effort without direction can be comforting, but it won’t become results.

The more an organization wants to be good at AX, the more sharply it has to ask itself: what are we trying to win here.

I invested three hours every evening to understand that organization. That was all I could do. Not a framework, not a toolkit. Just sitting in the office at night reading code and talking to people. Nothing glamorous.

But that was the real thing. People who know tools stay with tools. People who know people change organizations.

“If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.”

Antoine de Saint-Exupéry

References

1. MIT NANDA, “95% of GenAI Pilots Failing: What the Successful 5% Do Differently”
2. Fortune, “Why CFOs, not CAIOs, Are the Secret to AI Value”
3. CNBC, “Coca-Cola, Walmart CEOs Step Down amid AI Shift”
4. Ads of the World, “Coca-Cola: Designers Lead. AI follows.”
5. The Verge, “Coca-Cola’s new AI holiday ad is a sloppy eyesore”
6. CBS Atlanta, “Coca-Cola plans to cut about 75 jobs at its Atlanta headquarters in early 2026”
7. The Register, “Commonwealth Bank AI Chatbot Fail: 45 Rehired”
8. Walmart Tech, “All in on Agents”
9. Fortune, “Why Walmart’s CEO says AI won’t lead to lower headcount”
10. Microsoft, “How Copilot Is Helping Propel an Evolution at Lumen Technologies”
11. Fortune, “Inside Bank of America’s Build Once AI Strategy”
12. Bloomberg, “Intel CAIO Leaves for OpenAI after 7 Months”
13. Defense Scoop, “Feinberg orders major shakeup in Pentagon’s AI enterprise”
14. CloudWars, “ServiceNow: 28,000 Employees Assessed for AI Skills”
15. SalesforceBen, “Salesforce Lays Off Nearly 1,000 Employees in Early 2026”
16. CNBC, “JPMorgan CEO Jamie Dimon: AI Is Reshaping Workforce”
17. JPMorgan Chase, “Teresa Heitsenrether”
18. EGA, “EGA Designated Industry 4.0 Global Lighthouse by WEF”
19. Evan Reiser, “The Projection Problem”
20. flowkater.io, “Installing Claude Code at Your Company Doesn’t Get You AX”
21. Target, “Enterprise Acceleration Office”
22. Block, “From Hierarchy to Intelligence”
23. YouTube / Peter Yang, “How OpenAI’s Codex Team Builds with Codex”
24. flowkater.io, “An Organization That Can’t Win Has No Future”