The laziest description of a Forward Deployed Engineer is "an SDE who talks to customers." I believed a version of that myself before I made the move from SDE to FDE. It's wrong in a specific way: it treats the job as the same engineering work, plus a communication skill bolted on top. It isn't. An FDE's job isn't to translate a customer's requirements into code. It's to turn an ambiguous business problem into a working system - and building on Palantir Foundry specifically, what that actually requires looks nothing like the engineering job I used to do.
SDE vs Foundry FDE: the comparison people reach for
Most of that table is really one difference, restated six ways: an SDE starts with a shape someone else already imposed on the problem and makes it real. An FDE starts with no shape at all and has to impose one before anything gets built. That's the part "talks to customers" quietly skips past - it's not a soft skill you add on top of the engineering, it's a different first step in the job.
What "translate requirements into code" would actually look like
Say a customer tells you: "Our adjusters are spending too much time reviewing claims."
An adjuster investigates an insurance claim and decides how much it's worth paying out. Reviewing a claim means going through everything about it before signing off.
The instinct I had to unlearn was jumping straight to the shape of a solution - sketching an endpoint, a screen, a schema. Something like POST /claims/review. That instinct isn't wrong because the endpoint is a bad idea. It's wrong because at that point I don't yet know enough to know if it's a good one.
The questions that come before any of that
Before anything gets built, the actual work is narrowing down what the sentence even means:
- What does "too much time" actually mean - minutes per claim, claims per day, or something else entirely?
- Which parts of the adjuster's decision are deterministic, and which require judgment?
- What relationships between claims, claimants, and policies matter to that judgment?
- What should the system surface automatically, versus what the adjuster should still have to go find?
None of these have an obvious right answer, and the customer usually can't answer most of them on the first conversation either - "too much time" is a feeling before it's a number. Getting to real answers means sitting with how the work happens today, not asking the adjuster to spec their own solution.
Answering them, for real
Here's what those questions actually turned into, for that specific complaint. "Too much time" wasn't about clicking through a form - it was adjusters manually pulling up a claimant's history in a separate system before they could trust their own severity call, every single time. That's not a UI problem, it's missing context. The severity call itself - claim amount against policy limit - turned out to be entirely deterministic, no judgment involved, and computable from data that already existed. But "four claims from the same person in five months is worth a second look" wasn't something anyone could write down as a confident rule - too easy to either flag every repeat claimant or miss the one pattern that actually mattered. That one stayed a judgment call.
So the fix was never a smarter review screen. It was surfacing the claimant's history before the adjuster had to go looking for it, and reserving the four-claims-in-five-months judgment for something that could actually reason about it, instead of a brittle threshold that would be wrong in both directions.
Why Palantir Foundry makes this the whole job, not a phase
On a lot of platforms, you can get away with answering these questions late, or halfway, and still ship something that technically runs - the ambiguity never actually gets resolved, it just gets quietly patched around, one workaround at a time, until the app works without anyone having agreed on what "too much time" even meant. Foundry makes that harder to hide, because the thing you're building on top of - the Ontology - isn't yours alone. It's a shared, persistent representation that other pipelines and other applications will build on too. Model the Claim object type wrong, or hardcode the four-claims rule instead of leaving room for reasoning, and it's not one screen that's wrong - it's the foundation everyone downstream inherits.
That's why building on Foundry looks different from building a typical application. You're not just building a screen for an adjuster. You're modeling the business first, and only then putting an operational workflow on top of it.
Where this leaves the job
The FDE title isn't earned by being personable in front of a customer. It's earned by sitting with a question like "is four claims in five months worth a flag?" long enough to get a real answer, before writing anything that assumes one.
And getting to that answer is only the beginning.
Once you know what the system should do - surface the history automatically, leave the four-claims judgment to something that can actually reason about it - you still have to decide where that decision belongs: as a fact sitting in the data, a deterministic rule, an action a user takes, or something that has to reason its way there at runtime. Get that placement wrong and the same judgment call quietly breaks the next time this exact situation comes up.
That's where the engineering starts to show.
The customer gives you the problem. The FDE has to figure out where the solution should live.