Between 65 percent and 75 percent of new products or services miss their revenue or profit goals.[1] In consumer packaged goods alone, roughly 40 percent of new SKUs have disappeared from shelves within two years of launch.[2] The product team shipped. The launch event happened. The press release went out. The dashboard showed green. The outcome didn’t follow.

The same pattern shows up in large-scale organizational change. McKinsey’s 2008 survey of 3,199 executives found that only about a third said their organization had achieved a true step change in performance.[3] In that same survey, the companies that applied all of the recommended tactics succeeded more than 80 percent of the time. The tactics were published. The Standish Group has tracked software project outcomes since 1994.[4] Success roughly doubled through the early 2000s and has been broadly flat since, in a band where most projects still miss their targets. Organizations announce transformations, stand up steering committees, publish progress updates, and close initiatives as complete. The outcome often doesn’t follow there either.

And in technology: the 2025 Gartner CIO and Technology Executive Survey, released in October 2024, found that only 48 percent of digital initiatives enterprise-wide meet or exceed their business outcome targets, after all the planning, the investment, the rollout and the go-live celebration.[5]

Three different domains. Three different sets of researchers. Three different definitions of success. And in each one, the same structural gap: the moment of completion is rewarded as the goal, while the intended outcome remains largely unmeasured, or measured too late to act on.

This paper is about why that gap exists and what it actually costs.

The strategy no one names

Every organization running a structural gap between activity and outcome is making a choice, even when it doesn’t feel like one. The choice: launch more initiatives to cover the gap, rather than ask what’s creating the gap. Add more resources to cover an adoption rate that hasn’t moved. Run more programs to maintain the appearance of transformation momentum.

That is “good enough” as a strategy. It optimizes for short-term measurable output at the cost of long-term structural performance. And the moment it becomes visible as a choice is always the same: it’s the planning conversation where someone asks whether to add more activity or investigate why the activity isn’t producing results, and the room decides, usually without saying so out loud, that more activity is safer than the question.

It succeeds at the wrong thing while accumulating a cost those metrics were never designed to find.

This isn’t an irrational choice. It’s the rational output of a system designed to reward it.

Wald’s problem

In 1943, Abraham Wald was asked by the U.S. military to analyze bullet hole patterns on aircraft returning from combat. The military’s instinct was to reinforce the areas showing the most damage. Wald’s contribution was pointing out the error: the planes they were analyzing had returned. The holes showed where a plane could be hit and survive. The signal they needed was in the planes that never came back. Those planes weren’t in the sample.

This is the precise structure of the “good enough” problem.

Organizations that accept a structural gap between activity and outcome analyze individual failures. They have retrospectives, they identify why specific efforts fell short and they adjust the next one accordingly. What they often don’t do, and what Wald’s insight names precisely, is ask what structural conditions are generating most of their efforts as failures in the first place. The military wasn’t ignoring the bullet holes. They were studying the wrong planes. The AI projects that fail, on some estimates more than 80 percent of them, are not generating post-mortems on the structural decisions made at launch.[6] The transformation initiatives that stalled quietly are recorded as “execution challenges,” not as evidence that the conditions were wrong from the start.

The losses carry the signal. The returning planes confirm what already works. The planes that didn’t come back are telling you where the system is actually broken. And they are the one data source the organization was built to not require.

Where the cost accumulates

The costs don’t appear in the dashboard showing green because of a structural timing problem: the feedback gap between the decision that causes failure and the moment that failure becomes visible often can run for years.

The people on the receiving end of initiatives that didn’t deliver remember. Employees who were asked to change how they work, given inadequate support, and then watched the initiative quietly dissolve remember. Partners, customers and stakeholders who were promised outcomes that didn’t materialize remember. That memory doesn’t show up in the program dashboard. It shows up eighteen months later as a change initiative that can’t get traction because trust was spent on the last one, or a talented person who stops raising their hand because nothing came of it the last time they did.

More activity layered on top of structural conditions that haven’t changed is not a growth strategy. It is a treadmill. And the pace accelerates as the organization’s capacity for genuine change erodes under the weight of everything that looked like change but wasn’t.

The organizations that figure this out do not do it by finding more efficient ways to run the same motion. They do it by asking a different question: what are the losses telling us that the wins cannot?

Four questions

Before reading the next section, answer these honestly:

1. What is your current success rate, and when did you last ask why it is that number instead of higher?

2. Of your last ten major deployments or initiatives, how many produced measurable outcomes twelve months after launch?

3. When your team says “we’re being practical,” what specifically are they protecting themselves from having to change?

4. Can you name what your failures are telling you about the conditions generating them, or have you built a system that doesn’t require you to know?

An organization running a genuine “good enough” strategy will feel the absence of an answer to that fourth question more than any of the others.

The compounding alternative

This is not an argument about individual capability. It is an argument about what the system asks of the people inside it. The same person performs differently depending on what the structure around them is designed to reward and designed to ignore.

In 2005, Salesforce was growing and losing customers. Not dramatically, but at a rate quietly undermining the economics of a subscription business still proving out its model. The leadership team asked a question most software companies weren’t asking: what happens after a customer commits, and who in the organization owns what they actually experience? The answer was to create the customer success function: a named, staffed, measured capability dedicated to ensuring customers achieved the outcomes they purchased. The measure of success shifted from transactions completed to results delivered.

That structural decision compounded over years. Retention rates climbed well above industry averages. Existing customers expanded faster than others churned. The organization’s relationship with its customers changed because the structure changed, not because the people improved, but because what the system asked of them did. By 2010, the model had become a design standard the rest of the industry was trying to replicate.

Salesforce did not hire better people than its competitors. It built a different structure, anchored to a different definition of success, and had the discipline to ask what the organizations that weren’t coming back were trying to tell them.

The question is not whether your team is working hard. The question is whether the system they’re working inside is designed to learn from what isn’t working, or only from what is.

“Good enough” isn’t the floor of acceptable performance. It’s a ceiling. The organizations that sustain change, develop talent and build real capability at scale are not the ones that ran more volume. They are the ones that treated their loss rate as a diagnostic signal rather than a fixed cost, built the structural capability to address what that signal said and redesigned the conditions generating losses rather than covering them.

Notes

[1] Madhavan Ramanujam and Georg Tacke. “Your New Hit Product Might Be Underpriced.” Harvard Business Review, May 2016. Between 65 percent and 75 percent of new products or services miss revenue or profit goals.

[2] Kupor, D., Tormala, Z. L., and Norton, M. I. “How Common Is New Product Failure and When Does It Vary?” Marketing Letters, 2021. Analysis of 83,719 SKUs across 31 U.S. consumer packaged goods categories.

[3] “Creating organizational transformations: McKinsey Global Survey Results.” McKinsey Quarterly, August 2008. Survey of 3,199 executives, fielded July 2008. Findings cited: only about a third said their organizations achieved a true step change in performance; companies applying all recommended tactics succeeded more than 80 percent of the time.

[4] Standish Group. CHAOS Report series, 1994 to present. Reported success rose from 16 percent in 1994 to roughly a third by the mid-2000s and has been broadly flat since. Two cautions apply. The 2015 report changed its success definition, so the series is not a clean like-for-like record. And the methodology has been criticized in the peer-reviewed literature, most directly by Jorgensen, M. and Molokken-Ostvold, K., “How large are software cost overruns? A review of the 1994 CHAOS report,” Information and Software Technology 48(4), 2006, pages 297 to 301, and by Eveleens, J. L. and Verhoef, C., “The Rise and Fall of the Chaos Report Figures,” IEEE Software 27(1), 2010, pages 30 to 36.

[5] Gartner. “Gartner Survey Reveals That Only 48% of Digital Initiatives Meet or Exceed Their Business Outcome Targets.” Press release, October 22, 2024. The 2025 Gartner CIO and Technology Executive Survey: 3,186 CIOs and technology executives in 88 countries, supplemented by 1,126 executive leaders outside IT.

[6] Ryseff, J., De Bruhl, B. F. and Newberry, S. J. The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed. RAND Corporation, RR-A2680-1, August 13, 2024. RAND states that “by some estimates, more than 80 percent of AI projects fail,” attributing the figure to Kahn, J., Fortune, July 26, 2022, rather than generating it. RAND’s own contribution is a qualitative study of root causes based on 65 interviews. A separate and materially lower estimate comes from Gartner, which found that 48 percent of AI projects reach production (press release, May 7, 2024). The two figures measure different things and do not corroborate each other.

The conversation happening in boardrooms, at conferences and across the leadership press right now is worth taking seriously. Executives need better judgment infrastructure for AI decisions. Boards need to ask harder questions about how AI-assisted decisions are made and who is accountable for them. Organizations need governance frameworks that account for autonomous action in ways they never had to before. These are real observations. The people making them are noticing something true.

What is being diagnosed as a governance gap is better understood as a symptom of something upstream, and governance frameworks, however well-designed, cannot reach it on their own. The sequence matters as much as the structure.

Governance, in this context, means two things: who in the organization is authorized to deploy AI agents and what those agents can access, and what categories of decisions agents are permitted to make on their own. Most of the current conversation addresses the first. Almost none of it addresses the second. That distinction matters more than the governance conversation has acknowledged.

The diagnosis being made

The pattern in recent executive-facing AI coverage has converged on the same argument: AI is moving faster than executive understanding. Leaders are deploying without comprehending the downstream implications. The fix is fluency: get executives up to speed on how AI works, what it can and cannot do, and how to govern its outputs. Layer on governance frameworks: decision rights, accountability structures, oversight protocols. Build the infrastructure for better judgment.

This framing is not wrong, but it is incomplete in a way that matters.

What the governance conversation has not adequately addressed is that organizations publicly reporting AI implementation friction are not uniformly ungoverned. Many have invested in exactly the frameworks being prescribed. The problem showing up in their results is not the absence of structure. It is that the structure is sitting on top of something that was already broken before AI arrived.

What was already broken

The Why Change Fails series mapped five breakpoints where organizational transformations collapse: Strategic Disconnection, Incentive Fragmentation, Process Friction, Technology Illusion and Momentum Mirage. Each one represents a failure mode that does not originate with AI. AI accelerates them.

Strategic Disconnection is the one the governance conversation consistently underestimates. Most AI adoption right now is not driven by a coherent vision of what the organization is trying to become. It is driven by fear of being left behind, or by a belief that AI is a substitution technology: that you can swap AI for people and process, reduce costs and preserve outputs. Neither of those is a strategy. Neither of them answers the question that transformation requires an answer to: what are we building toward and why does it matter?

When that question has no answer, employees notice. They experience AI deployment not as progress toward something but as threat confirmation. The organization is figuring out how to need fewer of them, and leadership either will not say it plainly or does not see it. That experience does not stay private. It becomes the operating context in which every subsequent AI initiative lands. Governance frameworks cannot fix a trust deficit. Fluency training cannot fill a vision void.

This is the failure that predates the governance conversation and that governance frameworks, on their own, will not reach.

Why AI makes it worse

Paper 4 of the Why Change Fails series, The AI Mirror, made the argument directly: AI does not create organizational dysfunction, but amplifies whatever is already there. Deploy AI into an organization with clear purpose, coherent incentives and well-designed workflows, and AI accelerates progress. Deploy it into an organization where strategic direction is absent, incentives are misaligned and workflows were built for a different era, and AI makes those problems move faster and at greater scale.

There is a second problem the amplification framing does not fully capture. With software, a bad decision was at least traceable. Someone designed it in, or someone failed to catch a flaw. The cause had a name. AI agents operate differently. They do not execute what they were told. They infer what to do from the context they are given. That means an agent can do exactly what it was authorized to do, touch only the data it was permitted to touch, and still produce an outcome nobody intended, because it concluded something nobody anticipated. The organization can have complete audit logs of what the agent did and still have no clear answer for why it decided to do it. Governance frameworks installed on top of strategic disconnection do not just codify bad decisions more efficiently. They authorize a system to make decisions nobody designed and nobody approved, in service of a direction nobody agreed on.

The governance conversation is trying to solve an output problem. The output problem is a strategy problem. And strategy, as Paper 3 of the series argued, takes on the shape of what the system actually rewards, independent of what is stated in values documents or town halls.

This is where the design problem becomes visible. Cost reduction is a legitimate and often necessary outcome. The issue is when cost reduction becomes the ceiling rather than a floor. An executive whose incentive structure is built around cost reduction will build, consciously or not, an organization optimized for that purpose. AI deployed in that context will reduce costs efficiently. It will not answer the question the organization never asked: what is the freed capacity for? Governance frameworks installed on top of that answer will govern the outputs of a narrow purpose well. They will not expand the purpose.

Organizations that have done the upstream work, that have a genuine answer to what they are building and why, will find that governance frameworks become exactly as powerful as advertised. The sequence determines the outcome.

The sequencing problem

There is a pattern in organizational change that the series has documented across multiple contexts. An organization experiences a visible failure. Consultants and advisors identify a proximate cause, the thing that failed most recently and most visibly. A prescription is built around that proximate cause. The prescription is implemented with genuine effort. The same failure recurs, in a slightly different form, because the root cause was never addressed.

This is a sequencing problem, not a competence problem. The organizations investing in governance frameworks are often doing exactly what the situation calls for. The question is whether the foundation those frameworks are meant to govern is ready to support them. Governance installed on top of strategic clarity is a multiplier. Governance installed on top of strategic disconnection codifies the disconnection more efficiently.

The AI governance conversation is following this pattern. Organizations deployed AI without clear purpose, without dealing honestly with the substitution question, without the leadership foundation that genuine transformation requires. They are now experiencing the downstream effects: eroded trust, misaligned outputs, accountability gaps. The prescription being offered is governance frameworks and executive fluency. Those are real interventions. They are interventions that will reach their full potential only when the foundation beneath them is sound.

The question worth asking is whether the organization has the governance infrastructure its AI decisions require, and whether it has the organizational conditions that make any governance infrastructure work. The governance conversation has a framework answer for the first. The Why Change Fails series was written to address the second.

GitLab’s 2026 restructuring illustrates the sequence. They did not begin with governance, but with ten core beliefs about what the agentic era requires. Governance came fifth, only after the strategic foundation was named. They also removed up to three layers of management because every layer is a place where vision and priorities get filtered. The shorter the stack, the closer governance gets to the work it is meant to shape. (GitLab Act 2, 2026)

Where the work actually starts

Paper 1 of the series identified Strategic Disconnection as the first breakpoint: the failure to connect transformation effort to a clear, owned, communicated purpose. That breakpoint applies to AI adoption directly. Before governance, before fluency, before workflow redesign, the organizational question is: what is AI for here, specifically, in terms of what we are building and who we serve?

That question is not technical. It is not answered by a governance committee. It is answered by leadership that has done the harder work of clarifying what the organization actually is, what it is trying to become and what it is willing to trade to get there. Without that clarity, AI deployment, however well-governed, is acceleration without direction.

The governance conversation is worth having, and organizations that invest in it seriously are further along than most. The question worth adding to that conversation is: what are we governing toward? Governance that works starts with a named purpose, distributes accountability to the teams actually deploying agents, and defines what agents are permitted to decide on their own. That sequence is available to any organization willing to do the upstream work first.

Enterprise AI deployments follow a pattern that has become predictable enough to examine as a system problem rather than a series of individual failures.

A vendor builds a proof of concept. The technology performs. The engagement is logged as a success. Three to six months later, the system has degraded, drifted or stopped being used. The customer calls with a complaint that sounds like a technology failure. It is usually not.

The technology worked. The organizational conditions required to sustain it were never established. Published data on this pattern is consistent: IDC’s CIO Playbook 2025 found 88% of AI proofs of concept fail to reach production deployment, and RAND Corporation’s 2024 study found AI projects fail at roughly double the rate of non-AI IT projects.[1][2] In both cases the failure point is reliably the organizational transition rather than the technology itself.

The major AI vendors have recognized that a gap exists between what agentic AI can do in a controlled demonstration and what enterprise organizations can absorb in production. Their institutional response, the Forward Deployed Engineer, is a reasonable answer to a real problem. The purpose of this piece is to examine what that answer gets right, what it misses and what a more complete model would require.

The Three Problems the FDE Model Addresses

The Forward Deployed Engineer (FDE) is not a new concept. Embedding technically skilled practitioners with customers to accelerate deployment has been a feature of enterprise technology sales for years. What is new is the scale at which the leading AI vendors are deploying the model and the convergence with which they are doing it.[3][4][5][6] When the major players move in the same direction at roughly the same time, the shared problem they are solving is worth examining.

Three problems drive the model. They are related but distinct, and the FDE addresses them unevenly.

Speed. The traditional enterprise deployment model requires agreement on scope, team assembly and a signed statement of work before any technical work begins. A competitor who can start building on day one has a significant advantage in a market where customers are still evaluating options. The FDE is, at its core, a competitive response to the sales cycle problem.

Skill. Most enterprises do not have the internal capability to stand up a production-grade GenAI deployment. They have teams who understand the vocabulary, have run pilots and experimented with consumer tools. Most do not have teams who can architect multi-agent systems, design evaluation frameworks, manage model behavior in production or build the feedback loops that keep outputs aligned to intent over time. The FDE imports that capability.

Value fit. Inside most enterprises, the people closest to AI tools gravitate toward problems that are technically interesting rather than problems that are strategically important. The result is a proliferation of pilots that address edge cases, internal tooling and experimental applications that will never justify the investment required to scale. The FDE, at best, helps redirect effort toward use cases that align to real business priorities and are worth building toward production.

The FDE model addresses the first two problems reliably. The third receives more uneven treatment. Identifying a use case that genuinely matters to the customer’s business requires a different kind of conversation than the one that moves a deployment forward, and it is structurally in tension with the speed problem the FDE also exists to solve.

All three share a common assumption: the job is done when the proof of concept works. None of them address what happens after the FDE leaves.

What the Job Descriptions Reveal

The published job postings from the major AI vendors offer a window into what each believes the FDE role is actually for. Read across vendors, the signal is consistent.

The shared profile: production experience with large language models, advanced prompt engineering, agent development and evaluation frameworks. The most sophisticated postings add language about scoping work, sequencing delivery and measuring success through production adoption and measurable workflow impact. That framing is closer to what actually determines whether a deployment produces durable value. But it is still a delivery capability. The FDE is expected to measure workflow impact, not to assess whether the organization has the conditions to sustain that impact.

The hiring criteria is the most direct evidence of the diagnosis. When the screening requirements center on code, LLM architecture and prompt engineering, the model has already decided what the problem is: a technical build gap. That diagnosis is partially correct, but for most enterprises struggling with AI adoption, the build constraint isn’t what’s holding them back.

Across all of them, the requirement to assess organizational readiness before building begins is absent. None ask whether the intended outcome is defined specifically enough to govern the system over time. None address who owns the result after the FDE departs. None require evaluation of whether the workflows being augmented have been redesigned to absorb a new capability, or whether the organization has the practices to maintain what it has been handed.

The FDE is hired to win the engagement. Getting to a working proof of concept and securing adoption is the job. Whether that proof of concept becomes a production system that holds is someone else’s problem. That boundary is not incidental. It reflects a theory of the problem that stops at the close.

Where AI Deployment Differs from Software Deployment

Before examining what the FDE model misses, it is worth acknowledging what it reflects accurately: the current deployment complexity is partly a function of where AI sits on the technology adoption curve.

New, disruptive technologies that do not fit cleanly into existing paradigms have always required more intensive engagement at the proof of concept stage. Early ERP deployments, the first wave of cloud migrations, the initial rollout of service-oriented architectures: all required embedded practitioners, extended scoping and significant organizational work before value could be demonstrated. As those technologies matured and deployment patterns became repeatable, the model shifted: RFI and RFP processes replaced custom engagements, implementation templates replaced bespoke builds, and in some cases the proof of concept was skipped entirely because the deployment risk had become well understood. The FDE model, in this reading, is a maturity response. It will evolve as AI deployment becomes more templated.

That reading is partially right.

The proof of concept model works well for traditional enterprise software because the deployment question and the value question are largely the same: does the technology work in this environment? If yes, adoption follows a predictable path. The product has documented behavior, known integration requirements and repeatable deployment patterns. Once it is working, it keeps working. Maturity reduces the cost of answering that question. It does not change the nature of the question.

GenAI presents a different question, one that does not get easier to answer as the technology matures.

A proof of concept demonstrates that the model can produce an output. It does not establish whether the organization can define what “good output” looks like consistently enough to govern it over time. It does not determine whether the workflows the output is meant to improve are ready to absorb a new capability. It does not assign ownership of the ongoing tuning, monitoring and correction the system requires. It does not create the feedback loop that catches drift before it compounds.

The maturity path is real for narrow AI tools that return a result and stay in place. Those do follow the pattern of earlier enterprise technologies. Deployment complexity decreases as patterns become repeatable and implementation becomes templated. Agentic AI follows a different path. A mature, widely deployed agentic system still requires someone to own the outcome, still requires the workflow to have been redesigned around the new capability, still requires active monitoring to catch drift. Those conditions do not become easier to ignore as the technology matures. In some respects they become harder, because the scale of agentic deployment grows while the organizational attention given to any single system shrinks.

The organizational conditions problem has been present in enterprise technology adoption for decades. It has largely been absorbed by the friction of slow deployment cycles, long implementation timelines and the tolerance organizations have had for mediocre technology outcomes. AI removes much of that friction. Deployment is faster, outputs are immediate and the gap between a working proof of concept and a drifting production system is measured in weeks rather than years. The organizational problem that could be ignored in previous technology cycles can no longer be deferred.

This is what the FDE model has not yet fully reckoned with. Some of what FDEs do today will be templated away as AI matures. The organizational readiness work will not.

What Successful FDE Engagements Have in Common

Not every FDE engagement follows the failure pattern. The engagements that produce durable value share a set of characteristics that are organizational rather than technical.

In the engagements that hold, someone established four things before any technical scoping began: the specific business outcome the deployment was meant to produce, the person accountable for that outcome after the FDE’s departure, the workflow changes required for the output to produce value and the mechanism by which the organization would detect drift from the original intent.

The FDEs who ask these questions are not doing so because their job description specifies it. They are asking because experience has taught them that a technically successful deployment landing in an organizationally unprepared environment will not hold. These are organizational design questions. The job description treats them as someone else’s problem.

The vendors winning sustained customer relationships beyond the proof of concept are the ones where the embedded practitioner has come to understand that standing up the system is not the end of the job. Making sure the organization can own what it has been handed is.

Four Prerequisites Before the First Line of Code

A model designed for the actual problem would treat organizational readiness as a prerequisite for technical scoping, not an afterthought following deployment. That prerequisite assessment centers on four questions.

What is the outcome? The business result the deployment is meant to produce, stated specifically enough that someone could evaluate, six months from the launch date, whether it was achieved. A use case is not an outcome. If the customer cannot answer this question before scoping begins, the proof of concept will demonstrate that the technology works and establish nothing else. The FDE should not build until there is a clear answer.

Who is accountable after the engagement ends? The person responsible for whether the deployment produces the stated outcome: not the project manager, not the executive sponsor, but the individual whose job it is to ensure the system continues working and producing value once the vendor has left. If no one holds that accountability at the start, the system will be maintained by whoever is available. That is how working systems become broken ones.

What changes in how work gets done? AI either augments existing workflows or replaces them. Either way, something about how people work must change for the output to produce value. If that change has not been designed before building begins, the new capability will be used around the edges of the existing process and produce marginal results regardless of how well it was built.

How will drift be detected? AI systems require active monitoring. The relevant questions: who is responsible for comparing what the system is producing against what was intended, at what frequency and with what authority to intervene when drift is detected. If no one owns this function before the FDE leaves, the system works at launch and fails quietly over time.

These questions do not require an organizational consultant to ask. A technically skilled practitioner can ask and help answer them. The prerequisite is treating them as conditions for starting, not issues to address if problems emerge later.

The Structural Problem the FDE Model Has Not Resolved

The FDE model exists because the gap between what AI can do in a controlled environment and what an enterprise organization can absorb in production is real and large. Embedding technically capable practitioners with customers is a legitimate response to that gap.

The gap the FDE model has not resolved is primarily organizational. The technology works. The proof of concept succeeds. What fails is the organizational side: definition of purpose, ownership structure, workflow redesign and monitoring discipline. These are the conditions that determine whether a working proof of concept becomes a production system that holds.

The structural reason is straightforward. The proof of concept is where the sale closes. Organizational readiness work, the work that actually determines whether the deployment holds, happens after the contract has been signed. There is no incentive to make it part of the FDE’s scope. There are real incentives to keep it out: it slows deployment, introduces friction into the customer relationship and surfaces organizational problems the customer may not want named.

The vendors who change this will not do so primarily because it serves their customers, though it does. They will do so because the failure pattern ultimately damages the relationship and the renewal. The vendors who treat customer success as the measure of done will build something that compounds over time. The ones who continue measuring success at proof of concept delivery will keep winning the deployment and losing the account.

The FDE role is the right instinct. What it defines as success is the wrong question.

Notes

[1] IDC Research in partnership with Lenovo. Lenovo CIO Playbook 2025. Finding: “88% of observed POCs don’t make the cut to widescale deployment. For every 33 AI POCs a company launched, only four graduated to production.” Cited in CIO Magazine, March 25, 2025.

[2] RAND Corporation. “Why AI Projects Fail” (RRA2680-1), 2024. Based on interviews with 65 data scientists and engineers. Finding: more than 80% of AI projects fail, roughly double the failure rate of non-AI IT projects. Note: broader scope than POC-to-production specifically.

[3] Palantir Technologies. “Beyond Founder Mode: Mission Mode.” Palantir Blog, November 12, 2025. https://blog.palantir.com/beyond-founder-mode-mission-mode-b81bfa5a8d82. Describes Forward Deployed Engineering as a novel approach generated from Palantir’s need to work inside complex mission-driven organizations.

[4] FDE Academy. “How Palantir Invented the Forward Deployed Engineer Model.” April 13, 2026. https://fde.academy/blog/how-palantir-invented-the-forward-deployed-engineer-model

[5] Pragmatic Engineer. “What are Forward Deployed Engineers, and why are they so in demand?” November 3, 2025. https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers

[6] Netguru. “What Is a Forward Deployed Engineer? The Complete Guide.” June 4, 2026. https://www.netguru.com/blog/forward-deployed-engineer-role-guide

The standard prescription for enterprise sales is to maintain three to five times your quota in pipeline. That is practitioner convention rather than a research finding, and it survives because the arithmetic is hard to argue with. For complex deals with long cycles, multiple stakeholders and large contracts, five times is not unusual. If your win rate is around 20 to 33 percent, you need enough pipeline to absorb the losses and still hit your number.

Notice what that prescription does not include: any examination of why the win rate is what it is, whether it could be different, or what it would take to change it. The coverage model treats a 20 to 33 percent win rate as a fixed operating condition, something to plan around rather than something to fix. Build enough pipeline and the math works out. Do not ask why four out of five deals are being lost.

This is an institutional design choice, repeated across the industry and rarely named as such. Coverage ratios, quota design, territory structure: an entire operating model built around a failure rate no one questioned. That acceptance is its own illusion.

It is not the only one.

Of the deals that do close, many fail to deliver the outcome the customer purchased. The product gets deployed. Adoption stalls. The ROI case that justified the purchase is never tracked against actual results. Years later, when the renewal conversation finally arrives, the original champion has often moved on and no one can reconstruct whether the investment was worth it.

Some of what gets counted as success is not success. A transformation is declared successful when the system goes live, on time, on budget, full scope delivered. Whether the business actually changed, whether the promised productivity gains materialized, whether anyone is still using the system a year later: those are measured later, if at all. A sale is declared successful when the contract is signed. Whether the customer achieved the ROI they bought it for is someone else’s problem by then. Standish Group has documented this gap in software implementations for three decades. The Iron Triangle, on-time, on-budget, on-scope, is consistently measured; business value delivered is consistently not.[3] McKinsey’s 2008 survey of 3,199 executives found that among those whose transformation was meant to affect the whole organization, only 54 percent said the daily work routines of most of the workforce actually changed.[3] The transformation was delivered. Over in the work itself, less than half of it landed.

Two illusions compound each other. The industry accepts failure at the front end and does not measure it at the back end. The win rate measures whether the deal closed. It says nothing about what happened next. That gap, between closing the deal and delivering the outcome, is where most of the real failure in enterprise sales lives, and it is almost never measured.

That same gap appears in organizational transformation, and the structural reasons are identical. The Why Change Fails series maps five breakpoints where transformations collapse: Strategic Disconnection, Incentive Fragmentation, Process Friction, Technology Illusion and Momentum Mirage. The argument this piece makes is that those same five breakpoints explain why enterprise sales fails to deliver, with regularity and at scale, in ways the sales industry has not been willing to look at directly. The parallel is mechanistic, and understanding it changes what you look for, what you build and what you measure.

The win rate the industry has accepted

Win rates are not uniform across deal types. They vary by the nature of the opportunity being pursued.

Competitive displacement attempts close at very low rates because when a customer signals interest in replacing an incumbent, the signal is often not genuine intent to switch. It is a request for pricing leverage. RFPs that arrive without prior relationship development are frequently already written toward a predetermined selection. Pursuing them consumes time and resources at a win rate that rarely justifies the investment. Complex deals where the business problem and desired outcome are established before pursuit begins close at a materially higher rate.

Most organizations do not distinguish between these. They all count toward pipeline coverage. A low-probability displacement attempt and a high-probability outcome-anchored deal look identical in the coverage ratio, and the three-times-quota requirement absorbs both without flagging the difference.

A sales representative or solutions engineer with three to five assigned accounts and an annual quota does not have the luxury of selectivity. They pursue what is available. When accounts are early in relationship development, the available opportunities will skew toward lower-probability pursuits, not because the seller lacks judgment, but because the territory does not yet offer better options. The system produces the win rate it was built around, and the operating model absorbs it rather than examining it.

The organizations that consistently outperform on win rates are not generating more pipeline. They are better at identifying which deals are actually winnable and why, and running differentiated approaches for different opportunity types. That is a diagnostic and design discipline, and it is exactly what the system’s current design does not incentivize or develop.

A 20 to 33 percent win rate does not have to be accepted as a fixed condition of doing business. It is the output of a system that was never designed to ask why it is what it is. A different design, one that distinguishes pursuit types, builds relationship depth as a strategic priority and measures outcomes rather than activity, would produce a different result.

Where transformations and sales fail

Taking the five breakpoints from the Why Change Fails series and mapping them against enterprise sales failure is not a forced analogy. The mechanisms are the same even though the stakeholder configurations differ. The root causes are identical.

Strategic Disconnection is the failure to establish a shared, specific definition of what success looks like before the work begins. In transformation, this shows up as a compelling case for change that leaders can recite but can’t operationalize, direction without definition. Stakeholders are aligned on the narrative and misaligned on what changes, who owns it and how you know it’s working.

In sales, Strategic Disconnection happens before the contract is signed. The disconnection often precedes the deal itself. When a pursuit begins without a shared definition of what success requires, the pipeline fills with opportunities that can close but cannot deliver. The win rate problem and the outcome problem share the same root.

The buyer champion has a definition of success. The economic buyer has a different one. The implementation team, who will inherit the commitment, was not in the room for either conversation. The deal closes with multiple stakeholders aligned on purchasing a solution and misaligned on what solving the problem actually requires. Gartner puts the buying group for a complex B2B solution at six to 10 decision makers, and its 2025 buyer research found five to 16 people involved across as many as four functions.[1] Multiple stakeholders with different definitions of success is not a negotiating complexity but a delivery risk that the sales process treats as a closing challenge.

Incentive Fragmentation is the misalignment between what the organization measures and rewards and what the transformation requires. Leaders whose power depends on the current structure have no incentive to redesign it. The fastest path is marginal adoption around the edges, which looks like progress and produces none.

In sales, the incentive fragmentation is structural and explicit. The quota system measures deal closure, not outcome delivery. The seller is rewarded at signature. Whether the customer achieves the promised ROI is a customer success problem, a services problem, a product problem, almost any problem except a sales problem. The seller who closes a deal the customer can’t absorb has hit their number. The seller who slows a deal down to validate that the customer is ready has missed quota. The incentive structure does not reward the wrong behavior because sellers lack judgment. It rewards the wrong behavior because the measurement system stops at the wrong moment.

Process Friction is what happens when the workflows and handoffs required to deliver the outcome are broken, undefined or running on informal workarounds. Transformation initiatives that don’t redesign the underlying process are improving the wrapper on a broken package.

In sales, the broken handoff between pre-sale and post-sale is the process friction that makes failures predictable. The seller who built the business case is rarely the person who executes the implementation. The champion who sponsored the purchase is rarely the person whose daily work changes when the product goes live. The information that determines whether deployment succeeds, what the customer actually needs, what they said yes to and what problems they’re trying to solve, lives in the seller’s head and the pre-sale documents, not in the system the implementation team works from. Every enterprise software failure story that traces to “the customer bought something they couldn’t operationalize” is a process friction story. The handoff was broken before the project began.

Technology Illusion is the pattern of investing in a tool as a substitute for doing the organizational work that determines whether the tool produces value. The proof of concept is impressive. The deployment goes into conditions the organization hasn’t prepared. The gap between demonstration performance and production performance is attributed to the technology. The root cause is structural.

In sales, the Technology Illusion runs in both directions. The vendor believes that a technically capable product, correctly deployed, will produce the outcomes in the sales deck. The buyer believes that purchasing the right solution will solve the problem, bypassing the organizational change required to absorb it. Both are wrong for the same reason: they are treating an adaptive challenge as a technical one.[2] The outcome requires people to work differently, systems to be redesigned and decision authority to shift. None of those are features of the product. All of them are conditions the product requires.

Momentum Mirage is the confusion of activity for progress. Logs are filling. Tasks are completing. Deployment dashboards are green. The meaningful signal, whether the initiative is producing the outcome it was launched to produce, has no one watching it, because success was declared at go-live and the work of measuring actual value was not assigned to anyone with authority to act on what they find.

In sales, the Momentum Mirage emerges at renewal. Usage metrics look acceptable. Support tickets are within range. The customer hasn’t complained loudly enough to escalate. When the renewal conversation finally arrives, the account team discovers that the economic buyer who signed the original deal has a different read on the value delivered than the usage data suggests. The ROI case that justified the purchase was never tracked against actual outcomes. No one was assigned to do that. The momentum was visible in the activity data; the mirage was that activity meant the outcome was being achieved.

What it looks like when it works

The sales engagements that produce durable value, where the customer achieves the ROI they bought, renews without being pushed and calls back when a new problem emerges, share a set of organizational conditions that are rarely part of the sales process by design.

Before the deal closes, someone established a precise definition of success: not “improve customer response times” or “increase team productivity.” A specific business outcome, measurable at a defined point in time, with explicit criteria for what achieving it requires beyond the product itself. The organizational changes, the process redesigns and the decision authority shifts are named and owned before the contract is signed.

Someone established clear accountability for the outcome after the handoff: a specific person whose job it is to ensure the deployment produces the stated result, with the authority to intervene when it doesn’t. The project manager who runs the implementation fills a different role. If no one holds outcome accountability from the start, the system works at launch and fails quietly over time.

The workflows were redesigned around what the product actually requires, not wrapped around the existing process with the product installed on top. These two approaches look similar at deployment and diverge within months. The first treats the product as a participant in how work gets done. The second treats it as a layer added to how work already gets done.

The seller stayed engaged past close with the goal of ensuring the outcome, not managing the renewal. This is the distinction that separates sellers whose customers call them back from sellers who are always starting over. The engagement that produces trust is not the pitch but the period after the signature, when most sellers have moved on and the problems that determine whether the investment was worth it are being encountered for the first time.

These are organizational conditions, not technical requirements. The product cannot supply them. The contract cannot mandate them. They have to be established by someone, the seller, the executive sponsor or the implementation leader, who understands that the deal closing is not the outcome.

What this means for leaders building something different

The Why Change Fails series makes the case that transformation leaders are often focused on the wrong problems. The technology typically works. The frameworks are sufficient. The gap is in the organizational conditions that determine whether the tool, the method or the initiative can produce what it was designed to produce. The same case applies here. The sales methodologies are sufficient. The gap is in the organizational conditions that determine whether the customer achieves the outcome they purchased.

The cost of the current design accumulates in the places the measurement system isn’t looking. Customers who don’t achieve their expected ROI don’t renew, or renew at reduced scope, or require expensive intervention to salvage the relationship. Reichheld and Sasser found that cutting customer defections by 5 percent raised profits by 25 to 85 percent across the service businesses they studied.[4] Win rates accepted as fixed drive pipeline coverage requirements that consume resources pursuing low-probability opportunities, resources that could instead build the account depth and relationship quality that generate higher-probability ones over time. The system is not failing randomly. It is producing predictable, measurable costs that standard sales metrics are not designed to surface.

A different design is available. Examine the win rate as a system output, not an operating condition. Distinguish between opportunity types and invest in the conditions that generate high-probability pursuits rather than building coverage to absorb low-probability ones. Redefine success at the point of outcome, not the point of close. Build accountability for delivery into the sales role, not just the implementation role. Redesign the handoff so the information that determines whether a deployment succeeds actually transfers. Measure whether the customer achieved the ROI they purchased and tie something real to the answer.

None of that requires a new methodology. It requires a different definition of what the sales function is for. The current definition, close the deal, is precise, measurable and produces exactly what it is designed to produce. A different definition, ensure the customer achieves the outcome, produces something different. Some organizations are already redefining the finish line. Most haven’t made that choice explicitly, and the current win rate is what that choice looks like.

Notes

[1] Gartner, B2B buying group research: “six to 10 decision makers” for a complex B2B solution. See also Gartner press release, 7 May 2025, survey of 632 B2B buyers, reporting five to 16 people involved in a purchase across as many as four functions.

[2] Ronald A. Heifetz. Leadership Without Easy Answers. Harvard University Press, 1994.

[3] Standish Group, CHAOS Report series, 1994 to 2020, for the Iron Triangle measurement gap. “Creating organizational transformations: McKinsey Global Survey Results,” McKinsey Quarterly, August 2008, survey of 3,199 executives fielded July 2008. Statistic cited: among respondents whose transformation was intended to affect the whole organization, only 54 percent said the daily work routines of a majority of the workforce actually changed. The same survey found that about a third said their organization achieved a true step change in performance.

[4] Reichheld, F. F. and Sasser, W. E., “Zero Defections: Quality Comes to Services,” Harvard Business Review, September to October 1990. Finding cited: a 5 percent reduction in customer defections produced profit increases of 25 to 85 percent across a bank, an insurance brokerage and an auto-service chain. The multiples commonly quoted for acquisition cost against retention cost do not trace to a primary source and are not used here.

Every technology cycle produces the same moment.

A capability arrives that is genuinely impressive, and the organizational response is to treat it as the solution to problems that were never primarily technical. The capability solves a real problem, but not the one the organization actually has.

The first wave of ERP deployments promised integrated operations and a single source of truth. What failed, reliably, was not the software. It was the organizational conditions the software assumed: clear process ownership, consistent data definitions and the discipline to maintain both over time. The technology worked. The organizations that deployed it into broken conditions got broken operations, faster and at greater scale.

The cloud migration moment had the same pattern. The infrastructure worked. The costs didn’t improve as promised, not because the infrastructure was wrong, but because the organizational incentives, the governance architecture and the operating model that controlled cloud spend were not redesigned alongside the migration. The technology moved forward. The organization stayed put.

For AI it is the agent moment.

The pattern is repeating, this time with agents.

The promise is not wrong about what the technology can do. Where it goes wrong is what the technology can fix. Agents don’t resolve the organizational conditions that cause transformations to fail. They amplify whichever ones already exist, faster, at greater scale, with less visibility into the drift.

The question isn’t whether to deploy an agent. The question is whether the organizational conditions are in place that allow an agent to produce what you need.

What an agent actually requires

For the executive reader who hasn’t built one: an agent is not a smarter chatbot.

A chatbot waits for a question and returns an answer. An agent takes sequences of actions toward a goal, autonomously, observing its environment, deciding what to do next, acting on that decision and adjusting based on what it learns. The human approves the goal. The agent executes. That autonomy is the value proposition, and exactly where the organizational requirement lives.

Three things the technology cannot supply.

A goal defined precisely enough for the system to make tradeoffs without human intervention. An agent given a vague goal doesn’t fail to act. It acts confidently in a direction the organization didn’t intend. “Improve customer response times” is not a goal precise enough for an autonomous system. At what cost? By what means? What tradeoffs between speed and accuracy are acceptable? What decisions require human review before action? Every one of those unanswered questions is a decision the agent will make on its own.

A process clear enough to hand off. The process needs every step mapped, every handoff owned and every exception anticipated. The agent will encounter the same edge cases, ambiguous ownership and broken handoffs that humans encounter, and will handle them without the contextual judgment that lets humans work around dysfunction they’ve learned to absorb. An agent deployed into a process that runs on informal workarounds will expose every one of them.

A monitoring function with authority to correct drift. The agent’s outputs will drift from intent over time. This is a property of any system that adapts, not a defect to be fixed at launch. What determines whether drift compounds or gets corrected is whether someone owns the monitoring function: watching the gap between what the agent is doing and what was intended, at a defined cadence, with the authority and the knowledge to intervene. If no one is assigned to that function before deployment, the system works at launch. Three months later, no one can explain what it’s actually doing.

These are organizational design requirements. The agent won’t generate them.

Where it actually works, and why

There is one domain where AI agents are delivering on their promise at scale, reliably, across organizations of different sizes and maturity levels: software development. AI coding assistants and agents are producing measurable productivity gains, reducing defect rates, accelerating code review and shortening the cycle from idea to deployed capability. The results are real and documented.

The reason they work is not the technology. The reason they work is that software development is the rare organizational domain where every condition the technology requires was already in place before the agent arrived.

Software has a formal language with explicit rules. The agent knows what valid output looks like. Code either compiles or it doesn’t. Version control systems like Git provide a structured, documented record of every change: who made it, what it changed, when and why. Merge and review processes define exactly how changes get proposed, reviewed and integrated. Testing frameworks provide an objective, automated standard for what “good” looks like: tests pass or they fail. And the definition of success, what the software is supposed to do, is typically specified in requirements, acceptance criteria and user stories that can be evaluated directly against the output.

The agent isn’t producing the goal, the proof of correctness or the process. It’s operating inside a system that humans built over decades of hard-won software engineering discipline. Remove any of those conditions (vague requirements, no automated tests, no version control, no review process) and the AI agent’s output degrades or becomes uncontrollable in exactly the same ways agents fail in other domains.

Software development is not the exception that disproves the organizational readiness argument. It is the clearest demonstration of what the argument predicts: when the conditions are right, agents deliver on the promise. When they’re not, they don’t. The difference between software and the average enterprise deployment isn’t the technology. It’s the infrastructure of specificity and accountability that software engineering built before the agents arrived.

Most organizations have not built that infrastructure for the business processes they now want to automate.

The amplification problem

Organizations failing to get value from AI are not failing because the technology is weak.

McKinsey’s State of AI 2025 found 88% of organizations now deploy AI in at least one business function, yet only 39% report any measurable effect on enterprise EBIT. Deployment is outpacing business value realization by more than two to one. The technology that is failing to produce bottom-line impact is the same technology that demonstrably transforms the operations of organizations that have gotten the organizational conditions right. The variable is not the tool. The variable is the context the tool is operating inside.

Agents don’t change that failure condition. They accelerate it.

The Why Change Fails series describes five breakpoints: the specific organizational failure modes that determine whether a transformation produces durable value or visible activity. Each one maps directly to a failure mode in agent deployment.

Strategic Disconnection. The agent is given a goal that was never pressure-tested against what the business actually needs to achieve. A vague directive doesn’t produce vague results from an agent. It produces confident, efficient execution in the wrong direction, at machine speed. The months of slow drift that human execution produces compresses to days. By the time the gap between activity and outcome becomes visible, it has been running at scale.

Incentive Fragmentation. Leaders whose work is being transformed have no incentive to redesign the workflows the agent depends on. The fastest path is deployment around the edges of the existing process. The result is marginal improvement on a process that was already underperforming. The agent does its part; the surrounding structure ensures the output doesn’t compound into anything significant.

Process Friction. The agent doesn’t route around the broken steps in the process the way people who built workarounds over years know how to. It executes the broken process efficiently, at scale, automatically. The friction that was invisible because humans absorbed it becomes visible in the output data, at volume, on a timeline the organization didn’t plan for.

Technology Illusion. The demo is impressive. The proof of concept succeeds. The agent gets deployed into conditions the organization hasn’t prepared: undefined outcome criteria, unclear ownership, workflows that haven’t been redesigned to absorb what the agent produces. The gap between demonstration performance and production performance is attributed to the technology. The root cause is structural.

Momentum Mirage. The agent is running. Logs are filling. Tasks are completing. Every operational dashboard says deployment is succeeding. Drift is invisible without a monitoring function designed specifically to watch for it. The organization is watching the wrong signal. Activity is filling the dashboards while the meaningful signal, alignment between output and intent, has no one watching it.

The pattern is consistent across all five: the agent amplifies whichever breakpoints already exist. It does not resolve them.

Three questions before the first line of code

The GPS check (Goal, Proof, Steps) is a diagnostic from agent design that maps exactly to the organizational requirements that determine whether a deployment produces durable value. Any executive can answer these questions. The ones who can’t have identified the work that has to happen before deployment begins.

Goal. Can you define the outcome specifically enough that the agent would consistently produce the right result, not a defensible interpretation of it? Not “improve customer service.” What specific decision does the agent make? What tradeoff is it authorized to make on its own? What outcome, measured how, six months from launch, would tell you whether the deployment succeeded or failed?

If the answer is a direction rather than a definition, the organization hasn’t done the outcome precision work. The agent will run in the direction. Whether that direction leads anywhere useful won’t be visible until it’s too late to course-correct cheaply.

Proof. Can you describe what good output looks like specifically enough to catch bad output? Who reviews the agent’s outputs, at what cadence, against what standard? When the agent makes a decision you wouldn’t have made, how does that surface? The monitoring function has to be designed before deployment. Designing it after is like building the instrument panel after the plane is airborne.

Steps. Can you map every step the agent will run, including the handoffs, the exception cases and the points that require human judgment? The organization that can do this has redesigned the workflow around how the agent actually works, not wrapped the agent around the existing workflow. These are different architectures and they produce different results. The second one is almost always what gets built, because it’s faster to stand up. It’s also the one that quietly fails.

Three questions. The gap between “yes” and “not really” on any of them is the organizational work that has to happen before deployment starts.

What organizational readiness for agents actually looks like

Four conditions distinguish agent deployments that produce durable value from those that produce impressive demonstrations followed by quiet underperformance.

The outcome is defined at system level, not tool level. Not “deploy an agent to improve customer service resolution.” Reduce resolution time for tier-one issues by 40% within 90 days of deployment, measured by average handle time for tickets the agent closes without escalation, and here is the agent’s specific role alongside the process changes and the people changes that go with it. The system definition forces the organizational design work. The tool-level definition allows the organization to skip it.

Workflows are redesigned around how the agent actually works. Not the existing workflow with an agent inserted into it. What does the ideal process look like if the agent is a full participant from the beginning? Organizations that redesign workflows for agent-native execution consistently outperform those that retrofit an agent into an existing human-native process. The latter gets a proof of concept that degrades.

The monitoring function is named and owned before launch. A specific person, not a team, not the project manager, whose job includes watching the gap between what the agent is doing and what was intended, at a specific cadence, with the authority to flag drift and the knowledge to distinguish signal from noise. This function does not emerge naturally after deployment. It has to be designed and assigned before launch, because after launch there is always something more urgent than watching logs for drift that hasn’t caused a visible problem yet.

The incentive structure supports the change. The leaders and managers whose work is being transformed have a metric that rewards the new behavior, not just the metric that rewards the old behavior with a new tool added on top. Incentive Fragmentation is the most reliable predictor of which deployments stay marginal. It is also the condition that gets addressed last, because it requires the most organizational will to change and produces the least visible short-term friction when ignored.

These are not technical requirements. No engineer can design them into the system. They are organizational conditions, and the work of establishing them belongs to the leader who owns the outcome.

The right question before deployment

Most organizations ask: how do we deploy an agent?

That is the wrong starting question. It assumes the organizational conditions are in place and the only variable is the deployment approach. For most organizations in most deployments, that assumption is wrong, and the deployment will surface exactly which conditions are missing, at the speed and scale agents operate at.

The right question is: are the organizational conditions in place that allow an agent to produce what we need?

That question has a diagnostic. A pre-launch assessment of Goal, Proof and Steps, run honestly, without the pressure to reach “yes” before the board presentation. A named owner for the outcome and the monitoring function before the first line of code. A workflow designed for how the agent actually works, not a workaround designed to deploy faster. An incentive structure that rewards the change, not just the deployment.

None of those are technical tools. All of them are organizational design tools, the same ones that determine whether any transformation holds or quietly stops being fed.

The agent won’t save an organization that hasn’t done this work. It will make the gap between where the organization is and where it needs to be visible faster, and at greater scale, than any previous technology cycle has managed.

The organizations that do the organizational work first will build something that compounds. The ones that don’t will have very impressive demonstrations and very stable underperformance.

Notes

McKinsey QuantumBlack. “The State of AI in 2025: Agents, Innovation, and Transformation.” McKinsey & Company, November 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai. Figures cited: 88% of organizations deploy AI in at least one business function; 39% report measurable enterprise EBIT impact.