Forward Deployed Engineering

What this area actually covers

A forward deployed engineer writes production software inside somebody else's organisation. That sentence is the whole boundary of the area, and every other characteristic of the role follows from it. The customer's data is the input, the customer's systems are the runtime, the customer's staff are the immediate colleagues, the customer's security team decides what is possible, and the measure of success is that a process inside the customer's business behaves differently afterwards. You remain an employee of the vendor and you are judged by the vendor's engineering organisation, but almost nothing you need in order to work belongs to your employer.

The title came out of Palantir, where the model was that an engineer goes to the customer rather than a requirements document coming back, and it is now used heavily by AI-infrastructure companies — OpenAI, Anthropic, Scale and a long tail of smaller vendors — for the same underlying reason. Their technology is more capable than the market's ability to specify what it wants from it. A customer who cannot articulate a requirement cannot be served by a feature request, and a vendor whose product is ahead of the demand curve cannot wait for the specification to arrive. Sending an engineer is what closes that gap.

Three things are true of the work and untrue of most engineering jobs. The problem is not specified when you arrive, and a substantial part of your first fortnight is spent working out what it actually is by watching people do their jobs. The data is not documented, or is documented wrongly, so the schema you were given is a hypothesis to be tested with profiling queries rather than a contract. And your own presence is the largest hidden dependency in the system you build, which means handover is not a closing formality but a design constraint that shapes what you choose to build in the first place.

What gets wrongly bundled in is worth naming early, because it determines whether you prepare for the right interview. This is not presales: presales work happens before a signature, and its deliverable is a credible technical promise. This is not account management or customer success: those own whether a customer gets value from what already exists, and their artefacts are escalations, adoption and renewals rather than merged code. And it is not consulting in the delivery sense, because a delivery consultant is measured against a scoped statement of work while an FDE is measured against an outcome and expected to change the scope when the scope turns out to be wrong. The distinguishing axis is simple enough to hold in one line: an FDE ships engineering work inside someone else's organisation.

Embedded delivery, customer data and scoping

The section has three subsections, and they are not three topics so much as the three distinct kinds of difficulty the job presents. Almost every FDE interview question sits in one of them, and candidates are usually strong in one and untested in the other two.

Embedded Delivery is the organisational half of the job. It covers the four or five stakeholders you meet in the first week and how each of them can end the project without ever refusing anything, what to do when the executive sponsor and the operating team want different outcomes, how to get a decision out of a customer with no obvious decision-maker, how to work with a customer engineer who reasonably suspects you are there to replace them, and how to hand over a system so that someone else is genuinely accountable for it. It exists as its own area because none of it is engineering technique and all of it is load-bearing: a technically excellent deployment with no owner at the end is a deployment that will be quietly abandoned, and that is the most common way this work fails. Expect scenario questions here rather than definitions, and expect them to be drawn from situations that have no clean answer.

Customer Data Integration is where the code actually gets written, and it is the most concretely technical of the three. It covers profiling a schema nobody has documented, the discipline of establishing whether the column you were told is the primary key really identifies what you think it does, reconciling two systems of record that disagree about the same entity, working without a staging environment, building on read-only production access, and handling extracts that arrive late or half-complete. It is separate because the skill is genuinely distinct from ordinary data engineering: you are not designing a pipeline for data you control, you are conducting an investigation into data whose owners have partial and often mistaken beliefs about it. What a reader will find here is code, profiling queries and reconciliation arithmetic rather than prose about stakeholders.

Scoping Under Ambiguity is the judgement layer that decides whether the other two matter. It covers what to do with a request like "we want AI in our claims process", what a shippable increment is and why most declared milestones are not one, how to compress a vague objective into two weeks of work by cutting scope rather than quality, how to write down what you are deliberately not building, and how to handle the moment when the problem you were sent to solve turns out not to be the real problem. It exists separately because it is the part interviewers probe hardest and candidates rehearse least. The characteristic failure here is symmetrical: engineers who start designing before they have narrowed, and candidates who ask clarifying questions indefinitely and never commit to anything concrete.

Where it sits in a real business

Follow the money and the role's position becomes obvious. A vendor sells something whose value depends on work that has not been done yet — integration into an estate nobody has mapped, a workflow that exists only in the habits of the people who perform it, data that has to be understood before it can be used. Sales creates the contract; the product provides the capability; and neither of them closes the distance between a capability and a changed business process. The forward deployed engineer is the function that closes it, which puts the role on the revenue critical path while giving it authority over almost nothing.

flowchart TD
    SALES[Sales<br/>signs the contract] --> FDE[Forward deployed engineer<br/>ships the outcome]
    PROD[Product<br/>provides the capability] --> FDE
    FDE --> CUSTOPS[Customer operating team<br/>must change how it works]
    FDE --> CUSTPLAT[Customer platform team<br/>grants access and hosts it]
    FDE --> CUSTSEC[Customer security<br/>decides what is allowed]
    FDE --> PRODBACK[Product backlog<br/>receives what should be built once]
    CUSTOPS --> VALUE[A process behaves<br/>differently, or it does not]

The edge to look at is the last one, because it is the only one that decides whether the engagement succeeded and it belongs to a team in another company. The three edges above it all point at people who can stop you, and only one of them — security — is likely to say no out loud. The others block by omission: an access request that is never refused and never granted, a process change that is agreed in principle and never scheduled. Detecting a block that nobody has declared is a large part of the skill, and it is why experienced FDEs treat silence as a signal rather than as consent.

The edge pointing to the product backlog is the one that distinguishes this role from consulting, and it is the reason vendors staff it with their own engineers rather than buying the capacity from a systems integrator. Every deployment produces two outputs: a result for one customer, and a specification for the product. The first is contractually owed and the second compounds. When the same awkward mapping has to be written by hand at the third customer, that is no longer a customer specific, it is a missing feature, and the FDE is the only person positioned to know it.

There is a commercial consequence worth stating plainly. Because this role sits after the signature and before the value, it inherits every optimistic assumption made during the sale. Reading the proposal before the first meeting is not diligence, it is self-defence: the assumptions written to make a deal closeable are precisely the ones that will be discovered to be false on your time, and knowing which they are lets you raise them in week one when it is still cheap.

A deployment walked end to end

Deployments have a recognisable shape, and knowing it is what lets you answer "where are you and what is blocking you" without narrating a task list. The useful mental model is a sequence of states rather than phases, because a deployment stalls in a state and can sit in one for months while activity continues.

flowchart TD
    A[Access requested<br/>on day zero] --> B[Process observed<br/>and problem narrowed]
    B --> C[Increment agreed<br/>with a baseline recorded]
    C --> D[Running in production<br/>on real data]
    D --> E[One named team using it<br/>for real work]
    E --> F[Owner operates it<br/>through a real incident]
    F --> G[Old process<br/>switched off]

The transition worth studying is the last one, because until the old process is switched off the customer is running both, which means you have added work rather than removed it and the measurable benefit is close to zero. Parallel running is the politest form of failure in this discipline: nobody objects, nothing is cancelled, and nothing is realised either.

The second thing the sequence shows is where the calendar goes. Access sits at day zero because it is the longest-lead dependency in the whole engagement, and in a large enterprise it routinely takes weeks: a vendor security review, a data owner's approval for specific tables, identity provisioning with device requirements, and a network route, each owned by a different team and none of them measured on your timeline. Those queues run in parallel if they are all started on day zero and serially if they are discovered one at a time, which is the difference between three weeks and two months. A plan that assumes a query on day three has already lost a fortnight, and the right thing to put in that fortnight is the observation and scoping work that needs no access at all.

The third observation is about the fifth and sixth states, which look similar and are not. A team using something for real work is a genuine achievement. A system with users and no accountable owner has a life expectancy equal to the patience of whoever currently tolerates it, and the transition between those two states requires a conversation with the customer's management about allocating capacity — which most engineers do not think is theirs to start, and which is in practice the single highest-value thing an FDE does.

Who does this work

Titles vary more in this area than in almost any other on this site, which is itself something to plan for: the same work is advertised under at least six names, and two roles with identical titles at different companies can be quite different jobs.

Read the deliverable column rather than across the rows, because that column decides what your week contains and what you are graded on. Anyone whose deliverable is a document will spend their week in conversations; anyone whose deliverable is a running system will spend it in a repository and a query console, and will still have to hold the conversations. The pairing of deployment strategist and forward deployed engineer, which some companies run as two roles on one deployment, is worth understanding as a division of labour: one owns what the right thing to build is, the other owns building it, and where a company has only one of the two titles, that person does both.

A representative fortnight looks like this. The first week has no code in it at all: an access request raised and chased through four teams, three mornings sat with the people who perform the process you were sent to improve, a recurring slot negotiated with the one domain expert who knows the rules, and a scoping note written and circulated with a list of assumptions and their named owners. The second week has profiling queries that contradict two things you were told, a conversation with the platform team about where this will run and who will own it, a first increment that is narrower than the sponsor expected, and an afternoon recording the baseline nobody thought to measure.

Seniority in this role moves along an unusual axis. It is not primarily about system scale, as it is in backend engineering, and not primarily about breadth of technology. It is about how ambiguous a situation you can be dropped into and still produce a defensible plan, and how senior a person you can disagree with constructively inside a customer. A senior FDE is someone who can tell a customer executive that the premise of their project is wrong, with evidence, and leave the room with the relationship intact and a better project agreed.

Demand, adoption and how that is changing

Demand is high and the reason is specific. A generation of AI-infrastructure companies has products whose capability exceeds their customers' ability to specify a use for them, and that gap cannot be closed by documentation, a sales engineer or a feature. It is closed by an engineer sitting inside the customer for two months. As long as the frontier keeps moving faster than enterprise absorption, this role has structural demand, and the frontier moving is precisely the condition these companies exist in.

Two further forces push the same way. Enterprise buyers have been burned by platform programmes that were technically delivered and never used, so they now want the vendor's own engineers on the hook for an outcome rather than a handover document. And the integration surface has got harder rather than easier: data residency rules, restricted access, estates nobody has mapped, and security review processes that assume no external engineer will ever be granted anything. All of that increases the amount of work that can only be done on site.

Three honest qualifications belong here, and they matter more than the demand level. The first is concentration. This is not a role advertised by every company that writes software; it is concentrated in a relatively small number of employers, mostly vendors whose product is both technically demanding and sold into large organisations. That means the number of openings is meaningfully smaller than for backend or platform engineering, and it means a downturn at a handful of companies moves the market for the whole title.

The second is that titles vary wildly for substantially the same work, so searching for the exact phrase will hide most of the opportunities. Field engineer, deployment engineer, implementation engineer, solutions engineer and several internal names all describe versions of this job, and the only reliable way to tell is to read what the role is measured on and whether it writes production code. Conversely, some roles advertised as forward deployed engineering turn out to be presales with a fashionable label, which is a reasonable job and a different one.

The third is temperament, and it is the real filter. The work suits people who are energised by an under-specified problem and by other people's organisations, and it makes people who want to own one system deeply and improve it under load persistently unhappy. That is not a small preference to get wrong, because nothing about the role changes with seniority in that respect: a staff-level FDE is still working on somebody else's estate, on somebody else's calendar, and still leaving the interesting problem at the point where a product engineer would settle in.

What makes it hard

The genuine difficulty is that you are accountable for an engineering outcome inside an organisation over which you have no authority, using inputs you cannot schedule, against a specification that does not exist. Each clause generates its own hardness, and none of them is the one candidates prepare for.

Ambiguity is the first, and it is harder than it sounds because the failure is bidirectional. Start building too early and you build the thing that was asked for rather than the thing that was needed, which is how a technically successful deployment produces no benefit. Refuse to build until the problem is clear and you never start, because the problem will not become clear from asking — it becomes clear from watching a process being performed and from a first increment that turns out to be wrong in an informative way. The skill is knowing how much narrowing is enough, and the observable form of that skill is being able to say what you are deliberately excluding.

The second is that the data lies, and not out of malice. Everyone inside a business describes their data as they believe it to be, and their beliefs were formed before the last two migrations. A column documented as an enumeration of five values will carry forty; a field described as never null will be null in four per cent of rows for a reason that is a genuine business rule nobody thought to mention; a key will turn out to identify a version rather than an entity, so every total you compute is silently too high. The discipline is to treat the data as the only authoritative account of itself and to profile before designing, and the disposition that goes with it is curiosity rather than complaint: a distribution that contradicts what you were told is usually describing something true about the business.

The third is the access boundary, which is the hardness nobody warns about. Weeks of an engagement can be consumed by a queue of approvals nobody is refusing, and the correct response is neither to wait nor to seek an informal exception.

sequenceDiagram
    participant FDE as You
    participant Sponsor as Their sponsor
    participant Sec as Their security team
    participant Owner as Their data owner
    FDE->>Sponsor: Access needed, named tables, stated purpose
    Sponsor->>Sec: Vendor and purpose review
    Sponsor->>Owner: Approval for those tables only
    Sec-->>FDE: Device and network conditions
    Owner-->>FDE: Read access, production, no writes
    FDE->>Sponsor: Scope note updated with what read-only allows

The thing to notice is that every arrow leaving you goes to the sponsor rather than directly to the teams that decide. That is not deference, it is mechanics: an external engineer has no standing to raise an internal approval, and the two requests at the top are parallel rather than sequential, which is the difference between three weeks and two months. The last arrow is the one candidates omit entirely — when the access you were granted is narrower than the access you planned for, the scope changes, and saying so in writing is what stops the shortfall being attributed to you later.

The fourth is that your own presence is the deployment's largest undeclared dependency. While you are there, the manual data preparation gets done, the unexplained failure gets fixed within the hour, the domain question gets answered because you are in the building. All of that disappears on your last day, and a system whose reliability depended on it will fail in the first week of its unattended life. Designing against your own absence from the start is the part of this job where experience is least substitutable, because it requires having watched something you built die quietly after you left.

Why study it

Study it if you like engineering and you like organisations. In a year you will see more real production estates, with more of their embarrassing history exposed, than a product engineer sees in five, because customers show you the truth when they need help. You will also acquire a rarer skill than the code: knowing how to convert a vague business complaint into something buildable, which is the scarce input at the front of every software project and the reason FDEs move readily into product management, architecture and founding companies.

There is a specific case if you are already a strong engineer who has noticed that technically excellent work sometimes produces nothing. This role is where you find out why. The answer is usually not technical, and watching it happen from inside the customer — the sponsor who left, the team that kept the spreadsheet, the system with no owner — changes permanently how you scope and hand over work, even if you go back to a product team afterwards.

The commercial case is also honest. Roles that require both real engineering ability and the willingness to be the only technical person in a room with a customer's director are persistently harder to fill than either half separately, because most candidates have one and not the other. If you can do both credibly, the field you are competing in is much thinner than the one you compete in as a backend engineer.

Do not study it if you want depth. You will leave every problem at the point where it becomes interesting, hand it to somebody else, and start again somewhere worse documented. Do not do it if the ambiguity would grind at you rather than energise you, because there is no seniority at which the problems arrive specified. Do not do it as a route into research or into a pure product engineering role; it is adjacent to both and does not become either by default. And be honest with yourself about the logistics, which the recruitment pitch underplays: travel, other people's time zones, and a working week whose shape is set by a calendar you do not control.

Your first hour

Do a profiling pass on a dataset you did not create, and let it contradict you. Take any public dataset with a plausible business shape — a transactions extract, a permits register, a claims or complaints file — and before opening it, write down five things you expect to be true: which column is the unique key, which fields are never empty, what values a status column takes, the date range, and which two tables join cleanly. Commit to the list in writing, because the value of the exercise is in the disagreement.

-- Is the key a key at all
select count(*) as rows, count(distinct claim_ref) as distinct_refs
from claims_detail;

-- What the column you were told was an enum really contains
select status_code, count(*) as n
from claims_detail
group by status_code
order by n desc;

-- Whether the nulls are a defect or a business rule
select channel,
       count(*) as rows,
       count(*) - count(underwriter_id) as nulls
from claims_detail
group by channel;

Run those three and check them against your list. The first tells you whether every count you were about to build is wrong. The second is where documentation usually dies, in a long tail of case variants, decommissioned codes and one region's private convention. The third is the one that teaches the most: nulls spread evenly across every dimension are usually a defect, and nulls concentrated in one channel are usually a real business rule nobody mentioned, which means imputing a value there would have been actively harmful.

Then write the second artefact, which is the one an interviewer would actually want to see. Half a page containing the outcome you would aim at in the customer's own words, the one named person whose behaviour would change, what you would explicitly not build in the first increment, three assumptions each with a named owner, and the baseline number you would record before writing any code. That half page is a scoping note, it is the first real artefact of the job, and it is worth considerably more in a loop than a memorised definition of the role.

What this is not

It is not presales, and this is the confusion worth being most precise about. Presales work happens before a signature and its deliverable is a credible technical promise: discovery, a proposal, a demo, a proof of concept with written exit criteria. Forward deployed engineering happens after the signature and its deliverable is something running. The two are complementary rather than overlapping, and the relationship between them is directional — an FDE inherits the presales engineer's assumptions and discovers which of them were false. If what appeals to you is the room, the whiteboard and the deal, that is presales and it is a real discipline with its own craft.

It is not customer success or account management. Those functions own whether a customer gets value from what already exists, and they are measured on retention, adoption and renewal. A technical account manager debugs an integration in order to establish whose fault it is; a forward deployed engineer writes the integration. Both spend the week on a customer's problems, and only one of them merges code. Where a small company has one person doing both, the honest question in an interview is which artefact the role is graded on.

It is not delivery consulting either, despite the superficial similarity of being embedded and billable. A delivery consultant is accountable against a statement of work, and changing the scope is a commercial event with a change request attached. An FDE is accountable for an outcome and is expected to change the scope when the scope turns out to be wrong, which is a different relationship to the same customer and a different professional obligation. The vendor also wants something a consultancy does not: the specification for what should be built once, for everybody.

It is not a travelling support role, and it is not a junior route into a product team. The work requires the ability to ship production software without a team around you and to be the only technical voice in a room with people far senior to you, which is why the role tends to be filled at mid-level and above. Companies that staff it juniorly usually discover that the constraint is not coding speed but the judgement to say that a premise is wrong.

And it is not less rigorous than product engineering. The rigour moves rather than lessening. Correctness under test becomes correctness against data you did not create and cannot fully see; design review by colleagues becomes design defence in front of a customer's platform team; and the ordinary safety net of a team that will notice your mistake is replaced by a handover document and the knowledge that in a month nobody in the building will know why you did it that way.

The measure of a forward deployed engineer is not what they built while they were there, but what was still running, owned and relied upon six months after they left.