Part Three · Action
Chapter 8
Not a New Name, but Old Roles Converging on the Front Line
What is an FDE? This chapter compares the Forward Deployed Engineer with sales engineers, architects, implementation consultants, product managers, and customer success, explaining why old roles must converge on the front line.
After the FDE became popular, the most common debate wasn't about what it should do, but what it used to be called.
Some say, isn't this just an implementation consultant?
Some say, it's clearly a Solutions Architect.
Others think it's just a pre-sales engineer who can write code, or a full-stack engineer willing to be stationed on-site.
Each of these descriptions captures a part of it, yet none is complete.
The FDE didn't invent a new set of skills out of thin air. It's more like pulling several previously scattered roles in enterprise software to the same table, and then telling them: this time, don't rush to hand off—stay until the results come out.
Every old role guards a stretch of the road
Pre-sales meets the customer first.
They need to understand roughly what problems the customer has, explain the product's capabilities clearly, and help sales judge whether an opportunity is worth pursuing. But once the contract is signed, the project is usually handed off to the implementation or delivery team.
The Solutions Architect is responsible for assembling the system.
They consider interfaces, data flows, permissions, performance, and deployment, ensuring the solution is technically sound. But how much the business actually adopts is often not their primary metric.
Implementation consultants know the customer's site best.
They configure systems, sort out processes, train users, and handle go-live issues. A good implementation consultant already looks a lot like today's FDE. The difference is that the boundaries of many implementation projects are still defined by feature checklists and acceptance milestones.
Product managers are responsible for commonality.
They must decide what goes into the product trunk and what is merely an individual customer's need. Too far from customers, and you build features nobody uses; too close to a single customer, and the roadmap turns into a customization list.
Data engineers and software engineers turn the solution into a working system.
They are accountable for code, data, and production stability, but don't necessarily get to participate in the earliest problem definition. By the time requirements reach them, the direction may already be set.
Customer success takes the final stretch.
After go-live, who is using the product, why they've stopped, whether the customer will renew—these become their concern. But by this point, many product problems are already hard to redo.
This division of labor isn't outdated. Large companies must divide labor; it's impossible for everyone to do everything from sales to operations.
The problem lies in the handoffs.
Every time a problem passes through a handoff, it loses a bit of context. What started as "reduce order disputes" becomes "build an exception dashboard" in the solution, becomes a few interfaces and pages in the hands of engineering, and customer success finally discovers that users are still handling things offline.
Every runner completes their leg as required, but the baton is no longer the original one.
The FDE temporarily connects the stretches of road
OpenAI's public job description for the FDE is very specific: responsible from problem discovery, technical scoping, and system design through building all the way to production launch; success is measured by production adoption, measurable workflow impact, and eval feedback that can in turn change the product and model roadmap.
In this description, what matters most isn't which frameworks one knows, but that several normally separate actions are connected.
The person who discovers the problem participates in building; the person who builds follows through to production; and production feedback flows back to product and research.
That is the basic shape of the FDE.
It doesn't require one person to permanently cover all roles. Complex projects still need business experts, security teams, product, research, and the customer's own engineers. The FDE's role is to ensure that no segment of this chain becomes "that's not my responsibility."
Sometimes it's one strong engineer carrying it; sometimes it's a small team of two or three. The point isn't heroics, but that someone must continuously hold the context across the entire chain.
"The front line" doesn't mean sitting in the customer's office
Being on-site doesn't equal being on the front line.
An engineer who sits in the customer's meeting room every day writing code from requirement tickets may still be far from the problem. Another person who remotely examines real workflows, debugs alongside operators, and is accountable for launch outcomes is actually closer to the front line.
The front line means being close to three things:
- Close to real work, able to see the exceptions that fall outside the documentation;
- Close to production systems, knowing what happens when code breaks;
- Close to outcomes, able to judge whether the delivery actually changed the business.
Miss one, and the role becomes distorted.
Close to the work but not touching production, you easily stall at consulting; touching production but not understanding outcomes, you easily become outsourced development; talking only about outcomes without engineering capability, you revert to pre-sales promises.
The difficulty of the FDE is precisely that none of the three can be fully pushed to someone else.
China has long had people doing isomorphic work
Before the name FDE became popular, there were always cross-boundary people on the ground in Chinese enterprise software.
Some implementation consultants could write scripts directly; some systems analysts sorted through processes together with the business; some data leads both did architecture and explained ROI to the boss. When a project had problems, the person the customer sought out first was often not the highest-ranking one, but the one who understood how the system, the business, and the historical reasons connected.
They may not have held the FDE title, and may not have had today's large model capabilities. But the shape of the work was already very close: blurred problem boundaries, the necessity of entering the field, technology and business inseparable.
Acknowledging this history doesn't mean the FDE is just an old role with a new name.
The prototyping speed, probabilistic risks, tool calling, and continuous evals that AI brings mean field roles must master new engineering methods. In the past, a consultant who understood the business but couldn't write production code could hand requirements off to engineering; today, if prototypes change daily and model behavior must be tested on-site, the cost of handoffs becomes very high.
The old roles provide the skeleton; AI changes the tempo and the density of responsibility.
Not every customer project needs an FDE
The FDE is also easily misused.
For projects where the standard product is mature, customer requirements are clear, and configuration and training will suffice, there's no need to dispatch an expensive cross-functional team. Forcing the FDE model may just add cost.
Scenarios better suited to the FDE usually share several characteristics:
- The problem is important, but the customer can't yet articulate it clearly;
- Data, processes, and permissions span multiple systems;
- Model capabilities need to be validated while building;
- The cost of failure is high, so you can't just deliver a prototype and leave;
- Discoveries in the field have the opportunity to be distilled into product capabilities.
The last item here is crucial.
If every customer's problem is only useful to that customer, no matter how strong the FDE team is, it will be dragged down by endless customization. The front line must both serve the current customer and seek reusable patterns for the product.
This is a dual responsibility, and it naturally creates conflict.
The customer wants you to focus only on them; the product team wants you to bring back commonality. The FDE must make judgments: what is this customer's context, and what is a problem that recurs across the entire industry.
Judge well, and the field becomes the product's eyes; judge poorly, and the product becomes the project's warehouse.
What's new isn't the skill list—it's that responsibility can no longer be easily carved up
Debating which old role the FDE belongs to ultimately doesn't matter much.
Companies don't get results because a job title is more accurate. What they care about is: when a problem moves from the meeting room to the production environment, is there someone who always knows why it's being done, what success looks like, and what to do when things go wrong.
The FDE's value lies in this continuity.
It picks up what used to fall through the cracks between handoffs: how the customer actually works, the constraints of technical implementation, post-launch adoption, and field feedback on the product.
And precisely because responsibility has been extended, evaluating an FDE can't be based only on code, launch speed, or customer satisfaction.
The next chapter asks: if "launch" no longer means done, what should this new delivery contract actually take as its endpoint?
Chapter references
- OpenAI: Forward Deployed Engineer job description
- Palantir: A Day in the Life of a Forward Deployed Software Engineer
- Anthropic: Careers
Note on scenarios: The role handoff examples in this chapter are used to illustrate responsibility boundaries and do not correspond to any single company's fixed organizational structure.
This page is synced with the chapter Markdown on GitHub. Corrections are welcome.