Forward Deployed Engineers and the Businesses That Cannot Hire Them

A few hundred words on why AI stalls

Claire Vo is chief product and technology officer at LaunchDarkly, and the founder of ChatPRD. On 12 August 2026 she posted on X an answer to a question she says she is asked often: why AI stalls inside companies ^S1.

The post is a few hundred words. It makes one claim with two parts, and it names the stall as a human problem rather than a model problem. We will notify Vo on publication.

Two reasons, and neither is the model

Vo gives two reasons AI stalls inside companies, and neither is a shortage of models. The first is capability. Adopting AI asks someone to reimagine the workflows of their job, their team and their company, then to swap in technology they barely understand or trust ^S1.

Asking whether AI can do a task is not enough. You have to rebuild the work from first principles, break your own habits, and persuade others to do the same. Most people, she argues, lack either the imagination or the hard skills, so they stall at writing documents, generating code and producing daily briefings ^S1. That stall is rational. Those are the jobs a person can finish tomorrow without blowing up the role they already have.

The second is will. Most leaders are not motivated to force change, and even those who know it is needed avoid the hard parts. She reports hearing "yes, I know we need to change, but..." followed by a list of fears: staff will quit, data will leak, costs will run away, quality will drop. Underneath, she suggests, sits a simpler sentence: they will have to tell the team that things are different now, and the team might not like it ^S1.

Her conclusion separates the two. The first problem yields to staffing and tools: internal forward deployed engineers, hack weeks, investment in internal tooling. The second sits with roughly five people at the top of a company, and no hire fixes it for them. "The blocker is never tools or intelligence," she writes. "Human systems, human problems" ^S1.

The diagnosis holds. The pod does not reach you

The diagnosis holds, and it is not a finding about the models. PwC's 29th Global CEO Survey of 4,454 chief executives across 95 countries found 56% had seen no significant financial benefit from AI to date. Only 12% reported both higher revenue and lower costs. CEOs whose organisations had built strong AI foundations first were three times more likely to report meaningful financial returns ^S2.

MIT's Project NANDA, in a July 2025 working paper analysing 300 public AI deployments, found 95% of organisations saw little or no measurable profit-and-loss impact ^S3. In the UK, government research across 3,500 businesses found 16% were using at least one AI technology, agentic AI sat at 7% of adopters, and limited skills were among the most cited barriers ^S4. All three findings describe the problems Vo names. None of them describes a failure of the models.

The stall also has the same shape as the one we described in Single-player AI and the multiplayer business: people doing the job in front of them, not looking to a future problem. The tools get used. The business does not change.

The market agrees with her first diagnosis, and has priced it. Executive search firm Christian & Timbers found the share of companies planning to hire forward deployed engineers rose from 5–10% in January 2026 to 70% by the end of the second quarter, against roughly 17,000 FDEs in the US market, of whom it judges only about 2,000 capable of delivering returns at enterprise scale ^S5. On 30 June 2026 AWS committed $1 billion to a new Forward Deployed Engineering organisation that will embed thousands of engineers with customers, designed so customers are self-sufficient when a deployment ends ^S14. OpenAI and Anthropic launched their own deployment ventures earlier in the year ^{S15 S16}.

That arithmetic is where her fix list strains. A pod of engineers per customer is an enterprise price. Christian & Timbers measures an elite FDE's worth in tens of millions of dollars of impact ^S5. A 40-person firm has no such sum to give back, so no vendor will send the pod. Vo's remedies for the first problem - internal FDEs, hack weeks, internal tools budgets - assume spare engineering headcount, which is what a 10-to-250-person business lacks. Her observation about the roughly five people at the top lands differently there too. In a small business those five people are the whole management layer. No one sits below them to carry the change, and no one sits above them to force it.

The FDE model also strains on its own advocates' terms. Andreessen Horowitz, defending the model, names the critics' case that a services motion limits scale, and prescribes automating as much of delivery as possible ^S8. VC Cafe states the condition for scale plainly. The model scales only when fieldwork becomes product, and an engagement that starts from zero is consulting, whatever the job title says ^S9. Legion Intelligence, writing from inside the defence software market, argues the model grows by adding people and leaves customers dependent on the engineers who understand the system ^S10. Palantir reached the same conclusion in practice. Its AIP Bootcamps take a customer from zero to a working use case in one to five days, because the engineering that once happened on a blank canvas now ships inside the product ^S11.

A platform does not solve Vo's second problem either. Pre-built workflows do not make an owner willing to tell their team that things are different now. That work still belongs to a person the owner trusts, in the room, whose job is the change rather than the code. Rick Manelius makes a version of this point in arguing the gap needs executives as well as engineers ^S12. Moving engineering into a product also trades range for repeatability. An FDE with a blank canvas can invent something no product contains, and for a business with a rare, high-stakes problem, the blank canvas wins. Our position is that the problems of most 10-to-250-person businesses are common rather than rare, and that a platform which has already solved them beats an engineer solving them again for the first time. That is a judgement, not a finding.

Already built, with a person on the change

Three implications follow for how we build and advise. They split Vo's two problems: the product carries capability, and a person in the room carries will.

The engineering belongs in the product. A business of 10 to 250 people cannot fund a blank canvas and does not need one, because its workflows - quoting, scheduling, chasing invoices, onboarding staff - repeat across thousands of firms like it. Building the connectors, agents and governance once, then installing them many times, removes the two costs the blank canvas carries into every engagement: the risk of building something for the first time, and the months it takes. Palantir's move to five-day deployments shows the direction ^S11. The difference is which market the product is built for.

The person in the room is a business role. Alexander Group, advising technology vendors on go-to-market strategy, concludes that direct FDE coverage below the enterprise is not economic, and that certified partners must fill the gap, with certification signalling the partner can deliver outcomes ^S13. That matches how we deliver. A certified consultant carries Vo's second problem, the human one, working directly with the handful of people who decide whether change happens. The platform carries the first. Where an edge case needs new engineering, it routes to the core product team, and once built, every client receives it. RedOS is built on that division of labour.

Vo's closing line is the standard the whole category should be measured against. If the blocker is never tools or intelligence, a delivery model should be judged by where it spends on the human work. The capital now going into forward deployed engineering spends it where a business can pay for a pod of engineers. The two problems Vo names do not stop at the enterprise boundary, and below it the answer has to arrive already built, with a person whose job is the change.