A senior engineer, deployed inside.
A Forward Deployed Engineer sits at the customer site and fills the gap between what their company’s product can do and what the customer actually needs — closing it with working software, shipped from inside the operation, in days.
- Solutions engineering
- Consulting
- Professional services
- A ticket queue with travel attached
Operating. The FDE sits next to the people who do the work, lives their day, finds the problem that actually matters — then builds the solution into the customer’s environment and stays until it holds.
The name comes from the military: a forward deployed unit doesn’t sit at headquarters — it operates inside the environment where the problem is happening. So does the software engineer.
Born at Palantir.
The model wasn’t invented for the AI era. It was proven over two decades, by a company that built a generational product by refusing to design it at headquarters.
- THE FIELD
In the 2000s, Palantir began embedding engineers inside its customers’ operations — agencies, militaries, then banks and factories — building whatever it took to deliver the outcome. The customers couldn’t say what they needed; the engineers found out by being there.
- THE LESSON
The product team’s real job became extracting the general capability behind what the field built — always one level of abstraction up from any single customer’s ask. It landed in an ontology: a general model of objects, properties and links, flexible enough to serve any enterprise without forking the product.
- THE RULE
For years, nobody worked on core product without serving in the field first. The credibility to decide what generalises came only from battle scars — and the alumni of that rule went on to found a remarkable number of companies.
For years the model looked like a Palantir eccentricity — admired, rarely copied, too expensive for software economics. Then agentic engineering arrived, and the maths changed.
Gravel road, paved road.
Most software companies are built inverted: experts at headquarters decide what to build, and field engineers implement it off spec docs. FDE companies run the other way — figure out in the field what works, then generalise backwards. The whole machine is one loop.
GRAVEL ROAD
The FDE embeds at one customer, finds the problem that actually matters, and builds a working solution using frontier AI into their environment: fast and real, rough where rough is fine. The first version is allowed to be ugly. It is not allowed to be late, or wrong about the outcome.
PAVED ROAD
The platform maintainers choose what generalises. The field solution isn’t copied into the product — the more general problem behind it gets solved, so the capability serves the next five customers. Not just one.
LEVERAGE
The paved version comes back to the field as platform capability. The next deployment of the same outcome takes a fraction of the time — and the surplus goes into harder problems, which feed the loop again.
This is product development by backpropagation: radically orient around one customer’s outcome, build whatever it takes to deliver it, then generalise backwards. The FDEs are the discovery mechanism; the platform is the memory. Neither works alone.
The opposite of consulting.
The comparison everyone reaches for first — and the one that misses the entire point of the model.
Deliver. Invoice. Leave.
The engagement ends and the learning walks out the door with it. Every new client starts from zero, margins are capped by headcount, and nothing compounds. Selling effort, forever.
Deliver. Productise. Compound.
The FDE delivers the outcome — then what was learned gets generalised into the platform. Every deployment makes the next one faster; contracts grow as outcomes compound; the platform’s share of each deployment rises until the economics flip.
Why now: AI changed the maths.
Four facts explain why a model that looked too expensive for software economics is suddenly everywhere.
The adoption gap is the opportunity.
AI capability is racing ahead of the world’s ability to absorb it. Models can do astonishing things, and yet inside most enterprises the day-to-day feels unchanged. AI does not deploy itself — closing that gap takes human ingenuity, change management, and a real tolerance for pain.
There is no incumbent product.
In AI agents, nobody has the product yet. The market is a pile of heterogeneous segments that will each turn out to want different things. When there is no incumbent, product discovery is the entire game — and whoever discovers fastest wins.
Discovery only happens inside.
Sales-led discovery talks to enterprises from the outside and collects feature requests: what’s easy to ask for, which is rarely what’s valuable. The discovery that works happens on the floor of the operation, living the day of the people who run it. Customers don’t know what they want — they want a partner who figures it out with them, inside their walls.
The force multiplier arrived.
Bespoke software for every customer used to mean a team for every customer — that’s what made the model too expensive. Agentic engineering collapsed that maths: AI-leveraged engineers already operate an order of magnitude above pre-AI benchmarks, and the second order — 100× — is in sight. One FDE now ships what once took a team.
Adoption is the hard part.
Enterprises don’t buy AI tools — they buy their operation transformed. The model can already do the reasoning; adoption means changing how a shift, a queue, a workday actually runs. That cannot be done from headquarters, and it is exactly the part the FDE owns.
- WEEKS 1–2 · DISCOVERY
Inside the operation, next to the people who do the work. Map the systems, live the day, find the gap between what was asked for and what is actually worth building.
- WEEKS 3–6 · BUILD
Working software in the customer’s environment — their data, their security review, their constraints. First demo in days; a pilot with review dates already in the calendar.
- WEEK 7+ · ADOPTION
The unglamorous part that decides everything: training the team, reshaping the workflow around the new capability, making the humans guardians of the exceptions while the software carries the bulk. Then generalise what was learned, and go again.
This is why the role is exploding — search any job board. And the dual skill it demands, deep engineering plus enterprise navigation, is now the rarest profile in the market.
Who thrives.
The model hires on traits and treats backgrounds as evidence. Domain knowledge can be trained in weeks; the traits can’t be trained at all. Seven of them — the first three are non-negotiable everywhere this model runs.
Curiosity that crosses domains
You walk into a freight yard, a hospital ward, a control room — somewhere you’ve never been — and within two weeks you understand the operation well enough to see what nobody inside it can. Not curiosity about frameworks. Curiosity about forklifts. People who’ve never gone deep on a domain that wasn’t theirs find this role hard.
A very high sense of urgency
Days-to-value is the operating spec. The right person is constitutionally incapable of sitting on a solvable problem — they built the demo before the meeting where it was requested. People with urgency talk in days. People without it talk in phases.
Customer obsession — genuine, not salesy
No one likes being sold. What works: engineers transparently excited about the customer’s problem, and the customer can feel it on the call. The test is whether someone talks about customers as people whose day they lived, or as logos they closed.
Resilience, translated into product
Hard meetings, sceptical rooms, weeks where everything built gets ripped out. Raw tolerance is only half the trait — the real test is the transmutation: turning the hard week into notes, feature requests, platform improvements. Both kinds of people have war stories; only one has a changelog.
Appetite for ambiguity
Nothing is written. The customer’s ask is usually the problem that’s easy to ask for, not the one that’s valuable. The right person hears “go make this account succeed” and comes back with a plan, a demo, and three things nobody knew. The wrong person hears it and feels abandoned.
Prototyper, not cathedral-builder
Craftsmanship that needs perfect abstractions before shipping is a real and honourable skill — and it is not this job. The first version is allowed to be ugly; it is not allowed to be late, or wrong about the outcome. The paving is a separate, deliberate act at the platform level.
The splinter in the mind
The single best predictor: something to prove — that the outcome should happen, and that they’re the one who can make it happen. The splinter is what brings a person back Monday after the worst week of the quarter. Everyone great has one.
The wrong profile.
Each of these maps to a specific way the model fails. Said kindly, and said firmly: these are people who do great work somewhere — just not embedded alone inside an enterprise.
Asks who sets priorities, who writes requirements, what the process is. Best work was always well-specified. There is no spec in this model — the FDE writes it by building.
Needs the abstraction right before anything ships. Talks about technical debt as a moral failing. Spends the pilot window architecting and misses the go-live. Beautiful code, dead account.
Optimises for title and scope on paper. Asks about promotion ladders before asking about customers. The role’s currency is outcomes, and that’s illegible to them.
Polished, persuasive, vague on what they personally built. Customers buy outcomes from people who can build them — they smell charm without delivery immediately.
Would rather solve it over video calls. Being on-site makes everything an order of magnitude faster, and discovery only happens inside. Not negotiable — however brilliant.
Comfortable delivering and leaving. Measures success in engagements completed. Without the generalisation instinct, nothing compounds.
The summary test: could this person have started a company instead? If the honest answer is no, owning an account alone will break them. If it’s yes, every company running this model is hunting for them.
Where it leads: founder training.
An FDE spends years doing exactly what a founder does — find the real problem, build the product, deliver the outcome, grow the account — with platform leverage a solo founder would kill for, and someone else’s burn rate.
FDE
Own an account end-to-end. Build gravel roads that carry production traffic. Earn the right to the customer’s harder problems and grow the contract behind the outcomes. Build a résumé nobody else can replicate.
PLATFORM & PRODUCT
In mature FDE companies, the field is the only path into core product — full stop. Nobody earns the credibility to make generalisation calls without frontline scars. The platform team of year three is the FDE bench of year one.
POD LEAD
As the motion scales into pods and verticals, the people who ran the loop at one account run it across several. The founding cohort becomes the leadership bench.
FOUNDER-GRADE OPERATOR
In the same company — or in the one they eventually start. Some of the best leave to found things; that’s the strongest proof the role works. Companies that run this model would rather spend three years with someone who could, than thirty with someone who couldn’t.
The honest trade the role offers: the hardest, fastest, most exposed engineering job in software, in exchange for compressed judgement — product, engineering, and business at once — at a rate no other role builds. And you’ll never wonder whether the work mattered: the thing that took their team three days takes three minutes, and you watch it happen in person.