Becoming an FDE: The Transition From PM, Engineer, or SE

Three doors lead into forward deployed engineering. A product manager walks in with the customer and the outcome but not the production build. An engineer walks in with the build and the discipline but not the customer. A sales engineer walks in with the customer and the technical range but has never been on the hook after the signature.

Each door arrives with two of the three things the job needs. The transition is the third thing, and it is different for each path. What is the same for all three is that the third thing cannot be learned in a classroom, because it is a change in what you are accountable for, not a change in what you know.

The short version

The FDE role needs three things: production engineering, customer proximity, and accountability for the outcome. PMs have the second and third and need to close the engineering gap, which a coding agent has made a quarter's work rather than a career's. Engineers have the first and often the discipline behind the third, and need to move their desk to the customer's building. Sales engineers have the first two and need to stay past the signature, which sounds trivial and is the hardest of the three because everything in their compensation and calendar pulls the other way. In every case the 90-day plan is one real deployment, owned end to end, measured on the customer's result, with someone senior shadowing the first one. The role is senior by nature. Only 3 percent of open FDE roles in mid-2026 were early-career.

Door one: from product management

If you have been reading this handbook, you have already done most of the work. The Product Builder ships prototypes, sits with customers, and writes the eval before the code. What a PM usually lacks for forward deployment is the last mile of production engineering: authentication against the customer's identity provider, the batch job that runs at 2 a.m., the retry logic when the customer's API times out under real load.

Two years ago that gap was the whole distance. It is not anymore. A coding agent writes the retry logic. What it cannot do is know that the customer's API times out because their nightly ETL locks the table, and that the fix is a schedule change nobody will approve without a conversation with the data team's lead. That knowledge is customer proximity, and you have it.

The 90 days: take one deployment that is already sold. Weeks one to four, pair with an engineer and build the integration yourself, with them reviewing and you typing. Weeks five to eight, own a second integration alone, with the engineer available but not driving. Weeks nine to twelve, run the go-live and the first month after, and be measured on the customer's outcome, not on the integration shipping. If at the end of that you can defend the production system to the customer's engineers without a translator, you are through the door.

The trap: treating the deployment as discovery. PMs are trained to extract requirements and hand them off. An FDE extracts requirements and then builds the thing, and the handoff you are used to does not exist. If you catch yourself writing a document for someone else to implement, you are still a PM.

Door two: from software engineering

Engineers have the build. Most good ones also have the production discipline, the instinct for observability and rollback that this handbook's ship with observability chapter tries to teach PMs. What they usually lack is the customer, in the specific sense Nabeel Qureshi describes from Palantir: sitting in the customer's building three or four days a week until you have the tacit knowledge of how they work, not the flattened list of requirements.

The 90 days: pick one customer and move in. Not a kickoff and a weekly call. Three days a week on site, or the remote equivalent of it, which is being in their Slack and their standup rather than in yours. Weeks one to four, learn the vocabulary and the org chart, including the informal one, and build nothing you were not asked for. Weeks five to eight, ship the first thing, small, in their production, and watch what happens when real users touch it. Weeks nine to twelve, own the outcome metric and report on it to the customer, not to your manager.

The trap: overbuilding. Qureshi's line about the FDE job was solve the problem and do not worry about overfitting. Engineers want to generalize. That is the product team's job, and the deployment-to-product loop covers how what you build gets generalized by someone else. Your job is the customer's outcome this quarter. If you find yourself building a framework, stop.

Door three: from sales engineering

The SE transition looks shortest and is hardest. SEs have the technical range and the customer fluency. Meurer's joke that FDE job postings ask for eight years as a staff engineer plus six years of direct sales is a description of a senior SE. What SEs have never done is stay.

Everything about the SE role ends at the signature. The comp plan pays on bookings. The calendar refills with the next prospect the day a deal closes. The demo environment is clean by design, because a clean environment is what sells. An FDE lives in the dirty one.

The 90 days: hand your pipeline to someone else, in writing, and take one signed deployment through go-live and 60 days past it. Weeks one to four, do the integration on the customer's real data and discover everything the demo hid. Weeks five to eight, ship to production and sit with the first users. Weeks nine to twelve, own the outcome number. Your compensation for the quarter should be tied to that number and to nothing else, or the transition will not hold, because the pull of the pipeline is stronger than intent.

The trap: the demo reflex. When something breaks in production, an SE's instinct is to show the customer what it looks like when it works. An FDE's instinct is to fix it. The first instinct built your career. It will end this one.

What all three have in common

The transition is complete when a customer calls you before they call your account manager. Not because you are friendlier. Because they have concluded you are the person accountable for their result, and that is the entire job.

Until then, whichever door you came through, you are a vendor's engineer who visits.

Senior people make this transition. Plank's July 2026 look at open FDE roles found 3 percent early-career, and that matches what the job demands: enough standing to tell a customer that their process is the problem, and enough range to fix it anyway. If you are early in your career and want this, the path is to become excellent at one of the three doors first.

The chapter on building the FDE team covers the hiring side of the same three doors, and the standing argument on AI Product Management is why all three are converging on one seat.

Start this week

Whichever door you are standing in, write down the third thing. For a PM: the last production system you shipped alone. For an engineer: the last week you spent in a customer's building. For an SE: the last outcome you were measured on after a signature.

If the honest answer is never, that is the gap, and the 90 days above is how to close it.

Sources: Nabeel Qureshi, Reflections on Palantir · Natalie Meurer, The Dirty Secret of Forward Deployed Engineering, AI Engineer 2026 · Plank, What Is a Forward-Deployed Engineer (July 2026 role data)