Choose an FDE when…
The customer problem is ambiguous; solving it requires writing or operating production code; the environment changes the technical design; and field learning should improve a reusable product or deployment system.
Employer role-design guide
Do you need an FDE?
Choose among Forward Deployed Engineering, Solutions Engineering, Implementation Engineering, Applied AI Engineering, and deployment leadership by the work—not the fashionable title.
01 · Fast answer
Follow the durable owner.
The best first question is not “How customer-facing is this role?” It is “Who owns the production outcome after the customer says yes?”
Choose Solutions Engineering when…
The central outcome is evaluation and technical design before purchase, while another team owns durable production implementation.
Choose Implementation Engineering when…
The product is sold, the target state is understood, and success comes from reliable configuration, integration, migration, training, and handoff.
Choose Applied AI Engineering when…
The primary owner is a reusable model, agent, evaluation system, or AI product capability—not an end-to-end customer deployment.
A common fifth answer
If one person must coordinate discovery, executives, domain teams, governance, rollout, adoption, and delivery risk while engineers own most production code, the role may be a Technical Deployment Lead paired with FDEs—not one impossible requisition.
02 · Decision matrix
Five patterns hiding behind adjacent titles.
The matrix scrolls horizontally on small screens.
| Role pattern | Primary outcome | Production-code ownership | Customer phase | Evidence of success |
|---|---|---|---|---|
| Forward Deployed Engineer | A consequential customer workflow works in production and creates reusable learning. | Direct: designs, writes, deploys, and often operates code across the needed stack. | Discovery through rollout and adoption. | Adoption, stable production behavior, workflow impact, and reusable product or tooling improvements. |
| Solutions Engineer | A buyer can evaluate the product and commit to a viable technical approach. | Usually demos, prototypes, examples, or integration designs; durable ownership sits elsewhere. | Discovery, evaluation, proof, and technical close. | Sound evaluation, realistic commitments, successful proof, and clean handoff. |
| Implementation Engineer | A sold solution is integrated, launched, and handed over reliably. | Varies within a repeatable delivery boundary. | Post-sale delivery with explicit milestones and handoff. | Launch quality, scope control, customer readiness, and supportable handoff. |
| Applied AI Engineer | A reusable AI capability, evaluation system, or product feature improves. | Direct, commonly inside the core product or applied research stack. | May work with design partners, but customer delivery is not always the durable unit. | Evaluation quality, reliability, product adoption, and reusable platform capability. |
| Technical Deployment Lead | A multi-stakeholder deployment reaches an operational outcome with risks controlled. | Technically credible and may contribute code, but coordinates more than owns every layer. | Executive and working-team alignment from scope through adoption. | Decision velocity, milestone quality, adoption, risk resolution, and outcome delivery. |
03 · Six dimensions
Calibrate the boundary before writing the requisition.
Outcome unit
Is the durable unit a closed deal, completed implementation, production workflow, reusable AI capability, or adopted program?
Code boundary
Who writes, reviews, operates, and carries failure risk for production code after the first demonstration?
Customer phase
Does ownership peak before sale, after sale, across the lifecycle, or primarily inside the product team?
Problem ambiguity
Is the target state known, or must the person discover the problem and negotiate success?
Environment dependence
Do customer data, infrastructure, regulation, security, legacy systems, or domain workflows materially change the solution?
Reusable leverage
Who turns one deployment’s learning into product changes, tools, patterns, documentation, or a repeatable delivery system?
04 · Six-month outcome
Write the outcome before the requirements.
A defensible role brief can complete this sentence without relying on the title.
Outcome statement
Within six months, this person will have [deployed or changed what] for [which user or customer] inside [which technical and organizational constraints], demonstrated by [observable evidence], while turning the work into [reusable product, tooling, or operating leverage].
Copy the role-calibration worksheet
WHY NOW What customer, product, revenue, or operational constraint makes this role necessary? SIX-MONTH OUTCOME What must work in production, for whom, and what evidence will show it? OWNERSHIP BOUNDARY Discovery / technical scope / system design / production code / operation / adoption / product feedback CONSTRAINTS Customer systems and data / security / regulation / location / travel / domain knowledge HIRING EVIDENCE Three must-have signals / acceptable adjacent evidence / unknowns the interview must resolve
05 · Sources and limits
Primary descriptions, visible limits.
This is an editorial operating framework—not a validated occupational taxonomy or legal classification.
- OpenAI — Forward Deployed EngineerOfficial role description; reviewed August 12, 2026.
- Palantir — Software Engineer and FDSE role comparisonOfficial careers explanation; reviewed August 12, 2026.
- Palantir — Open positionsOfficial role taxonomy; reviewed August 12, 2026.
- Deming’s List — Verified FDE jobsCurrent employer postings used to inspect title and ownership variation.
Employer role calibration
Pressure-test the role before sourcing it.
Bring the live job, the six-month outcome, and the hardest unresolved boundary.