Forward deployed engineering fundamentals

A forward deployed engineer is a software engineer who works inside a customer's organisation rather than inside their own, writing production code against that customer's data, systems and constraints. The title originated at Palantir and is now used widely by AI-infrastructure companies. The defining condition is not travel and not customer contact: it is that the engineering happens on someone else's estate, against a problem that has usually not been specified properly, with the customer's own staff as your immediate colleagues. You still ship software, still own its correctness, and still get paged when it breaks. What changes is that almost every input you need — data access, a decision, a person's time, a security exception — belongs to an organisation that does not employ you.

The four customer-facing engineering roles are constantly conflated, and an interviewer will ask because candidates apply for one while describing another.

Role                    Sits         Owns                        Deliverable
----------------------  -----------  --------------------------  ------------------------
Forward deployed        After the    Working software inside     A running system the
engineer                signature    the customer's estate       customer now depends on

Presales / solution     Before the   The technical promise       A proposal, a demo, a
engineer                signature    made to win the deal        scoped POC

Customer success /      After the    Whether the customer gets   Adoption, a renewal,
technical account mgr   signature    value from what exists      an escalation resolved

Delivery consultant     Under a      Scope, hours and the        A signed-off milestone
                        contract     statement of work           against a fixed scope

The column that decides everything is the third. A presales engineer's deliverable is being believed; an FDE's deliverable is something running. That single difference reorders every incentive. Presales optimises for a credible commitment, and it is professionally correct there to leave the hard implementation questions as named assumptions. An FDE inherits those assumptions and finds out which of them were false, which is why the two roles are complementary rather than interchangeable and why a good FDE reads the proposal before the first flight.

The boundary with customer success is subtler and worth stating precisely. A technical account manager debugs an integration to establish whose fault it is; an FDE writes the integration. Both spend their week on a customer's problems, but only one of them merges code. Where the boundary genuinely blurs is a small company with one person doing both, and the right interview question is which artefact the role is measured on.

It means the unit of work is a deployment rather than a ticket. You are assigned to one customer, or a small number, for weeks to months, and your objective is a specific outcome inside their business rather than a backlog item inside your product. Practically that means your development environment is theirs, your data is theirs, your review conversations happen with their engineers, and your definition of done is a process of theirs behaving differently. Physical location varies more than the title suggests — plenty of the work is remote — so treat "forward" as describing organisational position, not geography.

Because the gap between a capable product and a working outcome is often not a feature at all. It is the customer's undocumented data, their idiosyncratic process, their integration surface, and the fact that nobody in the building has yet worked out what the software should do. A feature addresses a problem you can name for many customers at once; an FDE addresses a problem that is still unnamed at one. The commercial logic is that early deployments both earn revenue and generate the specification for the product, which is why this role concentrates at companies whose technology outpaces the market's ability to say what it wants from it.

Two things, and confusing them is the most common way a deployment goes wrong. The first is a running system doing load-bearing work inside a business process, which is what the customer paid for. The second is a specification: the account of what was genuinely hard, which parts were bespoke because the product lacked something, and what should therefore be built once for everybody. Only the first is contractually owed and only the second compounds. An FDE who ships the outcome and returns with no product feedback has done a consultant's job well and left the strategic half of the role undone.

It is product engineering staffed like consulting, and the tension between those two facts is the substance of the job. You are usually a permanent employee of the vendor, paid to advance the vendor's product position, working under the scheduling and access constraints of a consulting engagement. That means you carry a consultant's obligations — someone else's calendar, someone else's change window, a stakeholder who can stop you — while being judged by an engineering organisation on what you shipped and what you learned. Candidates who model it purely as consulting undersell the code; those who model it purely as product engineering underestimate how little of their week they control.

Problems where the difficulty is concentrated in the customer's specifics rather than in the algorithm. A pipeline that must reconcile three systems of record that disagree, a workflow whose rules live only in the heads of six operators, a model that needs data nobody has ever extracted before, a process where the correct output is obvious to a domain expert and impossible to define in writing. What these share is that no amount of remote requirement-gathering resolves them, because the information does not exist in a form that can be sent to you. The poor fit is the opposite: a well-specified integration against documented APIs, which is cheaper to do remotely.