Forward deployed engineers are booming. But are your deployments getting cheaper or just bigger? A test to tell leverage from a hidden services trap.
Forward deployed engineers are suddenly everywhere. FDE job postings jumped roughly 729% year over year, according to Indeed data. In May 2026, OpenAI stood up an entire deployment company and agreed to acquire an AI consulting firm so it could staff that unit with engineers from day one.
The market reads all of this as proof that enterprise AI has arrived.
There is a more useful way to read the same signal.
If every enterprise AI deployment needs an embedded engineer to make it work, the product is not yet doing enough of the deployment work on its own. That gap has a cost. It shows up in gross margin before it shows up anywhere else.
This is not an argument against forward deployed engineers. They are useful, and in most cases necessary. The argument is that the market is asking the wrong question. Instead of "how many FDEs should we hire," the sharper question is whether each deployment is getting cheaper or just bigger.
Most enterprise operating models are not ready for AI to land cleanly.
Data lives in separate systems that were never designed to talk to each other. Permissions are scattered across tools and teams. Workflows exist in people's heads, not in written processes. Governance runs through a committee. Legacy systems were built long before anyone imagined connecting them to a language model.
Forward deployed engineers sit in that gap. They stand between what AI can do and what a customer's environment will actually allow. They do the translation work: find the data, clean the connections, write down the workflows, and build the configurations that let AI do something useful.
The role exists because the distance between AI capability and enterprise readiness is real and wide. Someone has to close it.
But there is a difference between solving a problem and building a bridge. FDEs work around the operating model problem. The question is whether working around it builds something durable or creates a new dependency.
The FDE function can go in two directions. Both start in exactly the same place, with the same hire, solving the same first deployment. What separates them is what happens to the learning afterward.
Every deployment generates more than a working system. It generates patterns that repeat. Those patterns flow back into the product. They shape default configurations, onboarding steps, and implementation guides.
The next deployment takes fewer hours. The one after that takes even less effort. The product quietly absorbs the work the engineer was doing last quarter. Gross margin improves. Time-to-value compresses. The FDE becomes more valuable precisely because the product needs them less.
Every customer needs its own custom work. Deployment quality depends on specific people, not on product capability. Implementation hours never decline. The roadmap starts absorbing custom requests that came straight out of FDE engagements.
Revenue grows, but the labor required to deliver it grows at the same rate. Margins flatten. The business starts to look like a services company, even when the pricing model insists it is software.
The difference between the two paths is not talent or effort. It is whether field learning builds into the product or hardens into tribal knowledge locked inside individual engineers. This is the Linear Growth Trap wearing a better disguise: growth that can only move as fast as headcount, dressed up as an AI success story.
There is one question underneath all of this. Are your deployments getting cheaper?
Before celebrating what your FDEs have shipped, run your last three enterprise AI deployments through five questions.
1. Is time-to-value decreasing? Each deployment should reach a working, customer-validated outcome faster than the one before it. If deployment three took as long as deployment one, field learning is not making it into the product or the process. Labor is being repeated, not reduced.
2. Are implementation hours per customer declining? Track the hours required per deployment, quarter over quarter. If the number is flat or rising, your deployment model is scaling in lockstep with revenue. That is the definition of labor-dependent growth.
3. Is field learning making it into the product? Think about the last three problems your FDEs solved for more than one customer. Now name what changed in the product because of them: a new feature, a default setting, a step in onboarding. If you cannot name anything, the feedback loop is broken.
4. Can you describe a successful deployment without naming specific people? If the answer requires naming individuals rather than describing a process, the deployment is not yet repeatable. Repeatability comes before scale.
5. Is gross margin on AI-enabled work improving? Revenue per deployment should be rising while labor cost per deployment falls. If both rise together, you have revenue growth without margin expansion. That is services economics, no matter what the product actually does.
Two or more weak answers means your deployment model is hardening into dependency. That is worth knowing before it surfaces in your next board conversation instead of on your own terms.
The CEO's job is not to eliminate forward deployed engineers. It is to decide whether the FDE function is designed to reduce its own necessity over time.
That takes three things.
First, a feedback system that moves field learning into product development. Not occasional input dropped into a backlog, but a regular process that shapes what gets built next.
Second, a roadmap process that treats repeatable FDE patterns as product debt. Not as feature requests from named accounts, but as signals that the product is not yet doing work it should already be doing on its own.
Third, metrics that track whether each deployment costs less than the last. Completion means the system is running. Leverage means the next deployment is cheaper than the one before it. Those are not the same thing, and confusing them is how a software business slowly becomes a services business without ever deciding to.
The right question is not how many forward deployed engineers to hire. It is whether your product team has a formal way to turn field deployments into new product capabilities. If the answer is no, that is exactly where the leverage gap lives. Turning field learning into product capability is the heart of a Product Led Revenue motion, where the product, not headcount, carries more of the deployment weight over time.
A forward deployed engineer should be a bridge to leverage, not a permanent substitute for it.
The companies that win with enterprise AI will not be the ones with the most FDEs. They will be the ones whose FDEs made themselves progressively less necessary. Each deployment cheaper than the last. Each implementation faster. Each new customer requiring less custom work than the one before.
The Linear Growth Trap used to arrive through sales headcount and customer success teams. Now it arrives through forward deployed engineers. The disguise is better. The trap is the same.
If you want a fast read on whether your deployment model is compounding or quietly trapping you, take the free Quick Test and see where your growth is leaning too hard on headcount.
A forward deployed engineer (FDE) is an engineer embedded with a customer to make software, increasingly AI, actually work inside that customer's environment. They locate and clean data, connect systems, document workflows, and build configurations that bridge the gap between what the product can do and what the customer's operating model allows.
Enterprise AI capability has outrun enterprise readiness. Data is siloed, permissions are scattered, and workflows live in people's heads rather than written processes. FDEs close that gap by hand, which is why postings surged roughly 729% year over year and major AI companies are building deployment units staffed with engineers from day one.
Run your last three deployments through the deployment leverage test. If time-to-value is not decreasing, implementation hours per customer are flat or rising, field learning is not reaching the product, deployments cannot be described without naming specific people, and gross margin on AI work is not improving, you have services economics regardless of your pricing model.
No. FDEs are useful and often necessary. The goal is not to eliminate them but to design the function so it reduces its own necessity over time, through a feedback loop into product, a roadmap that treats repeatable patterns as product debt, and metrics that confirm each deployment costs less than the last.
The Quick Test reads your revenue motion against the five patterns in a few minutes. No financials required.