The adjacent roles all stop before production. That is the difference.

Solutions engineer, professional services, technical account manager and product engineer all touch the same deal, and people use the titles interchangeably. Sorting them by where their ownership ends explains the FDE role better than any list of skills.

12 MIN

TL;DR: Every adjacent role hands off before the software is in daily use. The FDE is defined by owning past that point, writing production code the whole way, and carrying what they learn back into the platform.

Where you are. You know why the last mile exists. Now sort out which role owns which part of it, because the titles are used loosely and the distinction decides what you will be measured on.

Sort by where ownership ends

Skill lists are a bad way to tell these roles apart, because the skills overlap almost entirely. All of them talk to customers. Most of them can code. Sorting by where each one stops separates them cleanly.

Solutions engineer, or sales engineer. Pre-sales. Their output is a technical win: the demo that proves the thing is possible and the objection handled in the room. The work is real engineering, but it is scoped to the deal, and when the contract is signed they move to the next one. Their code is usually disposable by design, and their demo environment, buffed smooth by a hundred demos, resembles no production system on earth. What worked beautifully in it becomes your problem in week one.

Professional services, or delivery consulting. Post-sales, bounded by a statement of work. They build what the contract says, and the contract was written before anyone understood the problem. That boundary is the defining feature: discovering that the real problem is different is a change order, not a Tuesday.

Technical account manager. Owns the ongoing health of the relationship after go-live. They answer questions, escalate issues, and track renewal risk. The one thing they do not do is build, which is why a deployment in trouble gets a TAM's sympathy and an FDE's commit.

Product engineer. Owns the platform for every customer at once. Their correctness bar is generality, which is exactly the wrong instinct in a single customer's environment, and their feedback arrives through a product manager rather than by watching someone struggle.

Forward deployed engineer. Starts around the pilot, sometimes earlier for technical discovery, and does not stop until the thing is in daily use. Writes production code the whole way. Then does the part that makes the model pay for itself: carries what they learned back into the platform so the next customer is cheaper to serve.

The naming has lore of its own. Palantir, which invented the role, split engineering into Devs, who build the platform, and Deltas, who deploy it into customer environments, the latter a holdover from the early days when teams were named after NATO alphabet letters. Most companies hiring FDEs today, whatever they call the tracks, are running a recognisable copy of that two-track design.

The two things only the FDE does

Strip out everything shared and two responsibilities remain.

Owning the outcome past the handoff. Every other role has a defensible stopping point: the deal closed, the statement of work completed, the ticket resolved. The FDE's stopping point is somebody using the software to do their job. That is not a more demanding version of the same role. It changes which decisions you are allowed to make, because you will personally live with all of them.

Feeding the platform. An FDE who only ships bespoke work is an expensive contractor. The value comes from noticing that three customers needed the same adapter and turning it into something the product ships. Companies that get this right compound; companies that get it wrong build a consultancy inside a software business and wonder why margins fall.

Why interviews test the boundary

Interviewers ask some version of "why this role and not a normal engineering job" because the wrong answer predicts a bad hire. Someone who wants to be left alone with a hard system will resent the meetings, of which there are many. Someone who likes customers but does not want to own production will stall in the last mile exactly like the pilot did, except now the company is paying a salary for it.

Ask about the travel model early, because the range is now enormous and it changes your life more than the compensation does. In the original Palantir version, forward deployed engineers were onsite at the customer three or four days a week. At the other extreme, PostHog runs its FDE function fully remote and asynchronous. Most AI companies sit between, with travel bunched around kickoffs and go-lives, and the job posting almost never says which one you are getting.

One more piece of hiring lore worth having: Ramp's forward deployed team screens for candidates with teaching experience, on the theory that explaining complex things clearly to people who are not obliged to listen is most of the job. If you have been an instructor or a teaching assistant and enjoyed it, say so. It is a stronger signal in this loop than in any other engineering interview you will sit.

The answer that lands names the trade you are making: less control over what you build, far more control over whether it matters. If that trade sounds bad to you, this is genuinely the wrong role, and finding that out now is worth more than passing the interview.

The trade has a documented upside. Qureshi observes that a typical Y Combinator batch contains more ex-Palantir founders than ex-Google founders, despite Google employing roughly fifty times as many people. His explanation is the job itself: an FDE spends years reading rooms, winning negotiations and learning unfamiliar businesses at speed, which happens to be most of a founder's job description.

Do this before moving on

Take the job posting you sorted in the previous lesson. For each responsibility in your "only this role" bucket, write which of the two defining responsibilities it belongs to: owning past the handoff, or feeding the platform. Anything that fits neither is probably a shared responsibility you mis-sorted, and that is the useful part of the exercise.

Go deeper

FDE vs other engineering roles sets the same comparison against pay and career path, which this lesson leaves out.
Explaining trade-offs is the skill that makes owning past the handoff survivable in a room full of stakeholders.
Stakeholder management covers the people who can stop your deployment even when the code is finished.
Travel and living at customer sites is the practical question behind whether this trade suits your life.
OpenAI interview prep shows an AI-native version of the loop, where the boundary is drawn slightly differently.

Key takeaways

Sort the adjacent roles by where ownership ends, not by skills, because the skills overlap almost completely.
Solutions engineering stops at the deal, professional services stops at the statement of work, and account management never builds.
Only the FDE owns past the handoff into daily use, and only the FDE feeds field learning back into the platform.
An FDE who never generalises their work is a contractor with a software company's badge.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1A team discovers mid-pilot that the customer's real problem is different from the one in the contract. Which role treats that as a change order rather than as the work?
2Name the two responsibilities that remain when you remove everything the FDE shares with adjacent roles.
3Why is an FDE who only ever ships bespoke customer code a problem for the business?