Flagship essay

Forward-Deployed Engineering Is New. The Work Underneath It Is Not.

August 8, 2026 · 22 min read · The frame: Start Here

Time Machine to 2014

The filling line chugged rhythmically as my colleagues and I walked out onto the manufacturing floor. I can still smell the isopropyl alcohol and the bleach we used to sanitize our boots.

In 2014, implementing a Laboratory Information Management System (LIMS) meant wiping my clipboard with isopropyl alcohol, gowning up in my blue bunny suit, and walking into ISO 8 and ISO 7 manufacturing areas.

The site made injectable IV bags across multiple manufacturing lines: saline, Lactated Ringer’s, and other terminally sterilized products (i.e., non-aseptic filled products). I was helping implement some of the LIMS workflows for biological and chemistry quality (BQ and CQ) on what was then Lonza’s MODA platform.

That meant locating the environmental monitoring points across the actual manufacturing plant. For example, that could be identifying physical tank-sampling valves or viable and total-particulate monitoring locations. Then, determining how frequently each one needed to be sampled. The BQ and CQ teams needed to know what sample to collect, where to collect it, and the sample scheduling to make sure they were compliant.

Also, those aligned answers had to be consistent across the process, the standard operating procedure, and the LIMS system configuration. If one of those aspects was incorrect, the software was wrong, and we could be at risk of a potential investigation (if you haven’t written a CAPA before, you’re in for a treat). The implementation also had to go through pharmaceutical software validation and hold up during an eventual FDA audit.

This overall exercise taught me one of the most valuable lessons of my career:

None of the implementation exercise started with the code. The process started with walking the floor, physically speaking with the operators doing the work, and translating that work into the software.

Implementation as a discipline

Today, many folks would describe much of that implementation process as forward-deployed engineering. At the time, my badge said engineer, but we didn’t call that work “Forward Deployed Engineering,” we just called it software implementation.

I am not making the old-man-on-the-internet claim that we secretly invented FDE first (I hope I’m not there yet, but my kids may say otherwise). Admittedly, the FDE title is also still useful, and the current AI-assisted tooling genuinely changes what one person can build. My point is that the discipline underneath this new motion already had a name, a methodology, and history several decades before the current label arrived.

Andreessen Horowitz called the forward-deployed engineer “the hottest job in startups” long ago in 2025… (Schmidt, 2025). The Financial Times reported, using Indeed data, that monthly listings for the title rose more than 800% between January and September 2025 (PYMNTS, 2026).

Caveat: I could not reproduce this fact from the published data to which I had access, so while I treat that as a strong signal that employers are reaching for the title, I can’t confirm that it is an organizational or talent census of the underlying work.

When you read a job description for one of these roles (outside of the odd JD where they ask you to be “AI pilled”), they typically read something like:

Embed with the customer, live inside the operation, wire the software into messy reality, and stay until it works.

But I keep coming back to the fact that there is already a name for this work and it has been on invoices for ~thirty years: implementation consulting. I personally know the suitcase version of that life. For a couple of years, I traveled more than forty weeks a year, and at one point I was Diamond with Hilton and Platinum with Marriott at the same time… which sounds better until you think about how you earn both.

The ERP wave ran hard on that kind of work. While SAP and Oracle shipped platforms, large implementation teams lived out of suitcases making those platforms live inside specific companies, one messy site at a time. Large Systems Integrators built entire billion-dollar+ practices on the premise that software does not deploy itself into an operation. Someone had to physically go to where the operation is. Pharma had its own regulated flavor of the same job, the one I did: implementation and software validation, software wired in and proven in, with an evidence trail an FDA inspector could walk.

The current wave is right that the job matters enormously. Where I disagree is with how new we sometimes make the underlying work sound.

My reaction is that this wave has no memory. And markets with no memory repeat expensive things.

The job-description test

Here’s the test I keep running. Take a 2026 FDE listing and strip the company names. Then put it next to what an ERP implementation consultant did in 1999, or what I did in a pharma plant in 2014.

The overlap isn’t superficial. It’s the implementation job. What changed between 1999 and 2014 was the industry vertical; what changed between 2014 and 2026 is the software layer being wired in, along with the economics and tooling around the person doing the wiring. The role is old enough to rent a car.

The translation discipline

The title comparison is fun, but it is not why I care about the lineage.

That methodology really narrowed down to business // technology translation; how can one translate a problem into a system that changes (and hopefully improves) the operation in a meaningful way.

See the below metaphorical translation “chain” that starts with the Profit & Loss (P&L) of the business and walks forward all the way to “reality” where things are executing and working within that business.

In the above translation chain, the software box is only one small part of driving improvements that translate back to the P&L of a business. If you enter the improvement process at the “software behavior” box, you are gearing up to learn an expensive lesson. By starting downstream, you inherently agree to every upstream assumption, and treat them as settled.

Starting this late, it’s much harder to challenge the process. Outside of technical implementation chops, an FDE should be able to work through tough implementation questions about the process and push back where the best solution is NOT AI.

Likewise, as a buyer, I would hope and expect that an FDE would ask questions like:

• Process hops: Is this process handoff necessary?
• Regulatory requirements: Is it required by a regulation / law?
• Change management: Does this process exist because it is just “the way we have always done it?”
• Exception management: Is the exception actually exceptional or should it be a warning?
• Outcome measurement / KPI / OKR: Does the measurement metric measure the desired outcome of the process?
• Optimization: Do we even need this process at all? (the most efficient process is an eliminated one)

Often, one of those assumptions / questions actually highlights the breakdown in the value chain.

This is why the work has always required more than requirements gathering. You need enough understanding of the business to ask which economic lever is supposed to move, and enough familiarity with the process to distinguish what people actually do from what the procedure says they do. From there you have to work out who makes which judgment, what evidence they use, what happens when the happy path breaks, and what the downstream user needs to trust the result. Eventually all of that has to be expressed in a form an engineer can build and an operator can reject when it is wrong.

In 2017, we built client-facing functional specifications and technical specs that did exactly that translation. Before the FDE title, agents, or cheap code generation, companies still needed people who could turn business process and user behavior into rules, interfaces, exceptions, and acceptance criteria an engineer could implement. That translation decided whether the build meant anything once it reached the operation.

The feedback arrow at the end is the return path through the same chain. A functional specification is not a ceremonial handoff. Once the system reaches the operation, you learn which exception was common, which rule was fictional, which field nobody could supply, and which technically correct output no operator would trust. The translator carries that evidence back into the next version.

Seen this way, Palantir’s contribution is easier to separate from the implementation discipline itself: it moved the function inside the product company, packaged it as engineering, and changed which economics could sit around it.

What Palantir repackaged

The origin story the market tells is that Palantir created the forward-deployed engineer. As history of the title, that’s right: Palantir coined it in the early 2010s and called the people who held it “Deltas.” For a stretch of its life the company had more Deltas than it had conventional software engineers; the field outnumbered the factory until around 2016 (Orosz, 2025).

But look at what the Deltas were doing: living at customer sites, configuring a vendor platform against live operations, translating between the client’s reality and the product team. A large systems integrator would have recognized the staffing pattern immediately, which is why I don’t think the underlying function was the invention.

The public record supports a narrower claim than “implementation at software multiples.” Palantir’s 2025 filing says its contracts include hosted subscriptions, on-premises software with operations and maintenance, and professional services such as interface configuration, training, and ontology and data-modeling support. It also says software engineers working with existing customers often manage deployments and identify new uses. At the same time, the company explicitly describes a “product-based business model” and says its platforms are offered on a productized basis to reduce acquisition, maintenance, and deployment time (Palantir, 2026).

What the filing does not provide is an FDE-specific P&L. I cannot separate the margin on embedded implementation from the platform around it. What we can observe is the combined model: subscription software, operations and maintenance, deployment, and professional services inside a company that reported an 82% consolidated gross margin in 2025.

The packaging allowed embedded implementation to live inside a scalable product company instead of appearing only as a consulting project.

The current wave is fairly explicit about the economics. The a16z essay that crowned the FDE the hottest job is an argument about margin: trade gross margin today for control of the deployment layer, because the companies that owned implementation (Salesforce, ServiceNow, Workday) started margin-ugly and ended up as systems of record (Schmidt, 2025).

I think owning the last mile may be worth paying for. I am less convinced that this means every hour of forward-deployed work behaves like software revenue. The available accounting does not tell us that.

Why AI widened the last mile

AI made that packaging newly urgent because it widened the distance between a convincing demo and a dependable operation.

An ERP rollout was brutal, but it was brutal in a legible way. The software was deterministic. Configuration was the hard part; once configured and tested, the system did the same thing every day, and the remaining risk was organizational: process change, data migration, people.

An AI deployment inherits all of that and adds a layer ERP never had: the core component is probabilistic. It behaves differently on your documents than on the demo’s, its failure modes can be quiet, and its correctness is statistical. “Does it work?” stops being a question you answer once and becomes a question you answer continuously.

That difference is new, and it gets its own essay later in this series. It’s the one thing this wave cannot copy from the last one.

I argued in The Model Is the Small Box that the model was the small piece in a much larger ecosystem required to create value. When it comes to the FDE / talent play, the model IS a real difference in this wave because it enlarges the whole diagram rather than just one box. When you have these probabilistic models, you must embrace and defensively design systems that handle receiving different answers to the same question (the model is a software slot machine after all).

To resolve this, there are several best practices we have to consider in designing and building these systems (i.e., building continuous evaluation, ensuring your failures are loud and not shaped like successes, facilitating meaningful organizational change management, and being ready to manage the complexity of ongoing maintenance). Consequently, these factors make the implementation discipline MORE important.

Put a component like that in front of an enterprise buyer and the distance between demo and deployed value becomes enormous, larger than the model vendors’ product teams can close from headquarters. So the market did what it did in the ERP era: it sent people.

It also gave the job a name that software companies and investors read differently. Implementation consultant is associated with a services business. Forward-deployed engineer puts similar last-mile work inside the product-engineering story.

The reported listings spike tells me employers are reaching for the title. It cannot tell us that the underlying body of work grew 800%, because title adoption and demand can rise together. I believe the need is real; I also think the market has forgotten that implementation businesses have followed this playbook before.

The earlier implementation-market cycle

If implementation is once again the bottleneck, the old market is more than history. ERP gives us a useful comparison, even if AI changes the ending.

ERP vendors built an enormous talent market around folks who could cross the gap between SAP transaction codes and a business process. Over time seasoned consultants would also build a heuristic understanding of where these flows would typically fall apart within an organization AND how to help redesign process around their system (partly for the betterment of the organization, but also partly because it made the ERP more sticky).

Over time, the implementation process became repeatable, and a competitive advantage for consultants. There was much time spent honing implementation methods, building talent development pipelines (through materials and a lot of on-the-job training), and even rate differentials for on/nearshore delivery. As the market saturated, the generic delivery DID get cheaper, but the domain expertise, business judgment, and apprenticeship / capability building genuinely remained scarce.

ERP implementation produced a recognizable playbook for how scarce delivery capability becomes legible and scalable. I am using that history as a conceptual model, not claiming the figure below is a measured industry margin curve:

The curve is mine. The pieces underneath it are not. SAP’s ASAP methodology codified implementation into repeatable phases, deliverables, templates, and quality gates. Research across 96 ERP projects documented the expectation that consultants transfer implementation knowledge so clients can maintain the system independently. Infosys’s 2003 filing described splitting work between client sites and offshore centers, training deployable staff, reusing knowledge, and executing components where they were most cost-effective. Accenture’s 2025 filing still describes standardized methods, global delivery, and cost advantages as the machinery behind price-competitive services.

That gives me receipts for method, knowledge transfer, talent scaling, and rate arbitrage. It does not give me the timing, slope, or inevitability of the curve.

The stages may not arrive neatly in order this time. We already have scarce practitioners, rapidly forming methods, agent factories, vendor-led delivery programs, partner networks, and early compression in the generic build layer at the same time. The market may mature from the middle out.

I think AI implementation is moving through a related curve, but not because every deployment will remain a bespoke snowflake. The build layer is already industrializing faster than ERP’s did.

Salesforce Agentforce, Google’s Vertex AI Agent Builder, Microsoft Agent Factory, and ServiceNow AI Agent Studio all package some combination of building, testing, deploying, governing, and operating agents. The model providers are compressing the layer from below: OpenAI and Anthropic both ship agent SDKs. Process-intelligence products such as Skan are trying to turn observed work into agent procedures, controls, and deployed agents. Adjacent workflow-capture tools such as Scribe are mapping how work happens, surfacing waste, and pointing teams toward what to improve or automate. Those are examples, not a complete market map.

With new capabilities (i.e., AI), the time it will take us to build repeatable implementation processes, build new implementation methods, talent development pipelines, etc. will almost assuredly decrease. Agent / software factories, low-code agent builders, managed code environments (i.e., runtimes) and model provider tooling are already compressing the build and execution.

Microsoft’s Agent Factory is almost too perfect as a receipt: the same offering combines agent platforms, training, forward-deployed engineering support, and a partner marketplace. A vendor absorbing the tool layer does not necessarily eliminate the services market. ERP gives us at least one precedent for the opposite.

The implementation gap became part of the business model

At the same time, the frontier labs like Anthropic & OpenAI are investing billions in “last mile” implementation and delivery because access to foundation models does not guarantee a change in client operations.

OpenAI’s Deployment Company embeds FDEs inside organizations to connect models to customer data, tools, controls, and core business processes. Ode with Anthropic is an enterprise AI services firm built from Anthropic engineers and the acquired Fractional AI team; its offer runs from roadmap through deployment rather than ending at model access.

DeployCo launched with more than $4 billion of initial investment. Ode was reported as a $1.5 billion company, although Ode and Anthropic’s official launch materials do not disclose that figure. The measures are not directly comparable or additive, but both are evidence that better models do not cross the implementation gap by themselves.

The last mile did not disappear. It became part of the business model.

For the frontier labs, implementation may make money in two places. There is the services revenue itself, and there is the customer adoption it can create for the model business upstream. Both OpenAI and Anthropic meter model usage by token. When a deployment arm moves a model from an experiment into a recurring core workflow, the project can create continuing inference consumption.

Or, less delicately: the implementation arm may earn revenue of its own. It may also be how the token business gets embedded.

Neither DeployCo nor Ode discloses enough unit economics to say how much value sits in each layer, or whether token pull-through is the primary motive. I am inferring that second incentive from the business model, not attributing it to a disclosed strategy.

The dollar figures got my attention, but the organization design is the stronger receipt. Both companies are putting a dedicated deployment institution between frontier models and customer operations. The capital does not tell us whether either one will work, but it does show the model providers treating deployment as a large enough problem to build an organization around it.

Here is what would prove me wrong: platforms commoditize the translation layer along with construction; operating context becomes portable without high-judgment implementation; domain depth stops commanding a premium; or providers absorb the whole lifecycle without creating another delivery ecosystem around it. All of those are plausible. AI’s probabilistic core also makes continuous evaluation and control more important than they were in deterministic ERP. I am using the last market for questions and base rates, not pretending it guarantees this one’s ending.

What remains scarce

If construction gets cheaper, the premium moves toward work that is harder to standardize.

A named method. Not a branded slide deck, but a way of working that reliably moves from economic objective through process, system, validation, adoption, and feedback. A buyer should be able to see how the team makes decisions, what artifacts survive the engagement, and where the method changes the result.

Domain and regulated depth. This earns its keep when someone knows which assumptions are dangerous, which evidence an operator or examiner will ask for, and which technically convenient shortcut creates a downstream control problem. You learn that depth slowly, usually by living through the consequences.

Capability transfer. A good implementation leaves the client able to operate, challenge, change, and eventually extend the system. Lock-in can look like a moat on a revenue slide; from inside the operation, it looks like asking permission every time your own process changes.

Ok, how do we mint more of these people?

With this in mind, it makes sense that the current demand for these folks is outstripping supply, but that leaves us with a new question.

My current working prediction is that many excellent FDEs will come from business analysis, operations, domain roles, and automation engineering, not only conventional software engineering.

AI is compressing the time required to turn a well-understood behavior into working software much faster than it is compressing the time required to understand the behavior.

Code is getting cheaper to teach and produce, and access to world class training materials is being created for free on YouTube and made available by the foundation model providers. You can teach a strong domain practitioner a new coding tool. You cannot compress twenty years of seeing how a plant, a P&L, a claims process, a quality system, or a finance operation really behaves into a prompt and call the transfer complete. The tools are explicit. Much of the judgment is path-dependent: exceptions seen, incentives misunderstood, controls failed, operators watched, and consequences lived through.

Automation engineers deserve an explicit place in that feeder pool. Many already know how to decompose a body of work, separate deterministic rules from exceptions, integrate across ugly system boundaries, and own what happens after an automation meets production. That does not automatically make someone ready to own a probabilistic system, but it is a much closer starting point than the current job titles imply.

None of this is permission to hand production architecture to anyone who can generate a demo. Security, reliability, data design, performance, deployment, and operability remain engineering disciplines. A business analyst still has to understand those constraints, just as an engineer still has to find the business decision the system should improve. Sitting at the customer site does not fill either gap.

The division of labor I would use puts experienced software and systems engineers on the safe systems these FDEs work inside: paved roads, identity boundaries, data contracts, deployment and recovery paths, observability, evaluation, and reusable controls. The FDE still owns the translation and the application. The platform team makes the safe path easier than the unsafe one. I would rather use scarce engineering depth there than ask the same central team to build every workflow or approve every change.

The hiring inversion

The HR mistake would be to read this as “hire fewer engineers.” I mean something more specific: stop writing every FDE role as a conventional software-engineering requisition with customer proximity added, then treating operating and domain judgment as nice-to-have.

I would build the role around four observable competencies:

• operating and domain judgment
• process translation
• production engineering
• evaluation and control

The four competencies are not enough by themselves; I would also hire for how someone learns. The ERP version of this job could hire for a decade of depth in one relatively stable manufacturing or quality module. An AI FDE is working while model behavior, frameworks, provider features, and operating patterns change underneath them.

I care whether they can pick up a new capability quickly, test it against the operation, discard it when the evidence changes, and ask for help before they are operating past their depth. The playbook is going to be incomplete for a while, so I would rather hire for that learning behavior than for familiarity with whichever framework happens to be current.

Candidates can start stronger on one side of the bridge. The staffing plan should name what they already bring, what they have to build, and who reviews the work until the gap closes.

The person I would look for is the analyst-builder: someone who can find the economic objective, map the work, make the decisions and exceptions explicit, use modern tools to build the smallest useful system, and know where deeper engineering judgment has to enter. The scarce skill moves up the chain. Less time translating a clear specification into syntax; more time making the specification true.

If I were building an FDE population, I would not start by asking who can produce code fastest. I would ask who can cross the translation chain without losing the operating intent, then build the missing technical or domain depth, review structure, and paved roads around them.

The team matters just as much as the individual. Searching for one mythical person with twenty years of domain experience, senior production-engineering depth, perfect customer instincts, and every current agent framework just recreates the same unicorn requisition under a newer title. Make the competency gaps explicit, pair people around them, and give the operation, the software, and the controls clear owners.

HR, engineering leadership, and the business have to design that system together. Changing the title on an old requisition will not do it.

Widen the pool. Keep the bar.

Therefore, while we shouldn’t lower the talent standard, we must consider broadening the talent pool to meet the demand.

So I modeled what happens when a recruiting funnel stops treating software engineering as the only valid source pool. Public labor data can size adjacent occupations, while the conversion assumptions make the unknowns explicit.

The default numbers are deliberately illustrative. Move the assumptions and the answer moves with them: who is reachable, what each lane already knows, how many people can be trained, who passes the same rubric afterward, and who can be placed inside the planning horizon. Today it is a staffing hypothesis; measured inputs could turn it into an operating instrument.

The public labor data provides scale for adjacent occupations. Readiness, interest, availability, and overlap among those populations remain unknown.

The hiring and buying test

So here is the test I would use for a person or a firm selling forward-deployed capability.

Give them one body of work and ask them to walk the whole chain:

• Which P&L lever or operating outcome are we trying to move?
• Which parts of the current process should disappear before anything is automated?
• Who are the actual users, and which decisions do they make?
• Which rules are stable, which boundaries can be learned, and which paths genuinely require runtime judgment?
• What exceptions carry the real risk?
• What would prove the software works in the operation, not merely in the demo?
• What will the client be able to operate and change without the embedded team?

Listen for where the answer starts. If it starts with the model, the framework, or how fast the team can code, you are still upstream of the important work. If it starts with the business outcome but never reaches architecture, validation, or production ownership, you have strategy without delivery. If it reaches production but leaves no capability behind, you bought an expensive dependency.

I would expect the answer to cross the whole chain and to be explicit about where the person’s or firm’s competence stops.

The people worth hiring

That is the job I recognize from 2014. The tools are better and the title is much cooler, but the test is still whether you can understand an operation deeply enough to build something it can trust, and leave the people running it able to own what comes next.

I’ve watched this movie from the inside twice, once with a validation binder and once with a migration cutover plan. The third screening has better effects. I would still rather not watch us relearn all of the expensive parts.

-T