Forward deployed engineering is production software work done inside a customer's organisation: their data, their access controls, their competing stakeholders, and a business problem nobody has specified properly. The deliverable is a running system somebody else can own after you leave.
High demand21 min readForward Deployed Engineer, Forward Deployed Software Engineer, Deployment Strategist, Field Engineer, Solutions Engineer, post-sale, Implementation EngineerUpdated 2026-08-11
Assumes you know: Enough software engineering depth to ship production code without a team around you, Comfort with SQL and with data that does not match its documentation, Willingness to work at someone else's pace, in someone else's building, on someone else's schedule
Overview
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.
Now practise it
11 interview questions in Forward Deployed Engineering, each with the rubric the interviewer is scoring against.
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.
Subsection
What it is for
Embedded Delivery
Operating as an engineer inside an organisation that does not employ you, and leaving something owned behind
Customer Data Integration
Building against data that is undocumented, restricted, and disagrees with what you were told
Scoping Under Ambiguity
Converting a vague business problem into something shippable, and deciding what not to build
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.
Loading diagram…
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.
Loading diagram…
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.
Title
Sits
Owns
Deliverable
Technical depth
Forward deployed engineer
After the signature
Working software on the customer's estate
A running system with an owner
Full production engineering
Deployment strategist
After the signature
The problem definition and the deployment plan
A scoped outcome and its adoption
Strong analytical, lighter build
Solutions engineer, post-sale
After the signature
Integration and configuration work
A live integration
Real, often narrower
Presales solution engineer
Before the signature
The technical promise
A proposal, a demo, a scoped POC
Broad, less hands-on build
Technical account manager
After the signature
The technical relationship and escalations
Resolved escalations, adoption
Real, diagnostic rather than build
Delivery consultant
Under a statement of work
Scope, hours and milestones
A signed-off milestone
Varies widely
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.
Loading diagram…
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.
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.
-- Is the key a key at allselectcount(*) asrows, count(distinct claim_ref) as distinct_refs
from claims_detail;
-- What the column you were told was an enum really containsselect status_code, count(*) as n
from claims_detail
groupby status_code
orderby n desc;
-- Whether the nulls are a defect or a business ruleselect channel,
count(*) asrows,
count(*) -count(underwriter_id) as nulls
from claims_detail
groupby channel;