The FDE Model Works. It Just Doesn't Scale.

The FDE Model Works. It Just Doesn't Scale.

Sarah flew to a financial services client for three weeks, embedded with their team, and built a custom Salesforce-to-Snowflake integration that no off-the-shelf tool could touch. She was brilliant, expensive, and — as far as anyone in leadership was concerned — completely unscalable.

What I didn't understand then is that Sarah is the future of enterprise software delivery. What I've come to understand since is that she's doing it with one hand tied behind her back.

Forward Deployed Engineering is how complex technology actually gets deployed. Not through documentation. Not through product-led onboarding flows. Not through support tickets. Through a skilled human being who sits inside a customer's operational reality long enough to understand it, and then builds the bridge from where the customer is to where the technology needs them to be. Palantir pioneered the model in the early 2010s in intelligence and finance. OpenAI-sf-san-francisco/), Anthropic, Databricks, and Anduril scaled the model into AI and defense. Job postings for the role grew 1,165% in 2025, with demand spikes across every major AI lab. The model works.

The problem is the economics.

A single FDE commands a median base of $173K, with total compensation frequently reaching $200K–$300K+ once equity and bonuses are factored in. For a 50-person FDE organization, fully-loaded cost lands somewhere north of $12M annually. That would be a reasonable investment if every engagement was building something genuinely novel. But it's not. Practitioners consistently estimate that somewhere between 30–50% of what FDEs build has structural precedent in work the team has already done elsewhere — a figure that's widely cited in internal conversations but, tellingly, almost never formally measured. The Salesforce integration Sarah built in week two had an authentication pattern, a rate-limit handling strategy, and a data quality framework that three other FDEs on the team had solved separately in the previous six months. Nobody knew. Nobody captured it. Nobody told Sarah.

"We're paying $300K for someone to reinvent a wheel we built last quarter," one FDE director put it, with the flat affect of someone who has said this many times in rooms where nobody had an answer.

This is not a management failure. It's structural. The FDE model, as practiced today, treats the knowledge generated in each deployment as a byproduct of the engagement rather than as a primary output. And that means the model has a cost problem that talent, effort, and compensation cannot fix — only infrastructure can.

But here's what makes this complicated: the infrastructure that would fix it doesn't exist yet. Not for enterprise. And understanding why requires understanding what "enterprise FDE" actually is — and what it isn't.

The Model That Actually Works

The AI lab FDE model is mature enough to be studied. Palantir built the template in the mid-2000s while deploying predictive software to intelligence agencies: embed skilled engineers directly into customer environments, give them the authority to understand and modify the integration layer, and build feedback loops back to the product team so field learning improves the core platform. It's expensive. It's not scalable in a naive sense. And it demonstrably works for deploying complex technology into complex environments.

The model spread because it had to. OpenAI deploying GPT-4 into enterprise workflows learned what Palantir learned a decade earlier: enterprises do not onboard themselves. Databricks scaling its data platform found the same thing. Anduril deploying autonomous systems software into defense environments found it in the most unforgiving way possible — where onboarding failure isn't a churned account, it's a mission that doesn't work.

What the AI labs built, beyond the technical capability, is a model: a structured organizational function with its own culture, career path, knowledge systems, and economics. Engineers in the field and engineers at headquarters share context. Insights from field deployments inform product roadmaps with deliberate, structural feedback loops — not informal Slack messages that disappear. Knowledge generated during an engagement doesn't evaporate when the FDE moves on; it gets captured and compounded.

Palantir solved this through culture. Engineers in the field and engineers at HQ are deliberately indistinguishable in skill and context. Knowledge flows through intense documentation, internal tooling built over two decades, and a rotation system that keeps field learnings connected to the core platform. That's a viable solution if you're Palantir. It's not a solution you can copy-paste.

For the 50-person FDE organization trying to emulate this today, without twenty years of internal tooling investment and a culture built around knowledge transfer: the math is brutal. At $12M+ in annual fully-loaded cost, if even a third of implementation work is structurally redundant — and most practitioners believe the true figure is higher — that's $4–5M in annual waste. Not incompetence. Structural waste baked into the model itself — because the infrastructure required to eliminate it has never been built.

What Enterprise Calls "FDE" Isn't FDE Yet

Here's the discipline gap that almost nobody is naming directly: enterprise FDE doesn't exist yet as a category. What exists is a set of adjacent practices that are doing FDE work without the FDE model.

Professional services is time-and-materials, defined by deliverables and project scope. The engagement ends when the thing is built. Knowledge capture is a nice-to-have. The relationship is transactional.

Systems integration is project-scoped, typically vendor-agnostic, focused on making existing systems talk to each other. The SI firm brings methodology, not embedded intelligence. They leave when the integration is live.

Field consulting is advisory, not constructive. The consultant tells the customer what to do. The consultant does not sit inside the customer's operational reality for four months learning what Gary understands about the 2 AM COBOL batch job.

True FDE — with the organizational model, knowledge capture mechanisms, feedback loops, and career path that the AI labs have built — is nascent in enterprise, and in most organizations it doesn't exist at all in this form. IBM has something approximating it in its most sophisticated field engineering teams. Red Hat has it in some corners of its services organization. Microsoft has early versions in FastTrack. But these are exceptions, often individual-dependent rather than systematically built.

What enterprise organizations call "FDE" is usually one of three things: professional services that's renamed itself to sound more cutting-edge; a field engineering team doing what field engineering has always done; or a small group of exceptional engineers doing genuine embedded work on the strength of their own talent and institutional knowledge, with no organizational infrastructure supporting them.

The exceptional engineers doing genuine FDE work in enterprise environments exist. They're doing the actual job — the Red Hat engineer who spent four months at the Midwestern bank, the Microsoft FastTrack engineer mapping fifteen years of Active Directory policy. They're doing it brilliantly, and they're doing it without the model, culture, or tooling that makes the AI lab FDE function compound over time.

"We have forty engineers in the field right now," one director of forward deployed engineering at a data infrastructure company told me. "I can tell you with confidence that at least a dozen of them are solving problems that other teams already solved this year. I just can't tell you which problems, which teams, or what they learned. That knowledge doesn't have a place to go." (This reflects a pattern across multiple conversations with FDE leaders; it is not a direct quote from a single identifiable individual.)

The gap between where enterprise FDE is and where AI lab FDE is isn't primarily a talent gap. It's a model gap. And closing it requires infrastructure that nobody has built yet.

Platform Capture Is the Business Model — But It Requires Infrastructure

There's a concept worth naming precisely because it's widely misunderstood: Platform Capture.

Platform Capture is not an IDP rebrand. It's not a vendor inserting a portal between the customer and their infrastructure. It's something more specific and more powerful: the moment a vendor's people become the connective tissue of a customer's technology stack through integrations that no standard tool can provide — and the customer becomes structurally dependent on the vendor's FDE function, not just the vendor's license.

The distinction matters because it clarifies why existing integration tools fail at this.

Backstage catalogs services and provides a developer portal. It does not execute integration logic in regulated customer environments. It cannot manage a stateful, compliance-aware adapter between a financial trading system and a new data platform. It catalogs what exists; it doesn't bridge what can't otherwise be bridged.

MuleSoft handles known API patterns with documented interfaces. It cannot adapt to an undocumented legacy system where the "API" is a thirty-year-old mainframe batch process that Gary is the only person who understands. MuleSoft assumes both sides of the integration are accessible, documented, and conformant. Enterprise environments routinely offer none of these things.

Zapier automates workflows between SaaS products. It assumes both sides are accessible web services. It cannot reach an air-gapped financial trading system, an on-prem HL7 server, or a COBOL job running in a bank's data center. The categories of integration that Platform Capture operates in are specifically the ones Zapier's architecture cannot reach.

The integration class that Platform Capture requires is stateful, compliance-aware, environment-specific adapters built for systems that pre-date modern API conventions and exist in environments with security and regulatory constraints that modern integration tooling wasn't designed for.

These adapters cannot be built by a product team working in the abstract. They require an FDE who has spent weeks inside the customer's environment, earned the trust of the people who understand the legacy system, and built a bridge that will still be running five years from now. That is the FDE's core output. And when that output is delivered well and captured systematically, the vendor doesn't just win a customer — they become structurally embedded in the customer's operations in a way that no competitor can easily displace.

Platform Capture is how FDE economics eventually work. But it requires FDE infrastructure — a systematic way to build those adapters, capture the knowledge embedded in them, and compound that knowledge across engagements. Without the infrastructure, each engagement is an isolated achievement. With it, each engagement makes the next one faster, more reliable, and harder to replicate.

That infrastructure doesn't exist yet. Not for enterprise.

The Legacy-Encumbered Middle

There's a segment of the market where the FDE need is most acute and the tooling most absent: mid-market companies running legacy enterprise infrastructure at compliance-grade requirements.

These are companies running SAP Business One for ERP, HL7 interfaces for healthcare data exchange, FIX protocol systems for financial trading, or custom on-prem workflows built over fifteen years of accumulated technical decisions. They have the compliance requirements of enterprise — HIPAA, SOX, PCI-DSS, whatever their industry mandates — and they do not have the resources to fund Palantir-style embedded engineering.

The Fortune 500 company can sign a $2M professional services contract and get a team of six people embedded for six months. The mid-market healthcare organization running a HL7 interface built in 2009 that its one remaining systems engineer barely understands — they can't do that. But their integration problems are just as real, their compliance exposure just as serious, and their need for expert embedded engineering just as urgent.

This is the segment that sits between "big enough to buy Palantir" and "small enough to use off-the-shelf tools." They're currently the least served and most vulnerable, because their legacy environments are specifically the kind that standard integration tooling cannot reach and standard professional services doesn't want to touch.

The FIX protocol trading system that hasn't been updated since 2015 because changing it requires recertification with the exchange. The SAP Business One instance that's been customized so heavily that nobody fully understands the customization map. The HL7 interface running critical patient data that has a single engineer who understands it and is three years from retirement.

These companies need FDE capability. They will need it more as AI and cloud infrastructure become non-optional for competitive survival. And they currently have no path to it that is economically rational.

The Knowledge That Walks Out the Door

There's a second-order problem that the redundant-work calculation doesn't fully capture.

When an FDE finishes a deployment and moves to the next customer, they take their accumulated mental model with them. The decisions they made — why they chose one authentication approach over another, which data quality checks actually matter in financial services, how to handle schema drift in a streaming pipeline, what the compliance auditor is actually looking for when they review integration logs — none of that is captured in the deliverable. It lives in the FDE's head.

This is the knowledge externalization problem that every knowledge-intensive organization faces. What's different in FDE contexts is the stakes. A senior FDE's embedded knowledge represents months of hard-won learning in customer environments that cost hundreds of thousands of dollars to enter. That knowledge is deeply contextual, hard to transfer, and completely personal. When the FDE leaves the company — and FDEs are in high demand; they leave — the knowledge is gone.

The pattern is consistent across every FDE organization of scale: the knowledge exists, scattered across completed engagements and individual engineers' heads. It just has nowhere to go.

There's a useful frame for this transition: from jungle combat to civil engineering. The first generation of FDE practice is jungle combat — individual expertise, improvisation, hard-won knowledge that doesn't transfer. The mature version is civil engineering: documented patterns, reusable structures, institutional knowledge that survives the departure of any individual.

Most enterprise FDE organizations are stuck in jungle combat, not because their engineers aren't talented enough to build something reusable, but because there's no infrastructure that makes capturing and reusing knowledge feel like career capital rather than administrative overhead.

The difference between these two modes is not talent. It's organizational infrastructure.

What Would Fix It

The business problem is clear enough at this point. A mature FDE model requires:

• Pattern capture: when an FDE builds a novel integration, the structure should be extractable and available to the next engineer facing the same challenge
• Hard knowledge loops: the feedback path from field insight to platform improvement should be structural and rapid, not aspirational and slow
• Organizational incentives: contributing knowledge should feel like building career capital, not satisfying a surveillance requirement
• Runtime flexibility: tooling has to work in the actual environments where enterprise FDEs operate, not the environments where the tooling designers wish they operated

These requirements aren't exotic. They're what any mature knowledge-intensive professional function requires. What makes FDE unusual is how poorly the current tooling landscape serves them — and how high the cost is of getting this wrong.

A 50-person FDE organization paying $5M in structural waste annually isn't just leaving money on the table. It's also building a career environment where the most talented engineers burn out on redundant work, where institutional knowledge is entirely personal, and where the economic case for the whole function becomes increasingly difficult to defend to leadership.

The organizations that solve this first will have a structural advantage: faster time-to-deployment, lower cost per engagement, and a knowledge base that compounds rather than resets with every departure.

What solving it looks like technically — and why the obvious answer (Kubernetes operators) is the right answer for some environments and the wrong answer for most — is the question this series turns to next.

Post 4 makes the case directly: the AI lab FDE model can't simply be transplanted into enterprise environments. The constraint isn't talent or budget — it's directionality. The tool shapes the environment in AI lab FDE. In enterprise FDE, the environment shapes the tool. That inversion is everything.