What does a forward deployed engineer do?

The short version: a forward deployed engineer builds software inside somebody else's company, learns what it should do by being there, and stays until it runs.

The longer version is worth having, because the daily shape of the work is what separates this role from the four or five jobs that look like it on paper.

Four activities, repeating

Discovery inside the environment. Sitting with the people who will use the software, watching what they actually do, and finding the parts of the process nobody mentioned in the kickoff. This is not a phase that finishes. It runs alongside the building, because building is what surfaces the next question.

Building. Production code, in a repository, reviewed and merged. This is the bulk of the week and the thing that makes the role engineering rather than advisory. In the 1,000 postings analysed by Henley Wing Chiu in November 2025, the roles that were genuinely production-focused reported 70 to 90 percent of time spent coding.

Integration. Connecting to the systems that already exist, which in a large company means authentication, an identity provider, a data warehouse somebody built in 2014, and an API whose documentation describes a version that was replaced. Integrations were named in 32 percent of postings.

Getting to production. Change advisory boards, security review, a penetration test, a data protection assessment, a release window. This is the part that surprises engineers coming from a product company, and it is where deployments die.

What a week looks like

Not every week, and the shape recurs.

Monday tends to be alignment: what shipped last week, what the customer's own team is blocked on, what the next thing to prove is. Tuesday to Thursday is where the code gets written, usually with one or two conversations a day pulled in as questions come up. Friday is often the ugly-but-important half: the review comments, the deployment paperwork, and writing down what was learned so it is not lost when the engagement ends.

Running through all of it is a habit that defines the role: ship something small every week, against real data. Not a demo. Something a real user can open. Week-one output is the strongest scoping instrument in the model, because what breaks when you try to ship something small tells you more about the engagement than any discovery document. What a forward deployed engineer ships in week one goes into that.

The 20/80 rule, and why it matters

First Round Review's February 2026 guidance on hiring forward deployed engineers puts the time allocation at around 20 percent customer-facing and 80 percent building.

Treat that as a diagnostic rather than a target. When the split drifts toward half and half, one of three things has happened: the scope is unclear so the engineer is in meetings trying to establish it, the customer's organization is blocking and the engineer has become the person chasing approvals, or the role was a sales engineering role all along and nobody said so.

All three are fixable and none of them get fixed by the engineer working harder. They get fixed by somebody senior deciding what the deployment is for and who unblocks it.

What the job is not

It is not writing reports. A forward deployed engineer who spends the week producing documents has been handed a consulting engagement with a different job title.

It is not running demos. Demos happen before the contract, and that is a sales engineering role. Of the 1,000 postings analysed, none of the forward deployed roles carried a sales quota, which is the cleanest single test for telling the two apart.

It is not owning the customer relationship. Somebody has to, and it should not be the person whose week is supposed to be 80 percent building.

The part nobody puts in the job advert

Two things make this job harder than an equivalent product engineering job, and neither is technical.

The first is working without a specification. You are handed a vague problem, a real deadline, and an environment you did not build. Nobody can tell you what correct looks like, so part of the job is establishing that, out loud, in front of people who disagree with each other.

The second is saying no. Every embedded engineer accumulates requests, and each one sounds reasonable on its own. First Round's rule is the useful one: expand the scope when the work creates something reusable, and stop when the next iteration will only ever serve this one customer. Somebody has to make that call weekly, and if it is not made the engagement never ends. What goes wrong in forward deployed engagements collects the failure modes and their early warning signs.

How this differs by company

The role is not standardised, and the biggest variable is what the engineer is building on.

At a company with a mature platform, the forward deployed engineer configures, extends and integrates, and the custom part is thin. At an earlier company, the engineer is writing much more from scratch, and the risk is that the result is a fork nobody can maintain.

The AWS Partner Network's description of its partner-led model names what the mature version looks like: reusable delivery harnesses including domain ontologies, evaluation frameworks and capability registries. That is the tooling that stops each deployment from starting at zero, and building it is part of the job once more than one customer exists.

Where we sit

We work this way, so the honest version is worth stating. The build side of that 80 percent is AI-written on our engagements, and every change has to pass an eval suite derived from the specification before it reaches your branch. That changes the arithmetic of the model: the discovery, the integration and the path to production still take a person, and the typing takes less time than it used to. What it does not change is who is accountable when it does not run.

If you want the mechanics of an engagement rather than the shape of a week, read how a forward deployed engagement runs. If you are deciding whether the role is what you need, the three jobs hiding behind the title comes first.