What is a Forward Deploy Engineer?

The role in one sentence

A Forward Deploy Engineer is a software engineer who works on the customer’s problem, with the customer’s data, on the customer’s site, using their company’s platform — and ships running software, not slide decks.

That sentence carries a lot of weight. Each clause matters:

• Software engineer — FDEs write code. Real production code. Not pseudocode in a deck.
• The customer’s problem — not a generic product roadmap, not a feature backlog. The thing the customer is actually trying to do this quarter.
• The customer’s data — messy, partial, often classified or regulated.
• The customer’s site — frequently in person, often inside their network, sometimes inside a SCIF.
• Their company’s platform — the FDE is a deployed force projecting their company’s product into a specific customer context.
• Ships running software — the deliverable is a working system, not a recommendation.

Where the role came from

The FDE role was crystallized at Palantir in the mid-2010s. Palantir’s product (Foundry and Gotham) is a platform: a powerful, general-purpose substrate for modeling and operating on organizational data. The problem is that no customer can pick up a platform, shrink-wrapped, and turn it into a working solution to their specific problem. Someone has to do the bridge work — and Palantir decided that someone should be a senior engineer, not a separate consulting org.

So they invented FDEs: engineers who deploy with customers, learn the customer’s domain in weeks, model it in the platform, build the apps the customer needs, and stay until the system is in production and adopted. The model worked. Palantir’s revenue grew, and the FDE role became one of the most coveted engineering positions in enterprise software.

Today the pattern has spread:

• Anduril — FDEs deploy with defense customers to integrate Lattice into operational workflows.
• Anthropic — Applied AI / Solutions engineers deploy Claude into enterprise systems.
• OpenAI — Solutions and Applied teams play a similar role.
• Scale AI — Forward-deployed engineers on government and enterprise contracts.
• A whole generation of vertical AI startups — Harvey (legal), Sierra (CX), Hippocratic (health), Decagon, et al. — almost all have an FDE-shaped function, even if they call it “Forward Engineer,” “Applied Engineer,” “Implementation Engineer,” or “Customer Engineer.”

The names vary. The job is the same.

What an FDE actually does

A typical FDE week looks something like this:

That is not a metaphor — that is a real week from a real FDE engagement. The cadence is discover → prototype → show → iterate, compressed to a few days, repeated until something is in production.

The actual outputs an FDE produces over a 6–12 week engagement:

1. A problem statement the customer signs off on
2. A domain model (object types, link types, actions) of the customer’s business
3. Data integrations from the customer’s source systems
4. One or more operational applications that operators use daily
5. A deployment to the customer’s production environment
6. A trained customer team that can keep the system running
7. A renewal — the next engagement, the next phase, the expanded contract

How FDEs differ from adjacent roles

This is the question you get most often, especially in interviews and from skeptical hiring managers. Here is the breakdown.

FDE vs. Solutions Engineer (pre-sales)

A solutions engineer typically supports a sales rep, demos the product, scopes pilots, and writes statements of work. Their deliverable is usually a deal. An FDE owns the delivery after the deal — though at most FDE-style companies the same person may do both, blurring the line. The shift from “demo the platform” to “deploy the platform” is the shift from SE to FDE.

FDE vs. Consultant

A management consultant delivers analyses, decks, and recommendations. The output is advice. An FDE delivers a system. A consulting engagement ends when the report is signed off; an FDE engagement ends when the software is live and adopted. There is consultancy embedded in FDE work (interviews, scoping, stakeholder management), but the deliverable is fundamentally different.

FDE vs. Product Engineer

A product engineer at a SaaS company builds features in the platform. Their customers are abstract — represented by PMs, research, and analytics. An FDE builds for and with a specific customer, often building things that will never make it back into the core product. Product engineers optimize for generality; FDEs optimize for fit. The best FDE-heavy companies have a healthy back-channel where patterns FDEs discover get pulled back into the platform.

FDE vs. Customer Success Engineer

A CSE is reactive: a customer has a problem, the CSE helps them solve it within the existing product. An FDE is proactive: they go find the next problem worth solving and build something net new.

FDE vs. Consultant Implementation Engineer (at a SI)

At a systems integrator (Accenture, Deloitte, etc.), implementation engineers configure third-party software for clients. The closest cousin to an FDE, but with two big differences: SI engineers usually work for the integrator, not the platform vendor — so they are renting your trust, not building it. And they typically configure, not code.

The summary:

The core skills

Across every FDE org, the same skill profile shows up:

1. Technical breadth, not depth. You will touch React on Tuesday, SQL on Wednesday, a Kafka consumer on Thursday, a SAML config on Friday. Specialists struggle in this role; generalists thrive.
2. Speed of comprehension. You need to understand a new business — its workflows, its vocabulary, its politics — in days, not months.
3. Modeling instinct. The customer hands you a tangle. You hand back a clean object model. This is the single most leveraged skill in the role.
4. Written and verbal communication. You will write more docs than the average engineer, and you will brief executives in person.
5. Operational maturity. You will deploy to production at customer sites. You will be on call for systems you built. You will own the consequences.
6. Comfort with ambiguity and politics. Customer projects fail more often for political reasons than technical ones. You need a tolerance for messy human stakes.
7. A bias to ship. A working ugly thing on Friday beats a beautiful design on Monday.

The disposition

Skills can be taught. Dispositions are harder. The FDEs who thrive tend to share a few traits:

• They are outcome-oriented, not output-oriented. They care whether the dispatcher’s life got better, not whether they hit a sprint metric.
• They are comfortable being wrong in public. The first prototype will be wrong. So will the second. That is fine.
• They are respectful of the customer’s expertise. The dispatcher knows things about dispatching that no engineer will ever know. The FDE’s job is to amplify them, not replace them.
• They have low ego about the codebase and high standards about the deliverable. Throwaway prototypes are fine. Production cutovers are not.

When the FDE role is wrong for you

Be honest with yourself. The FDE role is not glamorous most days. It involves:

• Travel. Often a lot of it.
• Politics. You will be caught between IT, ops, and procurement.
• Context-switching. You will not get deep flow days.
• Customer time zones. Your day starts when the customer’s day starts.
• Code that nobody else will ever read. Some of your best work will live only at one customer.

If those are dealbreakers — and they reasonably are for many excellent engineers — this is not your role.

Key terms to remember

• FDE — Forward Deploy Engineer. The role this course is about.
• Engagement — a single bounded delivery with a customer, usually 6–12 weeks.
• Deployment — pushing a system live at the customer site. Not “git push.”
• Ontology / domain model — the typed model of the customer’s business that anchors the work.
• Cutover — the moment the customer switches from the old way to the new system.
• Hand-off — the process of transferring operational ownership to the customer team.

What’s next

You know the role. Next we will look at how the role is delivered — the embedded delivery model — and why FDE work is fundamentally on-site, walking the workflow, not at a desk reading specs.