A few months ago I moved into a Forward Deployed Engineer role, building on Palantir Foundry. On paper it still says "engineer." In practice, most of what I optimized for on a day-to-day basis changed.
What's a Forward Deployed Engineer? It's an engineer embedded directly with a customer's team rather than sitting behind a product backlog. Instead of building a general-purpose product for anonymous users, you go on-site (or on-call) with a specific customer, learn their actual workflow, and build and ship a working application against their real data - often in the same week you start talking to them. The role originated at Palantir and has since spread to other companies selling directly into enterprises.
The role sits at the intersection of three things that are each fine on their own but rare together: engineering ability, comfort operating directly with customers, and enough domain context to know what you're actually modeling. Most engineers have one or two of these. FDE is the job where you need all three at once.
The problem is no longer well-defined
As an SDE, most tickets already came with a shape: a spec, an API contract, a bug report with a stack trace. My job was mostly to make the shape real - write it, test it, ship it.
As an FDE, the starting point is usually a customer describing a workflow that's currently held together by spreadsheets, email, and one person's institutional memory. Nobody hands you a spec. Figuring out what the actual problem is - not the one the customer describes first, but the one underneath it - is most of the job. The coding is often the easy part once you get there.
You're in the room, not behind a queue
As an SDE, customer problems usually reached me filtered through product, support, or a ticket. As an FDE, I'm often the person in the room (or the call) directly with the customer's team, watching how they actually work before I write a single line.
That's uncomfortable at first if you're used to a buffer between you and the person who'll judge whether the thing works. It's also the fastest feedback loop I've had in my career - you find out in the same afternoon whether an approach makes sense, instead of a sprint later.
Ownership moves from code to outcomes
An SDE's unit of ownership is usually a service, a module, a codebase - you know it cold, and "done" meant tests passed and the PR merged.
An FDE's unit of ownership is closer to "did this actually change how the customer works." Foundry gives you the primitives - data integration, ontology, applications - but nothing about the platform tells you whether you modeled the right entities or built the right workflow. That judgment doesn't show up in a diff.
Speed means something different
Shipping fast as an SDE usually means tight PRs and a good CI pipeline. Shipping fast on Foundry, in front of a customer, means being willing to build something rough, put it in front of them same-day, and rebuild half of it based on what they say when they see it. Polish comes later, once you know you're building the right thing. I had to unlearn some instincts about "doing it properly the first time."
What carried over
The specific stack mattered less than I expected. The muscle of taking something ambiguous and making it concrete, of debugging a system you didn't design, of explaining a technical tradeoff to someone non-technical - that's what actually transfers. The tools around it are just tools.
If you're considering a similar move: the technical ramp-up (new platform, new patterns) is the smaller adjustment. The bigger one is getting comfortable being judged by outcomes you can't fully control from your side of the keyboard.