“[Most] enterprise AI pilots don’t fail for technical reasons. They fail because the people running them quietly want them to fail.”
Disagreements are nothing new. In fact, they’ve not only always been part of everyday life, but they’re also both normal and healthy. It’s good to have opinions that differ from those of friends, colleagues and industry peers.
Better still, it’s good to discuss them.
Yet, we seem to be doing less and less of that. In an age of increasingly polarised views, it’s often easier to surround ourselves with people who already agree with us than engage with opinions that make us uncomfortable. After all, the circles we find ourselves in and the social media we expose ourselves to tend to place us in self-fulfilling loops, offering us opinions that match our own and further the thoughts we already have. So much so that it can end up feeling like our views are both common and reinforced by popular opinion.
But that doesn’t move conversations forward. All it does is create deeper divides and fewer opportunities to challenge our own thinking.
That’s the idea behind Quite Contrary, TechRound’s new series dedicated to hot takes, unpopular opinions and perspectives that might make people shift uncomfortably in their seats. Every edition starts with one deliberately contrarian viewpoint, and then we open the floor to the wider TechRound community.
This Week’s Contrarian
This week, the hot take comes from entrepreneur and AI pioneer Chase W. Hughes, who argues that most enterprise AI pilots don’t fail because of bad technology, poor models or weak prompts. Instead, he believes that they fail because the people running them often have little incentive to make them succeed.
It’s a bold claim, particularly when businesses are investing billions into AI while still struggling to prove returns.
So, is Hughes identifying an uncomfortable truth that nobody wants to talk about, or is he oversimplifying a much more complicated problem?
Chase W. Hughes
Chase W. Hughes is a three-time founder who built ProAI, one of the first commercialized GPT products, used by 300,000+ businesses and institutions from the Abu Dhabi Investment Authority to Keiretsu Forum, and sold it, bootstrapped, in an 18-month run to seven figures. He holds a patent-pending multi-agent research system filed in early 2023.
Chase’s Hot Take
“[Most] enterprise AI pilots don’t fail for technical reasons. They fail because the people running them quietly want them to fail.
“MIT’s Project NANDA study (The GenAI Divide, 2025) found ~95% of enterprise generative-AI pilots never deliver a measurable return. The industry reads that as a model problem, a data problem or a prompt problem. It is neither. It is an incentive problem wearing a technical costume.
“Look at who actually runs a pilot. It is usually a mid-level operator inside the function being automated. If the pilot fails, their job is at risk because the company falls behind. If it succeeds, their job is at risk because the work they own gets absorbed. There is no outcome where they win, so you get compliance without conviction: the pilot is technically staffed, technically running and quietly starved.
“The second reason is structural. Legacy stacks were built for fixed, predictable integrations, and we now live in a free-form API and MCP world where an agent is expected to find and solve its own problems. Most enterprises are stuck in the transient in-between, running new-world software on old-world plumbing.
“Fix the incentives before you fix the pipeline. The technology is rarely the bottleneck.
Here’s What the TechRound Community Had To Say
- Trevor Longino: CrowdTamers and GreenAI.studio
- Vitaly Koval: Co-Founder at GoGlob
- Nikhil Garg: Fractional CTO
- Alex Debelov: Founder and CEO of Go X
- Phillip Hamnett: CEO of TalentAid
- Prasanna Kumar Kandregula: Senior Software Engineer at M&T Bank
- Sivan Kadosh: Fractional Chief Product Officer for SaaS
- Tom McNamara: Founder and CEO at Atoro
- Lily Stoyanov: CEO at TFY (Transformify)
- Henry Bell: Director of Research at Vendorland
- Keith Yunxi Zhu: Chief Executive at TKEG Expat
- Luke Sandelands: Founder at Stack Architect
- Tobias Trost: CEO and Founder of ERP Pilot and Senior SAP S/4HANA Consultant
- Patrick Gibbs: Founder at Epiphany Dynamics LLC
- David Tyler: CEO at Outlier Technology
- Egiziago Cioffi: IT/Enterprise Architect and CEO, SynSphere
- David Heiny: Co-Founder and CEO of SimScale
- Tim Doll: CEO of Precocity
Trevor Longino CrowdTamers and GreenAI.studio
“Enterprise AI pilots usually fail before the first integration is written. Conway’s Law tells us why: the system you build will mirror the organization that builds it. If the org chart puts the pilot inside the function threatened by automation, the incentives are already working against the project. The pilot can be technically sound and still be quietly starved. That doesn’t mean employees want the company to fail. Most people want the company to win. They just don’t want to volunteer themselves as the cost of winning. Give the people closest to the work a better role after automation, and they’ll surface the problems that matter.
“Leave that vague, and every prompt tweak becomes theater. Richard Hamming put the it bluntly: “you get what you measure for.” Most pilots don’t define a properly measurable S.M.A.R.T. business outcome before they start. So they get activity, demos, and a slide deck. They measured nothing useful and lo, they got nothing useful. Fix the org chart and the scoreboard first. The technology comes after. I run AI pilots for enterprise often enough.
“When they succeed, the people doing repetitive research and content operations would be worse off unless we had planned their next role so we tell them what their new opportunity will be before anything gets turned on. Involve them before the build, let them define what should stay human, and measure whether the system removes drudgery rather than moving it into review queues. The pilot needs to make their work better, not leave them wondering when they’ll be riffed and looking for work.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“I roll out AI pilots in my company quite frequently, and I also roll out AI pilots in other companies quite frequently. The most important bit to getting team buy-in is to not focus on how you are worse off.
“I will give you an example: a common thing you do with AI is build an automation that will then take away a big chunk of work. For example, the designer in my company, we now tend to create ads with AI graphics instead of handmade illustrations and layouts. You can look at that and say, “Oh man, I’m a designer. I don’t have as much of my job anymore. Now I’m concerned I’m going to lose my job.” What you say instead is, “Hey, you aren’t doing this anymore, or you won’t be doing this anymore soon. Let’s make sure we find a valuable thing that you can do that will take up the time difference.”
“For that same designer, we gave them more freedom on generating new stuff with AI graphics, AI videos, animated explainers, these types of things, a whole new skill. It is time-intensive but ultimately not very rewarding part of their job gets taken away, but they get to do a new thing that excites them more. It is important that you prepare that before you blow out the automation. You can get them investigating the new thing. Ideally, you can get them already trying the new thing while you are building the support for the pieces underneath it.
“Now, the key thing here and in general with AI use in business is: if your team isn’t flexible, AI will not be accepted. If your team is excited to try new things, AI can be successful.”
Vitaly Koval, Co-Founder at GoGlob
“I partially agree. Running advanced, non-deterministic agentic workflows on fragile legacy codebases is indeed a major architectural bottleneck. However, I don’t believe enterprise AI pilots fail primarily because employees quietly want them to fail. That only becomes true when organizations introduce AI as a headcount reduction initiative rather than a productivity initiative.
“When leadership positions AI as a replacement for people, resistance is inevitable. But when AI is intentionally designed for augmentation, that incentive problem largely disappears. AI should eliminate repetitive, low-value work, such as drafting boilerplate, organizing information, or generating test scaffolding, while leaving architecture, judgment, and final approval firmly in human hands.
“We’ve seen this firsthand. In one software engineering organization where AI adoption had stalled at 28%, introducing a standardised, governed Agentic SDLC increased daily active usage to 91% within 12 weeks. The issue wasn’t passive sabotage. It was a structural failure of workflow integration, governance, and change management.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“If our recruitment automation pilot had succeeded completely, our recruiters could have been worse off if they believed their primary value came from manually spending four to six hours searching databases and screening candidates.
“Before writing a single line of code for our semantic ML pipeline, we deliberately reframed the recruiter’s role from transactional filterer to relationship builder. The AI system would rank and prioritize candidates, but it would never make hiring decisions. Human recruiters remained responsible for relationship building, cultural assessment, and final hiring judgment.
“By designing the workflow around augmentation rather than replacement, we shifted daily work away from repetitive administrative tasks while preserving the human responsibilities that create real business value. That approach transformed what could have become passive resistance into immediate trust and strong internal adoption.”
Nikhil Garg, Fractional CTO
“Agree with the incentive diagnosis, but I’d push on the framing slightly. In 13+ years building SaaS and working as a fractional CTO, I’ve seen three failure modes, not one:
“1. The operator problem (the one the article names) — the pilot lead owns the function being automated and has no upside if it works. Real. Constant.
“2. The sponsor problem — the VP who greenlights the pilot doesn’t own the operational pain. They want a win on their deck, not a working workflow. They disappear after launch.
“3. The plumbing problem — agents are being asked to operate in a free-form MCP/API world while the enterprise stack was built for fixed, predictable integrations. That’s infrastructure debt wearing a capability problem costume.
“The incentive fix matters. But you can’t fix the incentive without also fixing who owns what after the pilot ends.
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“Almost always the manager whose workflow is being automated. The fix I’ve used: before any pilot starts, explicitly name that person, bring them in as a co-owner of the success criteria, and tie their post-pilot metric to business outcomes — not headcount. If you can’t answer this question before kickoff, your pilot is already in trouble.
Alex Debelov, Founder and CEO of Go X
“I agree with the diagnosis and I want to sharpen it. The NANDA finding is not a scandal, it’s an accounting error. The industry keeps measuring pilots by whether the model worked, when it should measure whether the org allowed the model to work. The mid-level owner is not sabotaging out of malice … they are optimizing rationally against the incentive they were handed.
“If the pilot succeeds, their headcount, their budget, and their political oxygen shrink. Compliance without conviction is the predictable equilibrium. The plumbing point is right too. Enterprises are running MCP-era agents on ERP-era pipes and calling the friction a “model problem.” The fix is not a better prompt. It’s an incentive redesign paired with an integration budget. Fund the humans through the transition, or the transition doesn’t happen.
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“At Go X, the honest answer is our business-development function. Our AI voice outbound went from roughly $100 to $200 per booked meeting down to a fraction of that once the agent handled it end-to-end. In one 15-host launch cycle we went from $1,500 in labor to about $65. So on paper the BDR seat is worse off.
“What I did before the pilot started, and this matters a lot: I told that person, in writing, exactly what the endpoint looked like and gave them the first shot at being the operator of the agent instead of the operator being replaced by the agent. They now run the agent stack, tune the prompts, monitor the funnel, and own the KPI. Same person, higher-leverage seat, more pay. Their old job disappeared. Their career didn’t.
“That is the piece most enterprises skip and it’s why their pilots die. You cannot ask a human to enthusiastically automate themselves out of a job. You can absolutely ask them to enthusiastically become the person who operates the automation. The framing is a one-line difference and a career-long consequence.
“The related mistake I see everywhere: companies run the pilot inside a function, but the reward structure still lives in the old org chart. So the successful pilot creates a person with new skills, no new title, no new comp band, and a boss whose team just shrank. That person quits within six months and takes the institutional knowledge with them. The pilot “succeeded” and the company is worse off. NANDA would count that as a win. It isn’t.”
Phillip Hamnett, CEO of TalentAid
“I disagree, though not entirely. We are a small company, I am not speaking from inside a big enterprise. What I can tell you is that we have no incentive problem whatsoever. I decide what we try, and the agents running our marketing and finance work are not absorbing anything a person was hired to defend. A good number of the things we tried still did not work. So incentives cannot be the mechanism, or everything we attempted would have landed.
“What actually killed ours was that we started without writing down what a good result would look like. With no bar there is nothing to pass and nothing to starve. It quietly stops. Incentives are also a far more comfortable diagnosis than scope, because if the problem is politics then the plan was fine all along.
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“Nobody, and I should be straight about why. We never staffed the work the agents took on, so there was no job underneath it to lose. That makes us a poor test of the argument rather than a refutation of it.
“The cost landed somewhere else. Once agents do the producing, the people around them spend their day checking output rather than making things, and that is a less satisfying job than the one they had before. What did I do about it beforehand? Nothing. I did not see it coming and only noticed once we were already running that way. I still do not have a tidy fix, other than trying not to let reviewing fill someone’s entire day.”
Sivan Kadosh, Fractional Chief Product Officer for SaaS
“I half agree, and I think the half that is wrong matters.
“The incentive read is right. The idea that operators quietly want pilots to fail is not what I have seen. Nobody sabotages anything. They deprioritise it, which looks the same from the outside and feels completely reasonable from the inside.
“The failure is further upstream. Most AI pilots launch without a business number attached, so there is nothing to defend when the quarter gets busy. At a martech company I worked with, only 35% of roadmap work connected to the stated strategy. The other 65% was stakeholder opinion and legacy commitment. Better models would not have touched that. We refused to fund any initiative that could not name the metric it moved, which took strategy-aligned work to 90% and cut feature waste by 30%.
“Attach a number and an owner before you attach a model.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“My product managers would be worse off, and I knew it going in. If AI drafts the first version of every spec, the craft they were promoted for gets commoditised. What I changed before starting was what the role is measured on. They stopped being judged on documents produced and started being judged on whether the outcome moved. That reframing is the actual work. Skip it and you get a pilot nobody defends.”
Prasanna Kumar Kandregula, Senior Software Engineer at M&T Bank
“I agree with parts of the statement, but I don’t think incentives are the only reason AI pilots struggle. From what I’ve seen working on enterprise technology projects in banking, insurance, and financial services, most failures come from a combination of people, process, and technology.
“Take payment exception handling or treasury reconciliation as an example. Today’s AI can identify anomalies, recommend actions, and significantly reduce manual effort. But if the operations team doesn’t trust the recommendations, the business process isn’t redesigned, or leadership hasn’t defined what success looks like, the pilot will lose momentum regardless of how well the model performs. On the other hand, I’ve also seen technically promising projects slowed down because legacy systems and fragmented data made integration far more difficult than expected.
“Successful AI adoption isn’t just about better models or better infrastructure. It’s about giving employees confidence that AI will help them do their jobs better, not replace them, while making sure the organization is ready to support the change.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“Ideally, no one should be worse off. Before starting any AI initiative, I believe it’s important to be transparent about why we’re implementing it. The goal should be to remove repetitive, low-value work—not the people doing it.
“In financial services, if AI automates tasks like transaction reconciliation, payment exception routing, or document processing, those employees can spend more time on customer interactions, investigating complex cases, risk analysis, and improving business processes. We involve end users early, explain how their roles will evolve, provide training, and ask for their feedback throughout the pilot. When people see AI as a tool that supports their expertise rather than replaces it, adoption becomes much easier and the business sees better long-term results.”
Tom McNamara, Founder and CEO at Atoro
“I don’t think the individuals want the pilots to fail. Traditional reporting and management structures just aren’t set up for unconstrained productivity. Sign-off is the killer of everything. You put an AI workflow in and the bottleneck simply moves to the management sign-off layer, and to what end? The work gets done faster and then sits waiting on someone. So no, I wouldn’t say individuals want these pilots to fail. The management systems that are in place are not set up to incorporate them, full stop.
“The way through it is to treat an AI agent as a direct report. Which team absorbs it? Where does it sit in the team structure? What tasks does it do, and how does that feed the bigger objectives of that team? Those are the questions you’d ask about any new hire, and almost nobody asks them before a pilot starts.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off, and what did you do about that before the pilot started?
“This feeds straight back into the first answer. If you haven’t planned it out across the team, that is exactly where you end up. Is this AI coming in to replace people? Is it going to do somebody’s work for them, or is it going to land a load of requests on their desk? That last one is the one that catches people out, because it looks like a win right up until the extra volume arrives on one person. The planning piece is key. Work out which team absorbs the agent and what it is accountable for, and you know who is affected before you start rather than after.”
Lily Stoyanov, CEO at TFY (Transformify)
“Mostly right, and it names the part everyone dodges. A pilot run by the person whose job it automates has a quiet incentive to stall, and no amount of better prompting fixes a human who is protecting their role. But I would push back on the framing. It is not that people secretly want it to fail, it is that leadership built a game where failure is the only safe move for them. That is a design failure at the top, not sabotage in the middle. You fix it by changing what the operator is measured and rewarded on before the pilot starts, and by being honest that their role will change rather than vanish. The legacy-stack point is real too, but incentives are the first domino. Fix those and the plumbing becomes an ordinary engineering problem.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off, and what did you do about that before the pilot started?
“Honestly no one, and that was deliberate. We designed TFY so AI carries the repetitive load and people own judgment, so when automation wins the team gets freed for higher-value work instead of replaced. In a badly designed version the person worse off would have been whoever owned manual matching or manual reconciliation, so we moved them into oversight and exception-handling before we automated, not after. The trick is to tell people up front what the machine will take and what it will hand them back.”
Henry Bell, Director of Research at Vendorland
“I partly agree, but I’d frame it differently. The real story isn’t that people want enterprise AI pilots to fail—it’s that organisations often underestimate how much organizational change successful AI adoption requires. Technical challenges are becoming easier to solve than questions around ownership, incentives, governance, and workflow redesign. If employees aren’t shown how their roles will evolve, it’s understandable that AI is perceived as a threat rather than a productivity tool.
“At the same time, technical barriers haven’t disappeared. Many organizations still struggle with fragmented data, legacy systems, and integration complexity. In practice, AI pilots succeed when organizational readiness and technical readiness evolve together. The organizations seeing the strongest results align executive sponsorship, process redesign, and employee incentives before they scale the technology. AI doesn’t fail because the models aren’t capable enough; it fails when implementation is treated as a software project instead of a business transformation.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off, and what did you do about that before the pilot started?
“The people most affected would likely be those performing repetitive coordination, manual processing, or routine content creation. That shouldn’t come as a surprise after deployment—it should shape the pilot from day one. Organisations should redefine roles before scaling AI so employees understand where they create greater value. Successful AI adoption is less about replacing roles than redesigning them.”
Keith Yunxi Zhu, Chief Executive at TKEG Expat
“Mostly disagree. MIT’s own report undercuts sabotage. It attributes the 95%-zero-return finding, against $30–40 billion of enterprise GenAI investment, to a learning gap — tools that forget your corrections and never make it into the actual workflow. It documents a shadow AI economy: employees at over 90% of surveyed companies use personal ChatGPT or Claude for work; only 40% bought an official LLM subscription. Workers adopting AI faster than their employers is the opposite of quietly willing it to fail. The statement’s plumbing half holds real truth; much of that learning gap is integration. But the missing incentive is usually simpler: nobody published a bar the system had to clear. Most pilots never state what the system must score before it earns decision rights. That’s a governance failure, not mutiny.
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“Our screening reviewers. A fully successful pilot would have absorbed the reads that team owns. Here’s what we did about it. Before the essay classifier could touch a production decision, the bar was 94% average precision; trained on 408 labelled samples, it reached 77.9%. It missed; we cut it back to a human-review flag built on its Poor-label confidence. It never got auto-reject rights. Every hiring call stayed human; the time savings came from routing and paperwork, not judgment calls. One AI we keep in production, our internal handbook assistant, answers questions. It doesn’t decide anything.”
Luke Sandelands, Founder at Stack Architect
“This statement correctly identifies the structural mismatch, but the underlying failure is architectural rather than political. Legacy enterprise systems rely primarily on deterministic execution, explicit schemas, and predictable state boundaries. Generative AI models and agentic protocols like MCP operate on non-deterministic probabilities. When companies bolt probabilistic software onto legacy REST APIs without intermediate state validation or event-driven orchestration, the integration fails at the boundary layer.
“The operator running the pilot isn’t deliberately sabotaging it, they are forced to manually verify every non-deterministic output against brittle legacy databases. That manual validation creates a severe operational bottleneck, destroying the return on investment. Until enterprises replace fragile polling and middleman APIs with deterministic, event-driven data pipelines that enforce schema validation at ingestion, AI agents will remain stuck in experimental sandboxes.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“Engineers assigned to writing boilerplate glue code and manually mapping third-party API webhooks would see their day-to-day responsibilities eliminated. Before initiating pilot projects, we re-scope those roles away from manual integration maintenance toward data architecture and schema governance.
“Instead of fixing broken payload mappings, their focus shifts to building server-side infrastructure and defining strict validation boundaries for autonomous agents. They move from reactive maintenance to owning the core system plumbing.”
Tobias Trost, CEO and Founder of ERP Pilot and Senior SAP S/4HANA Consultant
“I mostly agree. In the companies I’ve worked with, AI pilots stall when the person asked to champion the workflow sees upside for the business but no clear upside for their own role, so the project gets polite support and very little follow-through.”
The technology is rarely the bottleneck. Do you agree?
“Yes. The technical issues are usually solvable, but the harder part is deciding who owns the new workflow, who signs off on risk, and what happens to the manual work when the pilot starts saving time.”
Do you disagree?
“I disagree with making incentives the only explanation. I’ve seen legacy ERP and fragmented process design slow automation badly, especially when teams want an AI agent to work across systems that were never documented cleanly.”
Are you on the fence?
“I would narrow the claim. Incentives and process ownership break more pilots than model quality does, yet weak system architecture still matters once a pilot moves beyond a controlled demo.”
Who on your team would be worse off for it, and what did you do about that before the pilot started?
“At a Silicon Valley scaleup, the people most exposed were the operators doing repetitive finance and support tasks. The only approach I’ve seen work is naming that risk early, then redefining success around higher-value work before the pilot starts.”
Patrick Gibbs, Founder at Epiphany Dynamics LLC
“I agree with most of this, and I’d push it further. I build these systems for small businesses, not enterprises, and the incentive problem still shows up without any internal politics. There’s no mid-level operator protecting turf at a two-person company. The failure mode looks different: the pilot dies because nobody owns what happens after the demo. A founder gets excited about a working prototype, goes back to running the business, and the agent never gets the follow-through, edge-case handling, or monitoring it needs to survive contact with real customers. The technical build is the easy part. Deciding who owns the thing after launch, and what happens when it’s wrong, is the part almost nobody plans for before day one.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“At my scale, that question is really about my clients’ teams, not mine. Before I automate a task that used to belong to a person, I ask the owner what that person’s new job becomes, and I don’t ship the agent until there’s an answer. If the honest answer is that the role goes away, that’s fine, but it has to be said out loud before launch, not discovered after.”
David Tyler, CEO at Outlier Technology
“The incentive argument is real, but it’s presented far too absolutely. AI pilots fail for many of the same reasons digital transformation projects have failed for decades: poorly defined business problems, unclear success metrics, weak executive sponsorship, poor data quality, difficult integration, and unrealistic expectations. Individual incentives can certainly undermine adoption, but claiming that people “quietly want them to fail” is a broad assertion that requires much stronger evidence than a single failure-rate statistic. The opposite is often true: many teams actively pursue automation because they’re overloaded and want repetitive work removed. AI succeeds when organisations redesign processes, align incentives, invest in change management and choose problems where the technology genuinely adds value. It’s rarely a purely technical problem, but it’s rarely a purely incentive problem either.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“If your AI pilot succeeds automatically [and that] makes someone worse off, then you’ve already made a management decision, not a technology decision. Too many organisations frame AI as synonymous with headcount reduction because that’s the fastest way to improve the next quarterly balance sheet. But that’s a choice, not an inevitable consequence of automation. The organisations seeing the most sustainable returns tend to use AI to remove low-value work, increase capacity and improve quality, giving people more leverage rather than simply fewer colleagues. If employees assume success means redundancy, that’s not evidence they secretly want the pilot to fail. It’s evidence they’ve learned from how previous “efficiency programmes” have been handled.”
Egiziago Cioffi, IT/Enterprise Architect and CEO, SynSphere
“Half right, and the right half is the half nobody manages. The incentive trap is real: the person asked to pilot the automation of their own function has no winning move, so you get compliance without conviction. But “quietly want them to fail” overstates it. This is rational self-protection, not sabotage, and the distinction matters, because you fix it with honesty about roles after success, not by hunting for saboteurs. Where I disagree: ‘the technology is rarely the bottleneck.’
“In our deployments, the bottleneck is often brutally technical: data the model cannot reach, permissions it must respect, integrations that do not exist yet. Old plumbing is a real blocker, not an excuse. So fix the incentives first, yes, but do not wave away the pipeline. Most failed pilots die of both, in that order.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off, and what did you do about it before the pilot started?
“When we deployed an Azure OpenAI assistant that now auto-resolves about 60% of a services client’s inbound emails, the people most exposed were the staff who used to handle those emails. Before we started, we did two things. We had leadership commit, out loud, that freed capacity would be redeployed to higher-value work (complex cases, proactive client outreach), not cut. And we put those same people in charge of training and supervising the assistant, so their expertise became the product instead of being replaced by it. Name the person who loses before the pilot begins, give them a role in the outcome, and have leadership guarantee that success means redeployment, not redundancy. Skip that, and you have designed your own quiet failure.”
David Heiny, Co-Founder and CEO of SimScale
“No, most engineering leaders want Enterprise AI pilots to succeed and 99% expect them to deliver measurable returns within 12 months.1 Companies are setting pilot KPIs, including defaults to use AI for at least 50% of projects, and pilot leaders are accountable. Failure is a far greater risk than success.
“More pilots are launching than ever, 80% of engineering organisations have live pilots. Those running them are seeing the benefits to productivity, quality, innovation, and team morale. 2025 research data also showed massive appetite and openness for AI adoption at the mid-level, and that this level considers AI pilots as an opportunity for engineering innovation at pace, not job removal.
“Legacy technology stacks are an issue; the most successful pilots are being run by companies with cloud-native infrastructure. But the leading AI adopters are powering through these blockers.”
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“The success of a pilot project won’t make anyone on an engineering team worse off overnight. What we’ll likely see is a reduction in new engineers coming through with siloed specialisms. For example, at the moment simulation is still considered something only a small handful of specialist engineers can do. AI is already democratising access to these skills, and this will result in AI-native all-rounders who can handle specialist tasks – like product design space explorations – and speed through engineering workflows, enabled by AI.”
Tim Doll, CEO of Precocity
“The 95% figure is real and I cite it myself. But compliance without conviction is the wrong diagnosis. Look at shadow AI: Microsoft and LinkedIn’s Work Trend Index found most knowledge workers already use AI at work, largely on tools IT never approved. The conviction exists, it just isn’t pointed at the pilot.
“What I call ‘AI FOMO’ explains more. Boards ask for an AI strategy before anyone names a business problem, and the pilot inherits that vagueness. 81% of large financial firms admit competitive pressure rather than strategy is driving their spend. The test I use: would you still run this project if it didn’t have AI in the name? Most pilots fail it.
“Fix the problem definition before the incentives or the pipeline.
If your AI pilot succeeded completely tomorrow, who on your team would be worse off for it, and what did you do about that before the pilot started?
“We recently went through a pilot program of our own after recognizing that AI had fundamentally reshaped an entire practice area within our consultancy. To stay ahead, we launched a rigorous training and mentorship initiative to ensure that employees whose roles were most at risk wouldn’t be outpaced by the competition.
“We focused on mindset first and methods second. Our team needed to understand that the way they had worked for most of their careers had fundamentally changed. The hand only does what the head believes, so getting the mindset right was our first priority.”
