This website uses cookies to help improve your user experience
Enterprise software delivery used to follow a more predictable chain of ownership.
A product team would build the platform. The sales team sold it. Solution architects designed the fit. Implementation teams helped customers go live.
That model still works in plenty of cases. But as more and more large companies want to integrate powerful AI products into their often-messy legacy software environments, the business outcome depends on more than deciding what software to install.
This is why the forward deployed engineer role came to fruition. We’re seeing an explosion of FDEs in AI companies, platform companies, enterprise SaaS teams, and data-heavy businesses because customers now need someone who can understand the problem, write the code to solve it, work with different types of infrastructure, guide deployment, and bring product feedback back to the engineering organization.
In essence, traditional strategy deck consultants who come in, tell the company what they need, and then leave aren’t cutting it anymore.
FDE Pulse currently listed 124 live forward deployed engineer openings with new ones each week1. Compensation for these jobs is at a $215K median with senior frontier-lab packages north of $785K, and principal-level roles at the highest end of the market clearing $1.2M2. The compensation is notable, but the bigger story is why companies are creating these positions in the first place.
But aside from high salaries, the main story is that more companies have discovered a painful organizational gap between product engineers, consultants, and solution architects.
We want to explore how the FDE role fills that gap. What problem does it solve? What do FDEs do? How do major companies interpret this relatively new role differently? And when does a company need FDE-like ownership instead of another standard software engineering hire?
Key takeaways:
A forward deployed engineer is a customer-facing engineer who works close to the customer’s real environment to build, integrate, adapt, and deploy software that creates a usable business outcome.
However, when you consider the lack of standardization of this new role, that’s still a pretty basic forward deployed engineer role definition.
Companies have FDEs for different reasons than they do with Backend Engineers, QA Engineers, or DevOps Engineers.
One company may use the title for engineers who ship full-stack AI applications inside customer environments. Another may use it for platform specialists who turn repeated customer problems into reusable product patterns.
The common thread is proximity to the customer’s actual work.
An FDE isn’t a software engineer writing code isolation from customers and customer context. They’re getting close to the customer, trying to understand their business problems, designing solutions, building them, deploying them, fixing them when something goes wrong, and using that knowledge to create repeatable solutions.
Essentially, the role sits at the intersection of software engineering, integration, and customer-facing problem-solving.
The name and model originate from Palantir. The company helped popularize the idea of engineers working directly with ultra-complex organizations to solve hard operational problems.
Marty Cagan at Silicon Valley Product Group3 describes it as: “Technical product creators who embed with target users to deeply understand their environment, problems, and required outcomes.”
In practice, the gap rarely appears because companies lack technical talent. It appears because ownership is fragmented. Product teams know the platform, customers know their business, and delivery teams understand implementation, but nobody is responsible for turning those perspectives into a production-ready solution. That’s the space FDEs are designed to fill.
“Customer-facing engineer” may sound like an oxymoron to anyone used to traditional software teams. But that’s partly why there’s such a need for FDEs.
FDEs usually enter the picture when a customer has moved past “Can this product do what we need?” and into “How do we make it work with our data, our permissions, our users, and our existing systems?”
What does a forward deployed engineer do?
Unlike traditional software engineering positions, FDE job descriptions often ask for engineers to own customer outcomes alongside technical implementation.
In practice, that work tends to fall into four buckets.
The customer may ask for a feature, an integration, or an AI workflow. The FDE’s job is to uncover the real problem behind the request before deciding what to build.
What process is broken? Who uses it? Where does the data come from? What would make the deployment worth doing? This is the diagnostic aspect.
Once there’s a clear problem, the FDE turns it into something practical. That may mean writing production code, connecting APIs, building internal tools, configuring model workflows, or adapting the platform to a specific environment.
Just because a system passes a technical test and gets a round of applause at a demo launch doesn’t mean it’ll hold up in daily use. FDEs stay close enough to handle edge cases or instances where a proposed workflow might create additional work.
With proper feedback, they can alter the deployment plan or the product itself.
FDE work has to become reusable at some point. If every deployment turns into a one-off build, the team ends up creating as much product debt as it solves. FDEs have to document what was built, clarify what a customer can maintain on their own, and look at which patterns should feed back into the core product.
Most public job descriptions focus heavily on technical skills. And yes, FDEs need to be strong engineers. But the most experienced FDEs spend just as much time mitigating ambiguity and aligning stakeholders. It can be just as important to decide what not to build.
Though the title may be the same for different companies, the operating model and the forward deployed engineer role responsibilities change with the product.
Palantir is the main historical reference point here because it used FDEs as part of a platform-first delivery model. At Palantir, they’re referred to as “Deltas”, and unlike the Devs of Palantir, who focus on building isolated custom software, Deltas help individual customers unlock many capabilities from the platform.
A Delta may:
When they’re done, they’ll bring what they learned back to product teams so they don’t have to reinvent the wheel each time they go out to solve other customer problems.
OpenAI describes its FDE team as working with customers to turn research breakthroughs into production systems, with ownership across discovery, technical scoping, system design, build, and rollout4.
The company’s goal for its FDE team is to create model-powered software that integrates into real business workflows (production adoption, measurable workflow impact, and eval-driven feedback).
OpenAI also describes FDEs as employees who:
In other words, the role is both a delivery engine and a product sensor.
From the Anthropic standpoint5, the role appears more focused on production Claude applications and advanced AI deployment patterns. Its FDE job description implies “working inside customer systems to build production applications with Claude models.”
So while the general mission might seem to be helping customers use Claude, it’s more aligned with building AI systems that can survive operational constraints that companies are dealing with.
The Salesforce FDE role6 is more closely tied to Agentforce and enterprise AI agent adoption.
Salesforce describes the role as “a two-way connection between customers and the product team”. FDEs help accelerate AI agent adoption, but they also bring back feedback on what works, what doesn’t, and which feature gaps are blocking customer scale.
The role includes:
From Salesforce’s perspective, an FDE is not only a technical helper but also someone who defines what “working” means for an emerging product category.
A customer may buy the platform but may still need help taking vague automation goals and turning those into agents that operate with the right data, guardrails, escalation paths, and performance metrics.
Although these companies describe the role differently, they face a similar engineering challenge. The title may be the same, but the center of gravity can change drastically.
An AI vendor will use FDEs to move models into governed production workflows. Enterprise SaaS companies use FDEs to accelerate the adoption of new product lines. Startups use FDEs to compress product discovery, implementation, and customer learning into one tight loop.
FDE work overlaps with solution architecture, consulting, sales engineering, product management, and senior software engineering, which is why it can be so confusing. The responsibilities overlap, but accountability doesn’t.
The more useful question is: who owns what? Let’s take a look at how an FDE differs from a solutions architect, consultant, and staff engineer.
| Role | Primary owner of | Hands off to | Not the owner of | Where the confusion often lies |
| Forward deployed engineer | Customer-specific technical outcome from discovery through deployment | Core product engineering after reusable patterns are identified | Long-term ownership of every custom workflow after handoff | May look like consulting work, but the difference is hands-on building and deployment |
| Solutions architect | Solution design, technical fit, architecture guidance | Delivery and implementation teams | Writing and maintaining the main deployment code | May need to have a deep understanding of the architecture without owning production delivery |
| Consultant | Diagnosis, recommendations, process design, and implementation guidance | Customer delivery teams | Building production-ready customer implementations | FDEs may consult, but their value depends on how well they can execute from a technical standpoint |
| Sales engineer | Technical proof during evaluation and buying | Customer-facing decision-makers and implementation teams | Post-sale production ownership | FDEs may support revenue, but the harder work starts when the system has to go live |
In a normalsoftware development life cycle model, discovery, design, development, testing, deployment, and maintenance are typically handled by separate teams. FDEs compress that cycle to answer a strategic customer problem, then feed the learning back into a more scalable product process.
A company usually needs FDE-like ownership when the product is strong enough to sell, but hard to implement.
Do teams need to hire someone with an exact FDE title? Not always. Some teams can split the work across product managers, senior engineers, solution architects, customer engineering, and delivery teams.
But if no one owns the full path from customer problem to working system, it can sometimes present issues. In a leadership role, there are a few signals to look out for:
These symptoms often appear gradually. Individually, they may seem like delivery issues or product gaps. Yet combined, they usually point to a broader ownership problem.
Oxagile helps companies design, build, and scale software products to work in real business environments. We partner with clients in AdTech, FinTech, AI, online video and streaming, and beyond.
If your team is dealing with integration pressure or product delivery constraints, our software product development experts can help define the path forward.
As a job that’s a little under two decades old, there’s still no universal definition for forward deployed engineer careers today.
That’s why companies use several adjacent titles:
While they might seem like different professions, they’re mostly different ways of weighing the same large-scale problem.
For instance, engineering-heavy variants focus on production code, integrations, APIs, internal tools, and data pipelines, while AI deployment variants focus on model behavior, evaluations, agents, governance, and reliability. A product discovery variant of the role might have a narrower focus on learning from strategic users.
The title typically changes depending on three main factors:
An early AI startup may need FDEs because it’s still learning how the product should evolve. A mature enterprise SaaS company, on the other hand, may need FDEs because a new AI product line is hard to deploy at scale.
Support teams typically react to product issues or operational incidents.
FDEs may help resolve issues, but they have a deeper core value, which is to help design, build, deploy, and adapt technical solutions inside customer environments.
FDEs do consult in the sense that they diagnose problems and guide decisions. But the role depends on implementation ownership, which isn’t something you see in a traditional consulting role.
However, if the job doesn’t include any technical builds, deployment work, or creating a product feedback loop, then yes, the role is probably closer to consulting.
Weak FDE programs can fall into that trap. Strong ones, however, identify which parts of a customer problem are account-specific and which parts can become reusable product capabilities.
That’s why it’s important to have architectural discipline. The goal isn’t to create more technical debt.
Sales engineers usually help before the deal closes by answering technical questions, running demos, and showing how the product could fit in the customer’s environment.
An FDE goes deeper. They show how the system can be integrated and put to real use.
Since forward deployed engineer careers are still taking shape, job postings can look a bit, well, broad.
Some ask for full-stack development, Python, cloud systems, LLM experience, enterprise integration, stakeholder management, and travel. Some others emphasize product judgment, ambiguity, customer discovery, and communication.
You won’t often see FDE job postings without a list of technical skills, even though half the job depends on field skills.
Technical expertise gets engineers into the role. Product judgment and customer communication are often what determine whether they succeed.
Software engineering fundamentals
FDEs need the engineering depth to build functional systems. It’s not enough to build a demo that collapses after handoff. Depending on the company, this may include:
Integration and deployment
Most of the work happens inside existing customer systems, which is why FDEs often need experience with cloud platforms, authentication, permissions, data pipelines, enterprise APIs, CI/CD, logging, observability, and system reliability.
For teams that need more support in these areas, it can sometimes help to have a development team extension model instead of building a dedicated FDE function from scratch.
Data and AI fluency
In AI-focused FDE roles, companies typically look for experience with Python, SQL, LLM APIs, retrieval patterns, evaluation frameworks, agent workflows, and a working understanding of how model behavior affects product experience.
That’s likely one of the main reasons for the overlap with AI consulting services.
Businesses are constantly asking, “Can we use AI?” But that question is too vague. The real question an FDE wants the answer to is “Why should we want to use AI?” or “Can an AI system work for our users or under our system constraints?”
As such, the answer to the issue may not be a chatbot at all but a better data layer or workflow tool. It’s an FDE’s job to investigate the deeper issues behind the request.
Customer discovery and problem framing
The first request an FDE gets from a customer isn’t always what they need to build. A customer might say, “We’re lacking in the support department. We need an AI chatbot.”
But upon further investigation, an FDE might realize the real issue is that support agents are wasting time searching through five internal systems for the same account information.
As such, the answer to the issue may not be a chatbot at all but a better data layer or workflow tool. It’s an FDE’s job to investigate the deeper issues behind the request.
Communication and stakeholder management
Traditional engineers aren’t customer-facing. They leave that to the sales team, which can sell the dream of AI implementation. An FDE lives between those two roles, talking to engineers, product teams, business users, executives, security teams, and customer stakeholders.
They need to explain technical trade-offs without jargon and have enough business acumen to know what makes the work they’re doing beneficial for the customer.
The job teaches a few skills that are hard to measure in interviews:
Then there’s product judgment, which may be the most valuable part of the role. If a product doesn’t work when put to use, the FDE needs to know where it didn’t work and why. They can eventually turn that experience into customer patterns and bring back evidence that helps the product team make better roadmap decisions.
There is no single path to take as a forward deployed engineer, but most often, the role evolves from supporting deployments to owning customer outcomes, then to building the operating model for others. As FDEs become more senior, the role shifts away from writing most of the code and toward making technical and product decisions that improve delivery.
Some companies build this capability internally, while others prefer to use a dedicated development team model to create long-running ownership.
If there’s one thing to take away from all this, it’s that the forward deployed engineer role is incredibly valuable in a market that’s in constant need for new platforms that work with their data, processes, systems, teams, and constraints.
This isn’t to say that every company needs to copy Palantir. But when there’s a need for someone to own the work between product capability and production outcome, an FDE can close the gap.
Oxagile helps companies build reliable and scalable software for complex products. If your team needs support with architecture, delivery, product engineering, or AI implementation, contact us to discuss the next step.
1. FDE Jobs: Forward Deployed Engineer Openings — FDE Pulse
2. The 2026 Forward Deployed Engineering Compensation Report — Perspective
3. Marty Cagan about Forward Deployed Engineers — svpg
4. Forward Deployed Engineer (FDE) – NYC — OpenAI
5. Anthropic’s Forward Deployed Engineer Job Description — General Catalyst
6. Forward Deployed Engineer – Agentforce for Supply Chain — Salesforce
No. The roles can overlap, but they usually show up at different points in the customer journey. A Sales Engineer helps answer technical questions before the customer buys. A Solutions Architect helps design how the product should fit into the customer’s environment.
An FDE usually takes it one step further by building, integrating, deploying, and adjusting the solution for real-world work environments.
The most important non-technical skills are:
The best FDEs can listen to a complex customer problem and figure out what to build to solve it, thinking about relevant outcomes.
Hire an FDE if customers can get a demo or small test working but struggle to turn it into something their teams can use every day. Hire another core software engineer if the team needs more help building the product or fixing reliability issues.
The main FDE responsibilities include discovery, problem framing, integration, production deployment, user feedback, stakeholder alignment, technical handoff, and product feedback. The exact work changes from company to company.
Yes. Some companies can get the same result without hiring someone for the FDE role.
Senior engineers, product managers, solution architects, customer engineers, and delivery teams can typically share the work. The important thing is that one person or team owns the whole path from problem to solution, so that the work isn’t left scattered across five different teams.
Many FDEs write production code, but it varies. Some roles are heavy on full-stack development and deployment, while others focus more on integration, prototypes, AI agents, internal tools, and data pipelines.
