The job ad says FDE. Is the real work writing code or keeping customers?

An analysis of about 1,000 Forward Deployed Engineer job postings found that working directly with customers is the most frequently cited responsibility, appearing in 55% of them. Yet not one posting treats revenue responsibility as a core duty.

At first glance the two numbers look contradictory. The person who meets customers most is not responsible for keeping the contract. Customer success roles, by contrast, are usually tied to whether customers renew. That difference explains why FDE and Customer Success Engineer (CSE) are two distinct jobs, even though both sit close to the customer.

Confusing the two is more than a naming error. It decides what you do every day and which numbers you are judged by.

The Pragmatic Engineer noted in May 2026 that demand for FDEs is very strong at Google, OpenAI and Anthropic. Strong demand is good news, but it is also a reason to read each posting carefully before applying: the job title alone does not tell you what the daily work will be.

Both sit close to the customer, but they arrive at different times

The simplest way to tell them apart is to look at the stage at which each role starts working. FDE Academy writes that FDEs help build the first technical deployment. CSEs help customers keep using the product effectively, and usually do not take on large deployments or custom integrations.

Paraform sums it up as a chain of handoffs: the Solutions Engineer persuades the customer of what the product will do, the FDE turns that into a working system, and the Customer Engineer sustains it once the deployment is stable.

Companies label the post-go-live stage differently (FDE Academy uses Customer Success Engineer, Paraform uses Customer Engineer), so CSE is used here as shorthand for that group of roles.

Palantir’s job description shows why the FDE has to sit at the building stage. The company wants people who work directly with customers on their most pressing problems, to produce custom applications, LLM-powered workflows and production solutions fitted to each customer’s particular circumstances.

This is writing new software, not supporting a packaged product.

The symptom tells you what the role is

Paraform offers a memorable diagnostic. If the contract is signed but deployment has stalled, that is FDE work. If customers leave after the product is running, that is a post-sale technical support problem, in other words retention.

Imagine a startup selling inventory forecasting software that signs 10 contracts in a quarter. Scenario one: 6 customers still have not gone live because their data sits in a legacy ERP the product cannot yet connect to.

There is nothing to retain here, because the customers have not yet received any benefit. The company needs someone to go on site, write connectors and normalise the data: an FDE.

Scenario two: all 10 customers go live, but after three months several leave because their bug reports were not handled in time. Writing more custom code will not fix this. The company needs someone to monitor account health, resolve incidents and help customers use the product more deeply.

A company’s stage of growth leads to the same conclusion. According to Paraform, seed-stage startups whose users onboard themselves should hire for retention first, because users will leave when they hit problems and no one is there to give technical help.

FDEs only start to make sense at Series A, when deployments become complex and need close work with each customer. For job seekers this is a signal worth noticing: a seed-stage startup selling a self-onboarding product that is hiring an “FDE” very likely has a job that leans towards retention.

Don’t turn an FDE into an account manager

Precisely because FDEs sit close to customers, many customer success teams want to use them as CSMs (Customer Success Managers). Chad Horenfeldt, who writes about customer success, calls this a trap. In his view, getting pulled into solution details eats the time a CSM needs to understand what outcomes the customer actually wants.

He also says bluntly that he sees FDEs as closer to services, even support, than to a strategic, revenue-linked customer success function. FDEs may not like that classification. But it matches the hiring data: no FDE posting assigns revenue responsibility.

A blog from Jestor, a software company, looks at the same question from the other side. Traditional customer success is concerned with adoption and retention.

With an FDE-style approach, success is measured by operational results, not NPS or feature usage. Horenfeldt and Jestor judge FDEs from different angles, but both point to the same thing: the two roles are measured by different kinds of metric.

Diagnostic question	FDE	CSE / Customer Engineer (after go-live)
When they come in	When the first technical deployment is being built	After the customer is using the product, to keep them using it effectively
Symptom that calls for them	Contract signed but deployment stalled	Customers leave after go-live
Main output	Custom applications, integrations and workflows for one customer	Technical support, rarely large custom integrations
Measure of success	The customer’s operational results	Adoption, NPS, renewals
Relationship to revenue	No posting assigns revenue responsibility	Usually tied to contract renewal
Suitable company stage	Series A, complex deployments, close work with each customer	Seed, self-onboarding users

The metric decides who you become

For your career, the metrics row in the table above says more than the job title. You get better at whatever you are measured on. Three years judged on NPS and renewal rates will give you account management skills.

Three years judged on whether the customer’s system runs in production will give you the skills of someone who builds software.

So when reading a JD, don’t stop at the title. Look for the verbs and the metrics. If the posting talks about build, deploy, integrate, production and operational results, it is FDE work.

If it talks about adoption, health score, renewal and expansion, it is customer success, even if the title says Forward Deployed. Neither role is lesser, but you should know which one you are choosing.

In the interview, ask a question based on Paraform’s diagnostic: are most of the team’s customers struggling before go-live or after? The answer tells you whether you will spend most of your time writing connectors or handling tickets.

Your CV should follow the same metric. A line such as “supported 30 enterprise customers” fits a customer success profile. An FDE profile needs lines like: where the customer was stuck, what you built, and how operational results changed once the system ran in production.

If you have no external customers yet, an internal project you took from stuck to running in production demonstrates exactly the same skill.

To find out what a role really is, don’t ask for its title. Ask what number the company uses to measure success in it.