If you search for "forward deployed engineer" on any job platform today, you will find something that did not exist three years ago: hundreds of open roles, across dozens of companies, paying salaries that reflect genuine scarcity. Palantir built the template. Anduril adopted it. Scale AI, Glean, Cohere, and a growing list of enterprise AI vendors have all built FDE functions of their own. And in July 2026, Microsoft announced Frontier Company: a $2.5 billion operating unit with 6,000 engineers and one mandate, to embed directly inside enterprise customers and get AI actually working.
The FDE role is not a trend. It is a structural response to a real problem. Enterprise AI fails at the last mile, not the model layer. The model is rarely the constraint. The constraint is the distance between what AI can do and what a specific organization, with its specific data, its specific workflows, and its specific people, actually needs. That distance can only be closed by a human who is present, trusted, and capable of building quickly.
That is what an FDE is. And right now, there are not enough of them.
What Is Actually Driving the Demand
The demand is not coming from companies that are experimenting with AI. It is coming from companies that have already run pilots, seen some work and most fail, and are now trying to understand why the failures happened and how to prevent them at scale. That question does not have a vendor answer. It has a people answer.
Three forces are accelerating the demand simultaneously. First, the cost of building AI pilots has dropped to near zero. Any capable engineer can assemble a working prototype in days using available APIs and open-source tooling. That has created an explosion of pilots, which has created an explosion of stalled deployments, which has created urgent demand for people who can diagnose and fix them. Second, enterprise AI budgets are now large enough to justify dedicated deployment resources. AI is no longer being funded from innovation slush funds. It is on the CFO radar, which means it needs to show returns, which means it needs people accountable for making it work. Third, the competitive pressure between vendors has shifted from model quality to deployment quality. The companies winning enterprise contracts are not the ones with the best models. They are the ones with the best field teams.
The FDE is the field team. And right now, demand is outpacing supply across the industry.
What Most FDE Candidates Are Missing
Here is the uncomfortable reality. The technical bar for the FDE role is lower than most people expect. The ability to build with LLM APIs, connect data sources, and ship a working prototype is necessary but no longer rare. The supply of people who can do that has grown significantly over the past two years. That is not the bottleneck.
The bottleneck is enterprise depth. And most people who are trying to enter the FDE role have not been taught it, have not practiced it, and in many cases do not know it is the thing they are missing.
Enterprise depth is not a vague quality that comes with age. It is a specific set of knowledge layers about how large organizations make decisions, approve projects, manage risk, and change behavior. Each layer is learnable. None of them are taught in computer science programs. Most are not taught in MBA programs either, at least not in the form that an FDE actually needs them.
The FDE candidates who fail in the field are almost never failing because they could not build the thing. They are failing because they built the wrong thing, scoped it to the wrong timeline, missed the stakeholder who had the real veto, or handed off something that the receiving team could not operate. Every one of those failure modes is a gap in enterprise depth, not a gap in technical skill.
The Four Layers of Enterprise Depth
Enterprise depth is not one thing. It is a stack, and each layer has to be understood before the next one makes sense. Here is what that stack looks like, and what it means for how an FDE actually does their job.
Enterprise organizations do not buy things the way individuals do. They have fiscal year cycles, budget approval chains, opex versus capex distinctions, procurement vendor lists, and security review queues. An FDE who does not understand this layer will scope a pilot to the wrong size, price it against the wrong budget owner, and miss the approval window. The budget layer determines whether a project is even possible before the first line of code is written. An FDE who maps this in the first meeting, before scoping anything, is operating at a fundamentally different level than one who discovers it during the demo.
Every enterprise project has an official approval chain and an actual approval chain. These are rarely the same thing. The CTO who requested the engagement is often not the person whose objection can kill it. The VP of Operations who was not in the kickoff meeting often is. The IT security team, the legal team, the compliance officer, the line manager whose team will actually use the tool: each has the ability to stop a project that has no formal authority over it. An FDE who learns to identify and engage these stakeholders before they become blockers turns a 12-week sales cycle into a 6-week one. An FDE who discovers them at the demo stage loses the deal or resets the timeline. The stakeholder map is not politics. It is engineering for organizational reality.
In most enterprise AI deployments, the compliance review happens at the wrong time. It happens after the prototype is built, before the approval decision, at the point where changing the architecture costs the most. The reason is that FDEs who lack this layer do not ask compliance questions in discovery. They treat legal and security as a late-stage hurdle rather than an early-stage design constraint. An FDE who understands this layer asks the right questions on day one: what data classification applies to the outputs, where do the model responses go and who sees them, is this use case subject to any regulated decision framework, what would the audit trail need to look like. Those questions are not legal advice. They are architecture inputs. Getting them early means building something that can actually be approved.
A pilot that users do not adopt is a pilot that does not scale, regardless of technical quality. The change management layer is the understanding that end-user adoption is not a communication problem or a training problem. It is a design problem. People do not change their workflows because they are told to. They change when the new way is easier than the old way, when the incentive structure rewards the behavior, and when the people they trust have already made the switch. An FDE who designs a pilot around existing workflows rather than ideal workflows builds something that spreads on its own. An FDE who ignores this layer builds something that works in the demo and dies in the rollout. The difference between these two outcomes is rarely about the model. It is almost always about whether the FDE understood how the organization actually works before they started building.
Why These Layers Are Teachable
The most important thing to understand about enterprise depth is that it is not a personality trait and it is not purely a function of time. It is a set of mental models, and mental models can be taught. The reason most FDEs lack them is not that they are incapable of learning them. It is that no one has taught them, because the field is new enough that there is no established curriculum for what an FDE needs to know beyond the technical stack.
The budget and procurement layer can be learned by studying how enterprise purchasing actually works: the role of procurement departments, the difference between a PO-based purchase and a contract-based one, how to read a fiscal year calendar, and what makes a business case fundable. None of this requires years of enterprise experience. It requires deliberate study of a domain that most technical people have never been exposed to.
The stakeholder map layer can be learned by practicing a specific discovery methodology: asking who else has a stake in this outcome, who can say no, whose team will be affected, and what each of those people's incentive structures look like. This is a skill that gets faster and more accurate with repetition, but the framework can be taught in a single session and applied from day one.
The compliance and risk layer can be learned by understanding the regulatory environments of the verticals you operate in, the basic principles of data governance, and the questions that security and legal teams consistently raise. An FDE who spends a week studying HIPAA is not a healthcare lawyer, but they are an FDE who will not build the wrong architecture for a hospital customer.
The change management layer can be learned by studying how workflow adoption actually works: what behavioral economics says about habit formation, how to design for existing behavior rather than ideal behavior, and how to identify the early adopters inside a customer organization whose visible success will pull others in. These are learnable frameworks, not mysteries that only reveal themselves after a decade of consulting work.
What This Means for the Companies Hiring FDEs
If you are building an FDE function, the instinct is to hire for technical ability and assume the enterprise side will come with experience. That instinct is understandable and it is wrong. Experience does not automatically produce enterprise depth. People accumulate experience without extracting the right lessons from it all the time. What produces enterprise depth is a combination of experience and a framework for making sense of that experience.
The companies that will build the most effective FDE functions are the ones that treat enterprise depth as a trainable skill and build it into their onboarding. Not as a soft-skills module appended to the technical training, but as a core competency with the same rigor as technical onboarding: specific frameworks, specific vocabulary, practice scenarios, and assessment against real customer situations.
The companies that skip this step will hire people who can build quickly and get stuck frequently. The engagement cycles will be longer than they need to be, the failure rate on pilots will be higher than it needs to be, and the reason will rarely be visible in any postmortem because no one will name it. They will say the customer was difficult, or the data was not ready, or the stakeholders were not aligned. Those are descriptions of the symptom. The cause will be an FDE who did not know how to navigate the organizational layer.
What This Means for the People Who Want to Become FDEs
The technical bar is not dropping. It is a necessary condition and it stays necessary. The ability to build with AI APIs, understand the capabilities and limits of current models, structure a discovery process, and ship a working pilot is the floor, not the ceiling. If you do not have that, get it first.
But once you have it, the question is not how much more technical depth to add. The question is how to build the enterprise layer. And that is a different kind of work than what most technically trained people are used to. It requires studying domains that feel adjacent to engineering: organizational behavior, procurement, regulatory frameworks, change management. It requires practicing skills that are harder to measure than code quality: asking discovery questions that reveal real constraints, mapping stakeholder dynamics in a room, scoping something to what is actually approvable rather than what is technically optimal.
The FDEs who add the most value are not the ones with the deepest technical knowledge. They are the ones who can sit in a room with a VP of Operations, understand within 20 minutes what the real problem is and what it would take to solve it, build something that addresses that problem in 72 hours, and guide it through the internal process that turns a working pilot into a funded program. That combination is rare. It is also learnable. And in 2026, it is the most valuable thing you can build.