What are Forward Deployed Engineers, and why are they so in demand?
Startups and scaleups are on a hiring spree for a software engineering role pioneered by Palantir. A deepdive into this role, and why FDEs are so popular in 2025
Programming note: we’re back from summer break for the newsletter. For the podcast, there will be no episodes in August: podcast episodes will be back in September. In the meantime, you can catch up with past podcast episodes.
One interesting trend in the AI startup segment this year is the rise to prominence of a specialized software engineering role called “Forward Deployed Engineer” (FDE.) It has even been dubbed “the hottest job in tech” by venture capital (VC) firm, a16z.
An FDE does a mix of software, sales, and platform engineering, and the role has seen a major recruitment uptick since around the start of the year, fuelled by the need for integrating AI solutions. But it’s not just AI startups hiring for this position.
Today, we look into FDEs, covering:
What’s a Forward Deployed Engineer (FDE)? A software engineer who alternates between being embedded with customer teams and core product engineering teams. It can be a tricky job!
Origins. Until 2016, Palantir had more FDEs (which it called “Deltas”) than software engineers. No other company has shaped this role more than the secretive tech company.
The role at OpenAI. Established at the ChatGTP maker earlier this year, where it is differentiated from the professional services-type job of Solution Architect.
FDEs At Ramp. Put in place 9 months ago, Ramp has around 15 FDEs in pods who work according to four core operating principles.
Why so hot now? Integrating LLMs and AI-based products is a perfect use case for the role, while Palantir’s business success is linked to FDEs.
FDEs vs Solutions Engineers (SE) and Agent Engineers (AE). There are similarities, but FDEs are usually expected to contribute more to the core product.
FDE careers. How to hire FDEs, compensation, and potential career progression.
Thank you to Colin Jarvis (Head of FDE at OpenAI), Leo Mehr (heading up FDE at Ramp) and Anjor Kanekar (formerly an FDE for 7 years at Palantir) for their input. Anjor is currently open for advisory roles in structuring or hiring for FDEs – contact him for details.
1. What’s a Forward Deployed Engineer?
Job adverts for FDEs describe a few main characteristics:
Software engineering basics. Almost every recruiter seeks a solid software engineering background, and some real-world experience to show that the fundamentals are in place. Ramp prefers 5+ years of experience for Senior FDE roles, but does hire some exceptional new grads as FDEs. Palantir hires people with as little as a year of post-college work experience, while healthcare startup Commure, and industrial AI startup Matta, each value real-world experience of building and shipping projects from start to finish.
Collaborate with Sales to close customers. Many startups employing FDEs use them to help win customers. Basically, when a customer is undecided on whether they can effectively use a product, Sales offers to provide an FDE to help them successfully integrate it. Here’s how Ramp puts it in a job ad:
“Collaborate closely with our sales and go-to-market teams to close exciting deals, activate customers, and expand the value Ramp provides over time”.
Embed into customers’ teams. As an OpenAI advert says, “As an FDE, you’ll embed with customers, understand their domain, and co-develop solutions to tackle real problems in often undefined or evolving problem spaces”.
It’s pretty standard that the job involves travelling to customers to sit alongside them a few times. Palantir expects around 25% of FDEs’ time to be spent onsite with customers, and healthcare AI company Commure estimates up to 50%.
For businesses that work with unusual customers, this can involve working in harder-to-access work environments. For example, industrial AI startup Matta expects FDEs to “scope out solutions on the factory floor”. When at Palantir, former FDE Anjor Kanekar says he was on the final assembly line at aerospace manufacturer Airbus, and that many of his peer FDEs worked in similarly unconventional environments, including airgapped ones. Not typical workplaces!
Contribute to the core product, and embed with core product engineering teams. As Ramp describes, FDEs are expected to:
“Drive their core product engineering roadmap and make important prioritization and scoping decisions that determine when we build custom solutions vs. accelerate larger existing projects. Ramp’s team uses an embedding model where FDEs embed within core product engineering teams to develop expertise in the most relevant technical areas”.
Help customers succeed. The core of the role is to make customers successful by building on top of a company’s product offering. As robotics startup Gecko Robotics phrases it: “[FDEs] search for the highest-impact problems we can find, we spend a lot of time with customers to understand their true nature, we come up with new [approaches], and we don’t quit until we’ve reached impact”.
Some places treat the role as more of a technical consultant. AI agent management platform Lindy expects FDEs to help customers build and maintain their no-code workflows, “while serving as their technical consultant”. It’s evident the line between being a consultant and an engineer who works both with the customer and on the product, can be blurred.
Every company has their own flavor of FDE. This role is quite new, meaning workplaces define their own expectations of it. Some put more emphasis on FDEs closing sales pipelines, others on assisting customers, and some focus on contributing to the core product.
It looks as if the role comes loaded up with expectations; for example, here is what a Senior FDE is expected to do at Salesforce:
Drive tangible outcomes through hands-on implementation
Build transformative AI solutions
Engineer bespoke agentic AI solutions
Own the entire data configuration & integration lifecycle
Proactively remove technical blockers
Drive Agentforce innovation
Become a trusted strategic partner
Conduct deep-dive technical debugging and root cause analysis
Lead rapid prototyping and iteration
Implement and enforce best practices
That’s quite the list, and looks similar to implicit expectations upon an experienced software engineer – usually at the Senior+ levels. I personally like Palantir’s definition which encapsulates all this:
“FDEs responsibilities look similar to those of a startup CTO: you’ll work in small teams and own end-to-end execution of high-stakes projects.”
Roles that are highly similar to an FDE can be called different things. “Agent engineer”, “Solutions Architect”, “Sales Engineer”, and “Technical Delivery Engineer” all come pretty close to what Forward Deployed Engineers do. The difference comes down to that FDEs work with customers and also contribute to the product their company sells.
Here’s my own mental model of what an FDE typically is – with the caveat that the “platform engineer” part might be less emphasized at places where FDEs do not contribute to the product:
2. Origins
The “Forward Deployed Software Engineer” role was created at data mining giant Palantir in the early 2010s, and was named “Delta.” Palantir was founded in 2003 and provides services to government agencies like law enforcement and the military, and to private companies. The data it works with is often sensitive and proprietary.
Up until circa 2016, Palantir had more FDEs than it had “normal” software engineers. That year, a product called Palantir Foundry was launched: an integrated data platform built for commercial and civil government sectors. From then on, more FDEs went back to working as software engineers, working on Foundry and bringing their experience from the field to that core product.
Even today, no company employs more FDEs than Palantir, and no startup or scaleup comes close to influencing the role as much. Here’s how Palantir explains it in more detail:
“Deltas (Forward Deployed Software Engineers) deploy our software platforms to customers. Deltas are part of Business Development, and their mandate is to achieve technical outcomes for our customers.
As part of a team that directly supports one customer, a Delta focuses on technology-driven value creation: deploying and customizing Palantir platforms to tackle critical business problems. They measure success in terms of impact on the customer’s goal. For example, we work with manufacturers who want to reduce the number of defective products coming off the assembly line. To move the needle on that metric, a Delta uses Palantir products, a variety of languages, open-source tooling, and industry-standard build tooling, and their own creativity to devise a solution.
You can think of a Dev’s focus as “one capability, many customers,” while a Delta’s focus is “one customer, many capabilities”.
FDEs are sometimes mistakenly thought of as consultants, but the difference between consultants and FDEs is that the former make one-off recommendations, whereas FDEs generally work with customers, long-term.
As mentioned, FDEs also contribute to core products. When there’s a capability missing that a customer needs, the FDE can do the “dev” work of adding features and improvements to Palantir’s product.
Day-to-day as an FDE at Palantir
Two FDEs at Palantir shared what a typical day looked like, back in 2019:
“Dyon (Abu Dhabi): “Most weeks, I spend a couple of days working at the customer premises, some of that time in meetings with technical or business stakeholders, and the rest of the time monitoring, debugging, deploying, or configuring our software for that customer.
Back in the office, I spend some time writing minor code changes, reviewing pull requests, and researching/planning customer solutions.
The remainder of my time is spent communicating via email or VTC with our internal support and product development teams, and with my direct reports who are based in a number of remote offices.
G.M. (São Paulo): “My ‘day-to-day’ changes month-to-month, which is a cool feature of my role! Some weeks, I spend most of my time developing and reviewing my team’s code, like a typical software engineer. Other weeks, I spend most of my time scoping the future of a project with a client, or working with users to make sure the things we’ve built meet their needs.”
In general, a typical week for FDEs at Palantir is a mix of:
Project work for a customer: the primary focus
Improving Palantir’s platform/systems: when Palantir’s platform gets in the way of building functionality, FDEs do things like configure new data models, contribute stability improvements, or commit fixes to the platform
Keep up with internal tasks: internal comms, emails, meetings, standups, meeting coworkers, shared projects, etc.
The above may seem to describe two separate jobs (working similar to a consultant / working as a platform engineer) rolled into one! This is the tricky nature of the role: the ability to say “no” is part of doing well in this position, according to an FDE at Palantir said:
“I generally try to limit the amount of time I spend in meetings by asking myself “does this discussion have to be a meeting, and do I have to be there?” Most people at the company take a similar approach, and it leads to a situation where every meeting I attend ends up being a productive use of my time.”
Why does Palantir employ so many FDEs?
Palantir works a lot with government agencies and companies that I’d consider “traditional”. I suspect that without a role like FDE, these more traditional businesses would struggle to integrate Palantir’s system into theirs.
In contrast, startups are nimble, employ devs who are usually open to experimentation and don’t mind “hacking" solutions together. But large enterprises are often the opposite; where getting things done is less about technology challenges than bureaucracy, and a “not my job” mindset gets in the way of projects.
By sending in empowered engineers whose mission is to integrate Palantir’s software in a way that delivers customer value, Planatir “kills two birds with one stone”: they don’t need to worry too much about internal bureaucracy because they are blissfully unaware of it, and they send a “startup-minded” dev for the integration with the mindset of “how can I get this to work”, not “what are reasons this won’t work.” Companies contracting with Palantir see faster progress in software integration than by doing it themselves.
3. The FDE role at OpenAI
Colin Jarvis is Head of Forward Deployed Engineering at OpenAI. He initially joined in 2022 as a Solutions Architect, and became the Head of Solutions Architecture, last year. At the beginning of this year, Colin presented a business case for setting up a Forward Deployed Engineering Team, to have a more targeted offering. The group started with two FDEs, and today there are more than 10 at the company in:
US: New York and San Francisco
Europe: Dublin, London, Munich, Paris
Asia: Tokyo and Singapore
OpenAI still has a “Solutions Architect” (SA) role. Both SAs and FDEs help with the challenge of LLMs being complicated for customers to work with.
FDEs are more hands-on and typically work with more ambiguity than SAs traditionally do. SAs are more like advisory roles: they rarely write code on customers’ infrastructure, and usually build minimum viable products (MVPs), or proofs of concept (PoC) with anonymized or offline cuts of data.
FDEs are much more hands-on: they write code directly on customer infrastructure and use customer tooling for this. FDEs also align with OpenAI’s research objectives, and work with customers who can most likely build solutions that help advance the research direction at OpenAI. FDEs need to work with more ambiguity than traditional cloud solution architects.
FDEs help advance the product roadmap. In one case, OpenAI worked with a voice customer on call center automation, and FDEs created evals on the voice model. Initially, the model wasn’t performing well enough for the customer to commit to deploying it.
So, the FDE team went back to OpenAI’s research department with data and worked on improving the model’s performance for voice use cases, leading the customer to be the first to deploy the advanced solution in production.
OpenAI’s Realtime API was also improved by this work. In the end, it was a win-win: the customer got a more advanced capability faster thanks to FDEs, and OpenAI got to test improvement with a real-world case, and improve the product for all customers.
Work structure at OpenAI
Colin explained how their FDE team thinks about the parallel dimensions of their job:
Customer-facing-FDE work structure
Customer projects have three phases:
Early scoping (phase #1) A couple of days onsite with the customer
Sit with users, map out their processes
Identify the biggest value areas
Prototype with synthetic data
Whiteboard ideas and prioritize them
Validation (phase #2). FDEs land on the customer’s site and answer this question: “Is what we scoped out, the most valuable thing we can do for the customer?” If so, they agree on validation criteria. Building this validation criteria then usually includes:
Building evals (quality checks for LLM applications) with user input and labeling
Scaling the labeling process
Building features and hill-climb on evals (optimizing the model to perform better on previously-defined quality checks)
Presenting a final report showing eval performance compared to the objectives
Doing validation before delivery is unusual, but happens for good reason, says Colin:
“FDEs work in a ton of ambiguity, and often what the customer describes in scoping doesn't match the data/system reality on the ground. We want to bias for moving fast, proving out any brick walls and then adjusting the scope to the most useful thing we can do, given any insurmountable constraints.”
Delivery (phase #3). Onsite at the customer’s site, typically for a few days per week
Understand exact details of problems
Get data from the customer
Build solutions – typically at OpenAI offices – then demo to customers
Focus on the “smallest unit possible” that results in an end-to-end solution (or demo)
As an interesting example, in Iowa in the US, an FDE worked on a project with John Deere – a 200-year-old agriculture infrastructure business. They helped solve the problem of scaling “personalized farmer interventions”. Previously, the customer made phone calls manually to farmers, giving them tips and suggestions on how to make best use of their farming equipment.
But the customer wanted farmers to get personalized insights to maximize utilization of their latest weed control technology which reduced the amount of pesticide sprayed on crops, saving significant sums.
As part of the project, both Colin and an FDE travelled to Iowa, and worked directly with farmers.
The timing of the project was tight: John Deere wanted the new feature to be ready for the next growing season, when crop planting is done and effective spraying is critical. The team was able to pull off the integration within this tight time frame, and the project was considered a success.
Internal-facing-FDE work structure
While the main focus of FDEs is working on customer projects, they also share knowledge with OpenAI and work with internal teams:
Regular knowledge-sharing sessions with the Research team, usually bi-weekly
Fortnightly readouts with OpenAI’s Head of Product and Product Managers
“FDE Field notes” Slack channel, where any and all FDEs share insights in an internally public channel
Quarterly bootcamps that bring the whole FDE team together. This is important because members are currently in 8 cities across 3 continents
The FDE team is a big contributor to OpenAI’s Agents SDK. OpenAI’s Solutions Architecture team created the Swarm framework which they built to help customers integrate with OpenAI APIs easier and faster. They did this after realizing that the existing agent SDKs had a high learning curve, and wanted to offer something simpler when handing off networks of agents to a customer.
These days, the Swarm framework has been replaced by the OpenAI Agents SDK, and the Solutions Architecture and FDE teams contribute to it.
4. Forward Deployed Engineers at Ramp
Leo Mehr heads up Forward Deployed Engineering at Fintech scaleup, Ramp. Here’s how he recalls this function being created: