A few years ago, almost nobody outside Palantir had heard the phrase “forward deployed engineer.” Today it is on the careers page of nearly every serious AI company. OpenAI, Anthropic, Palantir, Databricks and a long list of startups are hiring FDEs as fast as they can find them. I want to explain what the role actually is, what is expected of the people who do it, and the skills it genuinely demands, because most of the descriptions floating around flatten it into a buzzword.
The short version: a forward deployed engineer is a software engineer who leaves the safety of the product team and goes to live inside the customer’s world, with its messy data, its security constraints and its urgent real problems, and builds the thing that actually works there. It is engineering, consulting and product management folded into one person. And it exists because the gap between what software can do in a demo and what it does in a real organization has never been wider than it is now, in the age of AI.
Where the role came from
Palantir invented the model in the early 2010s, where these engineers were known internally as “Deltas.” The company had a problem that no amount of clever product could solve on its own: its customers were large, secretive institutions whose data could not simply be handed over, and whose internal bureaucracy would swallow any normal software rollout. So Palantir stopped waiting for customers to integrate the product and sent engineers to do it on-site instead.
Palantir framed the distinction cleanly. A product engineer works on “one capability, many customers.” A forward deployed engineer works on “one customer, many capabilities.” Bob McGrew, who led forward deployed engineering there before going on to lead research at OpenAI, described it as building the rough gravel road to show where the product needs to go, so the core engineers can later pave it into a superhighway for everyone. That image is the whole philosophy in a sentence. The FDE proves what is possible in one hard, real place, and that proof becomes the map for the product.
What a forward deployed engineer actually does
The honest answer is that an FDE wears three hats at once, and switches between them constantly. In one week you are a software engineer, writing and reviewing production code. In the next you are a consultant, sitting with a customer to work out what they actually need as opposed to what they first asked for. In the next you are a product manager, deciding what to build and feeding what you learn back to the people building the core product.
Concretely, an FDE embeds with a customer’s team, often physically, for days or weeks at a time. Travel of twenty to fifty percent is normal, and the majority of the working week is customer-facing. You run technical discovery to understand the real problem, you scope a solution, and then you write production code that runs in the customer’s live systems, against their real and often sensitive data, inside their security and compliance constraints. You own the outcome from first conversation through go-live, not a demo you hand off to someone else. Palantir describes the responsibilities as resembling those of a startup CTO: a small team, high stakes, and end-to-end ownership.
One FDE described the rhythm well: the day-to-day changes month to month, which is the point. Some weeks are almost entirely code. Others are almost entirely people, data and strategy. If you need a predictable, bounded, heads-down job, this is the wrong one. If you are energised by owning a hard problem all the way to a result, it is one of the most satisfying roles in the industry.
Why the role is exploding right now
Forward deployed engineering is not new, but the demand for it is spiking for a specific reason, and it is worth being precise about it. Artificial intelligence has created an enormous gap between what a model can do in a polished demo and what it does when it is pointed at a real company’s data and workflows. Closing that gap is exactly what an FDE is for.
Three forces are driving the surge. First, enterprises genuinely cannot integrate this technology on their own, and their executives, quite reasonably, do not fully believe in it until they see it working on their own problem. A slide deck does not convince a skeptical operations director; an engineer who shows up, learns their process, and ships something that works does. Second, the economics finally justify it. AI deals now routinely run into seven figures, and at that contract size it is entirely rational to place an engineer on-site for weeks to make the deployment succeed. Third, and most interesting to me, the FDE closes a feedback loop. When OpenAI’s forward deployed engineers built evaluation metrics for a voice customer’s call-center problem, those metrics exposed real model gaps and fed directly into improvements to the Realtime API that then benefited everyone. Another OpenAI FDE worked with John Deere in Iowa to automate personalised outreach to farmers, on a timeline set by the planting season rather than by a product roadmap. The learning from one hard, real deployment becomes the product for the many.
This is the same reason forward deployed work sits so close to what I do when I help organisations deploy private, on-premise AI. The interesting problems are never in the model. They are in the data that is messier than anyone admitted, the network that cannot reach the internet, the compliance rule that rules out the obvious design, and the team that has to actually use the thing. You do not solve those from a distance.
What a forward deployed engineer is not
The role is often confused with three others, and the differences are the clearest way to understand it.
A software engineer builds the product for all users and rarely talks to a customer directly. An FDE writes roughly as much code, but splits the week between building and customer-facing work, and ships for one specific customer rather than for everyone. Scale is the software engineer’s first concern and the FDE’s second; the FDE’s first concern is that this customer’s problem is actually solved.
A solutions engineer or sales engineer is typically a pre-sales role. They run demos and proofs of concept, often with anonymised data, and they hand off after the deal closes. The forward deployed engineer is defined by what happens after that handoff: writing real production code on the customer’s systems and owning the result in production, not the promise of it in a pitch.
A traditional consultant advises and produces recommendations. The FDE advises and then builds the thing, in code, and is measured by whether it works. The distinction matters because it sets the skill bar. You cannot fake your way through this role on communication alone; the code has to run.
What is expected of them
Expectations for an FDE are unusually broad, which is exactly why the role is hard to fill. You are expected to own a customer outcome end to end, with the autonomy and the accountability of a startup CTO for that account. You are expected to be comfortable with heavy ambiguity, because what the customer describes in a first meeting rarely matches the reality of their data and systems, as OpenAI’s team puts it plainly. You are expected to travel and to work in unglamorous places, whether that is a factory floor, a hospital, or an airgapped room with no internet. You are expected to represent your company credibly in front of senior stakeholders one hour and debug a data pipeline the next.
Two expectations are less obvious and matter enormously. You are expected to feed the product, not just serve the customer, turning what you learn on the ground into better software for everyone. And you are expected to say no. The gravitational pull of a high-value account is to become its permanent private consultant, and the discipline to resist scope creep, to decide what is worth building and what is not, is part of the job rather than a distraction from it.
The skills a forward deployed engineer must have
The people who succeed at this have a T-shaped profile: real depth in one area, useful breadth across several others, and a genuinely high bar on the human skills that most engineering roles treat as optional. I group the skills into three.
Technical depth that survives contact with production. This is not negotiable. Your output runs in a customer’s live systems, not a sandbox, so you need solid software engineering fundamentals: the ability to write, debug and operate real production code. You need to be a polyglot, comfortable moving across whatever languages and stacks the customer already runs rather than the ones you prefer. You need to be good at integration, because most of the work is connecting to systems and data you did not design. And in the current wave, you need applied AI skills specifically: building retrieval-augmented generation pipelines, writing evaluations that measure whether a model is actually good enough, developing agents, and standing up the observability to know what is happening in production. Data skills sit underneath all of it, because the data is always the hard part.
Product and business judgment. An FDE decides what to build, which means running discovery well enough to find the real problem, scoping tightly enough to ship, and having the product intuition to know which of the customer’s requests is worth honouring and which will lead nowhere. You need enough understanding of the customer’s domain, and enough commercial sense, to see why a project matters to their business and not just to their engineering team. This is the judgment that separates an FDE from a very good contractor who builds exactly what they are told.
Communication and temperament. You will spend most of your time with people, so you need to communicate at an executive level and translate fluently between the technical and the non-technical. Just as important is temperament. The best FDEs combine confidence with a low ego and real humility, because you are a guest in someone else’s organisation and you will be wrong about their world more often than you expect. You need empathy, comfort with ambiguity, and a certain rebel streak, the drive to go into an undefined, messy situation and impose order on it. And you need boundaries, because without them the role will consume you.
None of these skills is exotic on its own. What is rare, and what commands the salary, is holding all three at once in the same person.
The trade-offs, and who it is for
I would be doing you a disservice to sell the role without its costs. The travel is real and, for some people, wearing. Burnout is a genuine risk, because you are often the person on the hook for the hardest deployment, and doing it well earns you more of them. The career path can be ambiguous: some FDE organisations are flat, with titles that do not map neatly onto the rest of the industry, and it is possible to spend so long embedded in customers that you drift from your own engineering culture. The role’s definition also varies wildly from company to company, so “forward deployed engineer” on two job descriptions can mean two quite different jobs.
Against that, the upside is substantial. You get ownership and visible impact of a kind that is hard to find on a core product team, you get paid well for it, and the role is a well-known incubator for founders and leaders, precisely because it forces you to do a bit of everything under pressure. Many Palantir FDEs went on to start companies, and that is not a coincidence.
So it comes down to fit rather than prestige. If you value ownership, impact and variety, and you can handle travel and ambiguity, it is one of the best seats in technology right now. If you want predictable hours and bounded, heads-down work, it is not for you, and there is no shame in that.
The human bridge
Strip away the hype and the forward deployed engineer is the answer to a very old problem wearing new clothes. Powerful technology is worthless until it meets a real problem in a real place, and meeting it there takes a person who can do the engineering, understand the business, and win the trust of the people who have to live with the result. AI has made that person more valuable than ever, because AI has widened the distance between the demo and the deployment. The FDE is the human bridge across that distance.
It is also, not coincidentally, a good description of what serious consulting looks like in the AI era, and of the work involved in deploying private AI inside an organisation’s own walls. The title is new. The discipline, embedding with the people who have the problem and building until it is genuinely solved, is as old as good engineering. The theory has always said that software only matters where it meets the real world. The forward deployed engineer is that theory, made into a job.
Frequently asked questions
What is a forward deployed engineer?
A forward deployed engineer (FDE) is a software engineer who embeds directly with a customer to build and ship a production solution inside that customer’s own environment. The role blends engineering, consulting and product management: running discovery, writing real code against the customer’s data and systems, and owning the outcome from first conversation to go-live. It was pioneered by Palantir and is now central to how AI companies deploy into enterprises.
How is a forward deployed engineer different from a software engineer?
A software engineer builds the product for all users and rarely deals with customers directly, with scale as the first concern. A forward deployed engineer writes roughly as much code but splits the week with customer-facing work, ships for one specific customer rather than everyone, and treats “does this customer’s problem actually get solved” as the primary goal. The FDE lives in the customer’s world; the software engineer lives in the product.
How is a forward deployed engineer different from a solutions or sales engineer?
Solutions and sales engineers are usually pre-sales: they run demos and proofs of concept, often with anonymised data, and hand off once the deal closes. A forward deployed engineer is defined by what happens after that handoff, writing production code on the customer’s real systems and owning the result in production rather than the promise of it in a pitch.
What skills does a forward deployed engineer need?
A T-shaped profile: strong software engineering fundamentals (production code, multiple languages, integration), applied AI skills in the current wave (RAG, evaluations, agents, observability) and solid data skills, plus product and business judgment for discovery and scoping, plus strong communication and the temperament to handle ambiguity with a low ego. The rarity, and the reason for the pay, is holding technical depth, product sense and people skills in one person.
Why are AI companies hiring so many forward deployed engineers?
Because AI has created a large gap between what a model does in a demo and what it does against a real company’s data and workflows, and closing that gap needs someone on the ground. Enterprises cannot self-integrate the technology, executives need to see it working on their own problem to believe it, seven-figure deals make on-site engineers economical, and the learnings from hard deployments feed directly back into better products. That combination has driven FDE hiring up sharply across OpenAI, Anthropic, Palantir and many startups.
Is forward deployed engineering a good career, and what are the downsides?
For the right person, it is one of the best roles in tech right now: high ownership, visible impact, strong pay, and a well-known launchpad into founding or leading. The downsides are real too: significant travel, a genuine risk of burnout because you get the hardest accounts, sometimes ambiguous career paths, and a definition that varies from company to company. It suits people who want ownership and variety and can handle ambiguity, and it does not suit people who want predictable, bounded, heads-down work.
