ROLE DEFINITION

What's a Forward Deployed Engineer?

The definition, where the title came from, the inversion that defines the work, and where the industry genuinely disagrees.

A forward deployed engineer is an engineer who works inside a customer's organization to make software actually land there — writing production code, integrating with systems they don't control, and taking responsibility for whether the thing works in the customer's world rather than in a demo.

The short version of what makes it different:

Almost everything distinctive about the role follows from that inversion.

Where the title came from

The term is borrowed from military vocabulary, where forward deployed means operating at the point of action rather than from a rear base.

Palantir created the role in the early 2010s — internally nicknamed Delta — and built an unusual company around it: engineers embedded in customer facilities for weeks or months, committing to customer repositories, debugging pipelines on customer hardware, attending customer standups. The model was strange enough at the time that industry analysts wrote about it as a category of one.

It's not a category of one any more. Anduril, Scale AI, and OpenAI run versions of the same model, and by 2026 the pattern has spread well beyond defence and frontier AI into any company selling software complex enough that buying it's not the same as using it.

What the work actually involves

On a normal week, a forward deployed engineer might:

  • Sit in the customer's standup and take real tickets
  • Write a data pipeline against a schema nobody has documented since 2011
  • Discover the documented process and the actual process are different, and redesign around the actual one
  • Run a workshop with an operations director who doesn't want this project to succeed
  • Ship something small and visible to keep a sceptical stakeholder engaged
  • Explain to their own product team why the roadmap assumption is wrong
  • Get blocked by a security review and find a path around it that's still compliant

The code is real. The customer-facing accountability is real. Neither one is optional, and that combination is what makes the role hard to hire for.

What it's not

Not a solutions architect. Architects design and hand off. FDEs build and stay.

Not a sales engineer. SEs sell the thing. FDEs are accountable after the signature, when the difficult part starts.

Not a consultant. A consultant's output ends at the customer boundary. An FDE's job includes bringing field reality back so the product changes. Remove that loop and you've an expensive contractor with a better title.

Not a support engineer. Support restores what exists. FDEs build what doesn't.

Where the industry genuinely disagrees

We would rather name the open arguments than paper over them. These are unsettled, and this community is a reasonable place to settle them.

Does an FDE need to be a strong engineer, or a strong communicator who codes? Job descriptions split roughly evenly. Our position is that the engineering bar is real and non-negotiable, and that communication is the axis on which strong engineers most often fail the role — but reasonable people disagree, and hiring bars differ accordingly.

Is "AI FDE" a different role? A large share of 2026 postings are AI deployment roles wanting retrieval, evaluation discipline, and agent orchestration. We treat that as current stack inside Technical Breadth rather than a separate axis, because a standard organised around this year's stack is obsolete in two years. Some disagree and want it broken out.

Does the role have a ceiling? Some organizations treat FDE as a stepping stone to product engineering or management. Others run it as a terminal senior track with principal levels. Our framework assumes the second, which is a position, not a neutral observation.

Is it sustainable? Travel, customer pressure, and being permanently between two organizations burn people out. Nobody has published an honest account of that. Someone should.

Where you fit

The framework defines four levels across six competency axes, written as observable behaviour rather than adjectives.

If you want to know where you stand, the assessment takes about three minutes and needs no account.