Sonith ManakkatMost software is built far away from the people who use it. A forward deployed engineer (FDE) does the opposite: they go to where the problem is, work beside the people who have it, and build or adapt software until it works in the real world. The role has been getting a lot of attention, so this article explains it plainly, with a picture first and an Expert view in each section.
The short version
An FDE is a software engineer embedded with customers. They learn how a customer's business really runs, make technology work inside it, and stay close enough to see whether it helped.
Expert viewA working definition
There is no single official definition. A practical one: an engineer who is accountable for a customer's outcome with the product, not only for the product's code, and who therefore combines engineering depth with customer-facing work. Anthropic's announcement of its Claude Frontier Academy (below) describes FDEs as engineers who can "take Claude from an idea to a system in production", working inside client organisations from use-case selection through security review to handover.
The chef analogy
A restaurant
- A fixed menu from a distant kitchen
- You never see how it is made
A chef in your kitchen
- The chef looks in your fridge and asks who is eating
- Cooks with your pots, for your table
Where the term comes from
The practice is most closely associated with Palantir, a US software company, which has used the title Forward Deployed Software Engineer for engineers who deploy its platforms at customers, and nicknames the role "Delta" inside the company. Embedding engineers with customers is older than any single company, for example vendors who sent engineers to customer sites to install and customise systems, but the FDE label spread widely after Palantir's use of it. This article has no connection with Palantir.
Expert viewOn certainty
I have not been able to confirm exactly when the public term first appeared, and the Palantir engineering blog page I tried to read returned an access error, so my description of its "Delta" naming rests on search summaries and should be treated with care. The reliable claims are the modest ones: the label is widely associated with Palantir, and embedding engineers at customer sites predates it.
What the work looks like
- DiscoverSit with the users, watch the real process, ask why
- PrototypeBuild something small that works well enough to try
- DeployPut it into real use with the customer's data and constraints
- FeedbackWatch what happens, fix it, and pass learning to the product team
Expert viewWhy the loop is short on purpose
The shorter the distance between a real problem and a working solution, the faster everyone learns. Experts add two disciplines: write down what you learn so the product team can generalise it (otherwise every deployment is a one-off), and decide early what is a customer-specific adaptation versus a product gap. Without that line, FDE teams drift into becoming a bespoke consultancy.
- Customer to FDE The customer describes a pain point, often not the real one.
- FDE (to itself) The FDE watches the real process and finds the actual problem.
- FDE to Customer A small working prototype goes into real use.
- Customer to FDE (reply) The customer reports what worked and what did not.
- FDE to Product The FDE records what was learned and which parts look general.
- Product to FDE (reply) The product team decides what becomes a product change.
Takeaway. The write-up is what stops every deployment being a one-off.
- 1Would other customers likely hit the same problem?Yes A product gap. Write it up for the product team.No keep going
- 2Does it depend on this customer's own systems, data or rules?Yes A customer-specific adaptation. Keep it in the deployment and document it.No keep going
- 3Is it a quick workaround to unblock them today?Yes Do it, then log it as a possible product gap.No keep going
- 4OtherwiseWrite down what you know, and decide with the product team.
Takeaway. Decide early which fixes belong to the customer and which belong to the product.
How it differs from nearby roles
| Role | What they mainly do | Time with customers |
|---|---|---|
| Software engineer | Builds the product for many customers, usually from a distance. | Little with any one customer |
| Forward deployed engineer | Builds and adapts software for specific customers, on site or close by. | A lot |
| Solutions engineer | Often supports sales: demos the product, designs how it would fit, helps with early set-up. | A lot, mostly before and during set-up |
| Consultant | Advises on strategy or process, and may not build the software itself. | A lot |
| Product manager | Decides what the product should do, across all customers. | Some |
FDE is a sales job
It is an engineering job done close to customers. It can support sales, but the work is building and fixing.
FDEs just write throwaway code
Good FDE work feeds the product: patterns found at one customer become features for all.
Expert viewBoundaries are fuzzy
Titles vary between companies, and some people do several of these jobs. A useful test is what you are held accountable for: a software engineer for the quality of the product, a solutions engineer for the quality of the fit before the sale, a consultant for the quality of advice, a product manager for the quality of the product decisions, and an FDE for whether the customer actually succeeds with the software in production.
Skills that matter
- Strong engineering basicsYou must build things that work.
- Fast learningEvery customer has a new domain and vocabulary.
- ListeningThe real problem is often not the first one described.
- CommunicationExplaining technical choices to non-technical people.
- OwnershipYou stay with a problem until it works.
- JudgementQuick fix, or build it properly?
Why AI makes the role more important
Anthropic's announcement of its Claude Frontier Academy on 2 October 2026 gives one view. It says the main obstacle to enterprise AI is talent: the people who can make AI work inside a real business, whom it calls the "hardest talent to find".
- $100Mcommitted to the academy
- 10,000Frontier Deployed Engineers to train by end of 2027
- 12 weeksresidency inside the participant's own company
Expert viewThe academy's structure, as announced
Anthropic describes the first programme, the FDE Residency, as modelled on medical training with three stages: a multi-day in-person programme with a simulated enterprise deployment and a graded practical (earning a Claude Resident Engineer badge); a 12-week residency in which engineers lead a real Claude use case at their own organisation, supported by Anthropic engineers; and a final assessment (earning a Claude Frontier Deployed Engineer badge, the first expected in early 2027). Cohorts are running in San Francisco, New York and London, and participation is by nomination from organisations. Candidates are described as hands-on software engineers with strong fundamentals, a record of building with LLMs and experience helping others adopt AI. This is Anthropic's own programme and its own description; treat it as one company's view of the role.
Stay close to the problem, build something real, and bring what you learn back.
How to become one
- Get good at buildingLearn one stack well, and ship small real projects
- Practise discoveryBuild for a real person, watch them use it, change it
- Learn a domainWarehousing, healthcare, finance, factories
- Use AI tools wellKnow their strengths and limits, and always review the output
- Show your workA portfolio of problems solved matters more than a title
Frequently asked questions
Is forward deployed engineering a sales job?
No. It is an engineering job done close to customers. It can support sales, but the work is building and fixing.
Do FDEs travel a lot?
It depends on the company and the customers. Some work on site, some remotely with frequent contact.
Do I need a computer science degree?
Many FDEs have one, but what matters most is that you can build, learn fast and communicate. Check the requirements of any role you are interested in.
Is the role only for big technology companies?
No. Any organisation that rolls out complex software to customers may use some version of it.