Why AI Adoption Has to Be an Executive-Sponsored Project

He will win whose army is animated by the same spirit throughout all its ranks.

— Sun Tzu, The Art of War, "Attack by Stratagem"

Start with a controlled comparison. The same AI adoption project, at two nearly identical companies, launched two different ways.

Company A had the technical department initiate the project: the proposal was tidy, the technology choices were sound. The project died in month four — the post-mortem traced the cause to needing sales-department data; the sales director's response was, this is your IT department's project, why would I grant you access.

Company B had its top executive initiate the project: at the kickoff meeting, the boss spent fifteen minutes explaining why this mattered to next year's business, and six months later the system was running inside the daily work of three departments.

The two companies' technical solutions were identical. The only difference: Company A's project had a good architect. Company B's project had someone who could mobilize the whole company with a signature.

The phrase "executive-sponsored project" has been worn smooth from overuse in China's enterprise software circles — enough that many practitioners flinch on reflex when they hear it. It sounds like a slogan for dodging blame: a project dies, and "there was no executive sponsorship" wraps the whole thing up. This chapter wants to restore those words from slogan back to structure: why is AI adoption almost inevitably an executive-sponsored project? What does the phrase actually mean? What does it look like when sponsorship is misapplied? And when doesn't it have to be the top executive at all?

I. The Cross-Departmental Problem

AI adoption has a trait other technology projects don't share: it is cross-departmental by nature.

Pull apart any real project and you'll find a map scattered across departments — data sits with Department A (customer information lives in the sales system, historical records with operations), process sits with Department B (the approval workflow that needs reworking belongs to finance), budget sits with Department C (the project has to clear the IT budget, but the benefit shows up on the business side's books), and benefit sits with Department D (the efficiency gains get recorded in the frontline team's own report).

Can a mid-level project owner command all four at once? Not easily — not even one of them. Data access needs Department A's sign-off; reworking the process needs Department B to give up some of its authority; budget ownership needs Department C to accept the bill; confirming the benefit needs Department D's cooperation on measurement — every single one of these is a cross-departmental negotiation, and a mid-level manager only has "negotiate" in their toolkit, not "rule." The only position in the organization that holds authority over all four at once is the top executive.

This isn't theory — the field already has examples.

First, a counterexample: a major tech company's delivery team — a customer's business unit wanted a business agent but had no budget; the budget sat with the IT team, and IT and the business unit were in different departments — so the vendor had no choice but to design a solution that could "satisfy IT's technical sophistication and the business's outcome at the same time." What they found in the end was that "the sophistication IT wanted wasn't necessarily the outcome the business needed, and the outcome the business needed wasn't necessarily the most sophisticated approach" — no way to reconcile the relations of production, whichever way they turned it.¹

A positive counterexample comes from a manufacturer: the chairman himself made a clear commitment to embracing AI, picked the sales function and a target region, and drove it top-down — finance, IT, and the sales line all moved together. The pilot started in the company's weakest-performing province and, six months later, that province had become the most advanced in the entire company, ready to be rolled out nationwide. Same equation, but whether the top executive is in it changes the answer completely.

It runs deeper than that. Inertia and self-interest are what have to be overcome, and the authority to change how people work — to overturn that inertia — likewise rests only with the top executive: performance metrics, headcount, the boundaries of departmental responsibility are all matters of corporate governance, not something any single business or technical department can move unilaterally. So this isn't a matter of posture — a plea to "get leadership to take it seriously" — it's a math problem about authority: the sum of authority required only comes together at the very peak of the management pyramid.

II. Fall Short of the Priority List, and the Road to Adoption Stops

So is it enough for any project to simply get an executive attached, and everything falls into place? No. Bob McGrew, an early Palantir executive, gave a sharper filter: your entry point has to be a problem leadership has already flagged as critical — ideally, one of the CEO's top five priorities. His reasoning is entirely practical — only a problem at that scale gives you enough force to grind through an organization's internal bureaucratic resistance; fall short of that priority level, and the customer organization has no reason to stay with you through the hard parts of getting the system adopted.²

The flip side of this standard matters just as much. As the vendor, the person you can actually reach is often an IT lead or some sponsor a few levels removed from the CEO — and that distance changes the nature of the problem. Whoever sits between you and the top has their own performance metrics to answer to, and would rather you solve something easy for them than touch something risky for them. So the project gets "downgraded" right at the source: what should have addressed the business's core pain point ends up as a safe, marginal, nobody-gets-offended demo project instead. This is exactly the organizational failure mode mentioned in Chapter 2 — it isn't that the problem wasn't worth solving, it's that you couldn't reach it.

A more complete chain of failure comes from the CEO of an enterprise software company: the board goes to the CEO and says "we need more AI," and the CEO says, fine — "I'll get a consultant to do more AI." The result is some centralized project nobody understands — detached from any specific business unit, operations never aligned. "Those things will fail."³ Note the irony in this chain: it isn't a failure of the top executive's absence at all — it's a failure of the top executive showing up only at the start and being absent for the entire middle. The signature gets signed, and then what?

III. "None of the Three Understand": An Empty Intersection

Why do AI projects depend so heavily on the top executive to pull people to the same table? Because there's a structural hole inside the organization, summed up in a phrase that circulates through the industry: whoever understands the business doesn't understand AI, whoever understands AI doesn't understand the business, and whoever understands both has no authority.⁴

This isn't a matter of capability — it's a matter of how the organization divides labor. A business expert's knowledge grew out of years on the ground; an AI team's ability grew out of a technical stack; two different languages, two different scorecards, two different circles — and the people who straddle both sides tend to sit low in the org chart in most organizations. They're too new, not yet risen to a position where they can command resources. With the intersection of all three empty, every project ends up running a "translation relay": the business explains the requirement to product, product translates it for engineering, engineering builds it and translates it back — and context is lost at every handoff (the same relay-loss from Chapter 6 replaying itself, unchanged, inside the organization).

Only the top executive can pin all three types of people to the same table at once. Pulling all sides together is what lets "what the business doesn't know" and "what the technical side doesn't know" cancel each other out inside the project — the business expert corrects course on the spot, the technical expert assesses feasibility on the spot, and questions of authority get settled on the spot. The reason an FDE is called a "forward-deployed engineer," the reason they have to be stationed at the customer's own site, is essentially to pull that translation-relay middle layer down onto a single table.

IV. What Executive Sponsorship Actually Means

Pull the slogan apart, and executive sponsorship in a real project takes the shape of three kinds of backing, none of them optional.⁵

Budget backing: only the top executive can rule on cost ownership for a cross-departmental project. The department that benefits from an AI project and the department that funds it are almost never the same — the money comes out of the IT budget, and the efficiency gains get credited to the business department's ledger. On any single department's books, a project like this looks like a loss; it only balances on the company's overall books. Who looks at the company's overall books? The top executive.

Incentive backing: the incentive problem discussed in Chapter 15 has no solution at the department level — the answer only exists at the top-executive level. Whether performance metrics change, whether headcount moves, whose fault an error is — these are acts of corporate governance, not something a project manager can promise. Without the top executive publicly standing behind it, the three failure modes from Chapter 15 will come true one by one.

Failure backing: allowing the first project to die meaningfully. An AI project's first delivery is, to a large degree, an exercise in organizational learning — learning how to work with an agent, learning how to measure, learning how to set acceptance criteria. Someone has to absorb the tuition for that first project on the organization's behalf; otherwise every department learns exactly one lesson — don't touch it, because touching it means the mistakes are yours alone.

There are real examples of all three kinds of backing.

One is a shift in how the demand side approaches things: enterprise top executives' attitude toward AI has changed — "night and day — it used to be all about how to use it, whether it could even be used, and now people skip straight past that to the next stage: when do we start actually putting it to work for me." The inflection point came once agents capable of executing tasks arrived — the nature of the question shifted from "should we" to "how fast."¹

Another form of backing is the most concrete and closest to the ground: the chairman from the manufacturer in Section I personally taught more than fifteen sessions to the full workforce and management within a single year — "I learn it myself first, then I teach it to the employees, and only then can they understand what I'm thinking and actually use these systems well."¹ Shifting how people think isn't something a single kickoff rally can accomplish — it takes the top executive turning himself into the first instructor, and that single act covers all three kinds of backing at once: real, non-trivial time invested (budget), the most public form of standing behind it (incentives), and paying the tuition first, in person (failure).

Xiaopeng Lu (co-founder of Ventus AI, serving the North American healthcare industry) has shared his own observation: bosses who can genuinely drive AI adoption share exactly one trait — they're AI-native themselves, meaning they're heavy users of AI in their own right. His strategy is "win over the benchmark case first, then push it downward."⁶

This isn't an abstract question of attitude — in execution, it translates into real, measurable friction cost.

Lu compared two similarly sized clients: one boss's reasoning for driving adoption was "everyone else is pushing it, so I want to push it too"; the other's was "I'm certain AI needs to start now, and I'll invest whatever it takes." The difficulty of change management was completely different between the two — with firm, CEO-level support, things move far faster.⁶

This adds a mechanistic layer to "three kinds of backing": budget backing and failure backing matter not because they're ceremonial gestures, but because how certain a boss is about "whether to do this" translates directly into the friction coefficient of the organization's execution — a boss following a trend can hand over a budget, but can't hand over the conviction it takes to pay the tuition and fail in public first.

Test "showing up at the kickoff rally" against these three, and it doesn't count as executive sponsorship. Showing up is a fifteen-minute act; the three kinds of backing have to run through the entire months-long span of adoption.

The test for telling real backing from fake is just as plain: when the project runs into the departmental wall in month four, does the top executive step in and rule on it, or say "you two go work it out among yourselves"?

V. A Catalog of Misaligned Sponsorship

Projects where the top executive is under-involved, or involved in the wrong way, tend to grow into a few typical shapes, each with its own tell.⁵

• Technical-department-driven: the system is the IT department's achievement, not the business's tool. Tell: the weekly project report is all technical milestones, not a single business metric. This is the second of the three failure modes from the last chapter, already unpacked.
• Nominal sponsorship: the top executive showed up at the kickoff meeting and never appeared again. Tell: when the project escalates to something needing cross-departmental judgment, the meeting minutes have no signature above department level. The matching tell on the vendor side: whoever you could reach during the sales pitch is unreachable by the time delivery starts.
• Siloed: the project closes its loop inside a single department; data, authority, and process can't reach beyond it. Tell: the system works great, but only for a thirty-person team, and expansion plans are perpetually "next quarter." Siloed is the most respectable of the four shapes — it's at least alive — but it never proves the project can scale.
• Consulting-dependent: exactly the "board → CEO → consulting firm → centralized big project" failure chain.³ Tell: the project documentation keeps getting thicker while frontline usage records keep getting thinner.

This catalog isn't for labeling other people's projects — it's for checking the one in your own hands: if you're the customer-side project owner, which of these does your project look most like right now? If you're the vendor, which one is your contract actually signed against?

VI. Two Gates and a Flywheel

Executive sponsorship isn't a one-time act of "winning over leadership." It has two gates — clear the first and there's still a second — and once both gates are cleared, it can spin up into a flywheel (see Figure 16-1).

Figure 16-1: The top executive's role isn't making technical decisions for the team — it's getting cross-departmental resources, responsibility, and priority through two gates.

The first gate: calibrate the top executive's expectations. Going in, four things need to be laid out clearly: what AI can do, what it can't, how long before results show, and what has to be invested. Get expectations wrong, and once any single piece falls short after go-live, the boss's reaction is "I was misled" — one of the three failure modes is already buried at the door. A common calibration scenario: the boss opens with "cut headcount by thirty percent" or "replace three thousand people," and the conversation has to be pulled back to value right there on the spot — what AI replaces today is tasks, not jobs; a role only becomes replaceable once eighty percent or more of its core tasks have been taken over, and reality is nowhere close to that yet; trading "promise to cut three thousand jobs" for "deliver seven verifiable efficiency gains" is what lets both sides keep going.⁷ Why is this gate hard to clear? Because most bosses' judgment of AI comes from a short video they scrolled past last night or a viral case study floating around online, not from systematic understanding — one practitioner said plainly that the biggest hidden cost in the adoption process is the boss's own cost of learning.⁸ Calibrating expectations essentially means spending that cost of learning up front, at the gate, instead of letting it explode at acceptance.

The second gate: defuse employee fear. Chapter 15 devoted an entire section to unpacking this fear — it has no solution at the department level; what employees are watching for isn't what some project owner says, it's how the very top of the organization positions itself. Without the top executive stepping forward, this gate stays bolted from the inside. Three moves: don't let the system present itself as a replacement for people; let the first cohort of users become beneficiaries, then let those beneficiaries win over the ones still on the fence; and the most critical move of all — the top executive has to stand behind it publicly. Approving a budget privately does nothing; it has to be stated publicly that "this is so everyone can spend their time on more valuable work."⁷ The difference between private support and public backing is one employees can tell apart perfectly well when they vote with their feet.

Once both gates are cleared, there's one more practical habit: pin a key-stakeholder map into the weekly report — who's a sponsor, who's the point of contact, who's potential resistance, and what each of them actually cares about, updated every week, turning the org chart from a static stack of business cards into a living map.

Does the work of clearing these gates have to start over from scratch on every project? One practitioner's approach turned it into compound interest: getting the first AI-illiterate boss on board is the most exhausting; every boss won over after that adds another layer to your material — training decks, alignment scripts, a list of common misconceptions — ready to reuse next time; and real problems worked out in the field also feed back into the head-office product, making the next customer easier to win over. So "the bosses keep turning over, and the playbook in your hands keeps getting thicker" isn't consolation — it's compounding: individual instinct accumulating, one project at a time, into an organizational asset. This skill itself is one of the assets a forward-deployed engineer carries away.

VII. A Two-Sided Tool

This chapter closes with two checklists — one for the customer, one for the vendor.

A checklist for managing upward, for the customer-side project owner: ask the top executive for three things — a clear ruling on budget ownership (who pays, how it's split), explicit authorization (a written designation of the project owner and their cross-departmental authority), and incentive backing (a public statement, ideally paired with a change in performance metrics); report progress using the Chapter 8 acceptance vocabulary — business metrics, time window, judgment criteria — instead of a technical Gantt chart; sync progress with the top executive once a quarter: where does this project currently rank among their five priorities? If it falls out of the top five, either escalate the project back into rank, or wind it down early and gracefully.

A pre-sales due-diligence checklist for the vendor: what signals of executive involvement show up in the contract — who attends the kickoff meeting? Who signs off on the acceptance criteria? Does the authorization path for cross-departmental data access actually work? A contract negotiated only with the technical department should be priced with "this project will probably die in month four" baked into the risk (Chapter 20's pricing and Chapter 27's deal-screening will pick this thread back up). One more piece of well-meant advice: if due diligence turns up that the customer's top executive just wants "AI" printed in the annual report, the best deal you can make is not making this deal.

VIII. When It Doesn't Have to Be the Top Executive

Back to the instinctive flinch from the opening — when "executive sponsorship" gets sold as a cure-all, it really does obscure a truth one level down: the core of this rule isn't reverence for rank. It's aligning authority with benefit.⁷

When a project can close its loop entirely inside one department — data never leaves it, process never touches anyone else's territory — "top executive" can scale down to "process owner": whoever holds both the authority and the benefit for that one process. A shop-floor supervisor over the shop's scheduling system, a finance director over an invoice-review agent — both can be effective "department-level top executives."

So this chapter's conclusion comes down to one sentence: the minimum organizational condition for AI adoption isn't "there's a top executive" — it's "the reach of the authority is no smaller than the span of the problem." A problem crossing four departments needs authority that stands above all four; a problem crossing a single process only needs a process owner. Which one is the exception, and which the norm? So far, the four-department case remains the norm — because the problems worth an FDE's time are almost always cross-departmental.

The top executive gets you through the door, and keeps the project alive through adoption. But a living system eventually has to answer one last question: where does delivery actually end — at the signature on the acceptance form, or at the point where you can walk away with a clear conscience? Handoff is next.

---

Footnotes

1. Silicon Valley 101, Episode 248: "China-Style FDE, with Alibaba Lingyang's Peng Xinyu" ↩ ↩² ↩³

2. Fan Bing, Forward Deployed Engineer (FDE) (XDash open-source book) ↩

3. a16z, Box CEO on AI agents and why enterprises can't keep up ↩ ↩²

4. "Anyone Out There Actually Doing FDE Work?" (linux.do thread) ↩

5. Crossroads × Rolling AI, "A Conversation on FDE" (podcast) ↩ ↩²

6. Tencent Research Institute, AI Lens Roundtable, Episode 6: "FDE Non-Consensus Views and a Field Guide from Silicon Valley Founders" ↩ ↩²

7. "100 Questions About FDE" (open-source ebook) ↩ ↩² ↩³

8. "AI Job Sense: Stop the Agent Rat Race" ↩