The title escaped Palantir and is now open at every frontier lab. Most people searching it want one thing answered: is this real engineering, or a customer-facing job with a better title?
It is real engineering. It is also genuinely not the job you have if you are a platform engineer today, and the difference is not seniority — it is where your week goes and what you are measured on.
A forward deployed engineer builds and ships production software inside someone else’s environment. You own the outcome at a named customer, not a component in your own codebase. The model is ready; their data, their auth, their edge cases are not. You are the person who goes and stands in that gap.
Where the week actually goes
The clearest way to see the job is to compare how the hours split. These are typical shapes rather than survey data, but the ratio is the point: an FDE spends roughly a third of the week in contact with the customer, and that time is the job, not an interruption to it.
The three jobs people confuse it with
Every one of these exists, every one is a real career, and none of them is this. The confusion costs candidates offers, because they answer the interview as the wrong role.
| Role | Owns | Ships to production? | Measured by |
|---|---|---|---|
| Sales engineer | The demo and the technical win | No — the demo is the artifact | Deals influenced |
| Solutions architect | The design and the diagram | Rarely — someone else builds it | Architectures accepted |
| Consultant | The engagement | Sometimes, then hands it over | Billable delivery |
| Forward deployed engineer | The working system at that customer | Yes, and carries the pager for it | Whether it is actually in use |
The last row is the whole distinction. If nobody at the customer uses the thing you built, an SE still had a good quarter and an FDE did not.
Why the role exists now
Every lab hit the same wall at the same time. The model became good enough to be worth deploying, and the gap moved somewhere the model cannot reach: the customer’s data is messy and undocumented, their auth is bespoke, their definition of “done” lives in someone’s head, and their edge cases are not in anyone’s eval set.
That gap is not closed by a better model or a better doc site. It is closed by an engineer who can sit in their environment for six weeks. Which is why the same job appears under several names — forward deployed engineer, applied AI engineer, solutions engineer (engineering track), deployment engineer, member of technical staff, deployments. Read the responsibilities, not the title.
What you actually do in the first six weeks
Weeks 1–2 — find the real problem
The stated problem and the valuable problem are rarely the same. “We want a chatbot over our docs” usually turns out to be “our support team answers the same forty questions and cannot find the answer in under four minutes”. Those need different systems. Getting this wrong costs the entire engagement, which is why the interview weights it so heavily — see what the FDE interview actually asks.
Weeks 2–4 — meet the data as it really is
Scanned PDFs, a table nobody has updated since a migration, three systems that disagree about who the customer is. This is where most of the engineering time goes and where nearly all of the schedule risk lives. See document processing for what this looks like in practice.
Weeks 4–6 — ship something narrow that works
One workflow, in production, used by real people, with an evaluation set drawn from their traffic rather than your imagination. Narrow and used beats broad and demoed — every time, and it is the thing that gets the second engagement funded. The premium guide covers what “in production” has to mean here: rollout, the failure modes to design for, and where a human stays in the loop.
The instinct that makes you a good platform engineer — build the general thing, handle every case — is the instinct that sinks a deployment. Six weeks of a general framework and nothing in production is a failed engagement. One narrow workflow in production is a renewal.
What makes someone good at it
- Speed to the real problem. Willingness to spend the first two days asking rather than building, and the judgement to know when the stated ask is not the ask.
- Tolerance for other people’s systems. You will spend more time reading unfamiliar code and undocumented schemas than writing anything new.
- Writing. A large share of the output is a memo that makes a decision legible to people who were not in the room.
- Scope discipline under pressure. The customer will ask for everything. Saying “not in v1, here is why” without damaging the relationship is a core skill, not a soft one.
- Comfort being the only engineer in the room. No one to pair with when the auth flow makes no sense at 6pm on their VPN — and their constraints become yours, from tenant isolation to the security review.
The parts nobody mentions in the job post
| What it means day to day | |
|---|---|
| Travel | Varies from none to substantial. Ask the specific number in the first call; it is the most common mismatch. |
| Their tooling, not yours | Their cloud, their CI, their laptop policy. Your preferences are frequently irrelevant. |
| Context switching | One to three accounts at once, each with its own stack and its own politics. |
| Compensation | Bands generally sit above the equivalent platform level, with the frontier labs equity-heavy. Figures move too fast to print — the roundup cited in the interview post is a starting point, but ask for the band directly. |
| Career path | Two exits that recur: into product, because you have seen forty real users; or into staff platform work, building the thing every deployment kept rebuilding. |
How to move into it
From platform engineering
You already have the build half. What you need is evidence of the other half: a project where you talked to the users yourself, cut scope deliberately, and can say what you chose not to build. Interviewers hear “I owned the outcome” and immediately test it, so have the specifics ready.
From consulting or solutions work
You have the customer half. What gets doubted is whether you ship and then carry it. The fix is a production system you built and operated — on call, incidents, the boring parts. One real deployment beats a portfolio of architectures.
In both cases the technical bar is a genuine bar. You are expected to design an agentic system on a whiteboard, name the failure modes, and put numbers on the tradeoffs. The system design framework and first agentic system sections are free and the place to start; the depth expected at this level — staff-level architecture, scaling, cost control — is in the premium guide.
The job is production engineering with the customer inside the loop instead of on the other side of a ticket. If reading unfamiliar schemas, cutting scope in front of a stakeholder and carrying a pager for something you built at somebody else’s company sounds like the good part of the work, this role is unusually well paid for what it asks. If it sounds like the tax you pay to get to the real work, it is the wrong role, and no amount of preparation fixes that.
If it does sound right, the loop is the next thing to understand: three stages, one decomposition case, and a failure mode that ends most candidates in the first ten minutes — the FDE interview, stage by stage.