Forward Deployed Engineer: The FDE Five-Lens Framework

Created by Vishwanathan Chandran - https://medium.com/@vishwanathan.chandran/the-rise-of-the-forward-deployed-engineer-from-code-to-context-in-the-age-of-ai-102aec328db7

Overview

A forward deployed engineer (FDE) is a software engineer who embeds with a customer, builds on that customer's data and systems, and is judged by whether the customer's problem gets solved. The FDE Five-Lens Framework is a short operating model for that role, published by Vishwanathan Chandran in his essay The Rise of the Forward Deployed Engineer on Medium in November 2025. It names five lenses: Mission Clarity, Interdisciplinary Skillsets, Empowered Autonomy, Continuous Field Learning, and Outcome Metrics. This page explains the forward deployed engineer role, where it came from, and how to run FDE work through those five lenses.

The role itself is older than the framework and belongs to Palantir. According to The Pragmatic Engineer, the "Forward Deployed Software Engineer" role was created at Palantir in the early 2010s and was named "Delta", and Palantir employed more FDEs than "normal" software engineers until about 2016. Palantir's current job posting for the role says the company "pioneered this unique position, embedding talented engineers directly with our customers." Chandran credits Palantir too, and traces the term further back to the military practice of sending specialists to the front line.

The clearest statement of the forward deployed engineer vs software engineer difference comes from Palantir. A Palantir FDSE interviewed on the company blog explains that a traditional software engineer, or "Dev," builds a single capability that many customers use, while an FDSE enables many capabilities for a single customer. Palantir's careers page describes Deltas as the people who "ensure the solutions we build actually work", which covers data infrastructure, AI systems that work in practice, and extending the core platform when a new problem turns up. So forward deployed engineer responsibilities span delivery for one customer and contribution back to the product.

The role spread well beyond Palantir once AI products needed the same kind of integration work. Andreessen Horowitz called the forward deployed engineer the hottest job in startups in Trading Margin for Moat, arguing that enterprise AI products need deep integrations and context before they deliver value. The same piece counted 22 of the 311 open roles on OpenAI's career page as forward deployed or solutions engineering jobs at the time of writing. The Pragmatic Engineer describes FDE teams at OpenAI, Ramp, Salesforce and several AI startups.

Chandran's contribution is the five lenses, and his essay states each one in a single line. Mission Clarity means every engagement starts from a sharply defined mission with room to adapt. Interdisciplinary Skillsets means blending systems thinking with storytelling and data fluency with domain empathy. Empowered Autonomy rests on his line that "Bureaucracy is the enemy of forward deployment." Continuous Field Learning means each iteration feeds organizational knowledge. Outcome Metrics means measuring impact "by business outcomes, not code volume." Everything else on this page, including the principles' detail, the tradeoffs, the steps and the eight skills, is this page's own working synthesis built on those five lines and on the sourced practice at Palantir, OpenAI and the other companies cited here. Where a claim comes from a source, the source is linked.

This page adds one principle that is not among Chandran's five lenses: feeding field work back into the product. It is included because the practitioners who describe the role put it at the center. Palantir's FDSE says some of the company's most valuable product additions originated in the field, and Marty Cagan of SVPG argues that without a platform team generalizing what FDEs learn, a company ends up maintaining a pile of bespoke solutions.

The framework fits companies that sell complex, data-heavy software whose value depends on integration with each customer's systems, and it fits anyone working as a customer facing engineer who writes production code. It is a poor fit for self-serve products that deliver value without integration work. Teams that want a shared record of their missions and field learnings can keep it in Hamster; any shared document works as long as the whole team reads from the same one.

Core Principles

Mission Clarity

Chandran's first lens is that every FDE engagement begins with a sharply defined mission, with enough flexibility to adapt (Chandran). In practice a mission names the problem, the result that counts as success, and the time box. The flexibility clause matters because the ground truth often differs from the pitch: OpenAI's head of forward deployed engineering told The Pragmatic Engineer that what the customer describes in scoping often does not match the data and system reality. A mission gives the engineer a reason to decline adjacent requests, and the tradeoff is that someone has to back that refusal when the customer pushes.

Interdisciplinary Skillsets

The second lens is a blend of skills. Chandran describes FDEs who combine systems thinking with storytelling and data fluency with domain empathy. Palantir's FDSE describes the same range in plainer words: software development, data engineering, customer engagement and creative problem-solving (Palantir blog). An engineer alone at a customer site cannot hand the domain research to a product manager or the stakeholder conversation to an account executive. The cost is hiring: people with this range are harder to find and slower to develop.

Empowered Autonomy

Chandran puts this lens bluntly: "Bureaucracy is the enemy of forward deployment." Customer environments surface surprises daily, and an engineer who must route every architectural choice through headquarters loses both speed and credibility on site. Palantir's careers page states the company culture as "We optimize for impact, not consensus" (Palantir careers). The tradeoff is governance risk, because autonomous engineers can leave behind technical debt the core team inherits, so autonomy needs written decisions and regular check-ins to work safely.

Continuous Field Learning

Chandran's fourth lens says each iteration feeds back into organizational knowledge. FDEs see how users behave under real conditions: which workflows break, which features go unused, which needs nobody anticipated. OpenAI's FDE team, as described by The Pragmatic Engineer, runs regular knowledge-sharing sessions with research, readouts with product leadership and an internal "FDE Field notes" channel. Writing learnings up takes time away from delivery, so the plan has to set that time aside.

Outcome Metrics

The fifth lens measures impact "by business outcomes, not code volume" (Chandran). Palantir's description of Deltas, quoted in The Pragmatic Engineer, makes the same point: they "measure success in terms of impact on the customer's goal." A pipeline that processes every record but changes no decision is a failed engagement under this lens. Outcomes are slower to appear and depend on factors outside the engineer's control, which makes performance reviews harder.

Feed the Platform (Added by This Page)

This principle is not one of Chandran's five lenses; it is added here because the sources on the role treat it as central to the job. Field solutions should flow back into the core product so the next customer starts further ahead. Cagan at SVPG describes Palantir's platform organization as constantly generalizing capabilities identified by FDEs, and warns that FDEs alone would produce large bespoke solutions to maintain indefinitely. The tension is that product teams rightly resist being steered by one customer, so the FDE's job is to turn a specific request into a pattern that serves many.

FDE Compared With Related Roles

People searching for the forward deployed engineer role usually want to know how it differs from roles they already know. The rows below state only what the linked source says.

Steps

1. Define the mission and success criteria Before anyone deploys, write down the business problem, the measurable result that counts as success, and the end date. Bring the customer's operational owners into this conversation, since they feel the problem and will judge the result. Keep the scope small enough to finish; a16z's advice to teams building their first services function is to start small in scope (a16z). Record what is out of scope as clearly as what is in. The output is a one-page mission brief both sides have agreed to.

2. Go and see the customer environment Spend time where the work happens before writing code, which is the idea behind the Lean term gemba, the "actual place" where value is created (Lean Enterprise Institute). Map the data sources, pipelines, access controls, compliance rules and the people who will use, approve and maintain the system. OpenAI's FDE process begins with a couple of days on site mapping user processes before prototyping (The Pragmatic Engineer). You are done when you can sketch the current state from memory and point to where your system attaches. Do not assume the environment matches one you have seen before.

3. Validate before you commit to delivery Check whether what was scoped is still the most valuable thing to do once you see the real data. OpenAI's FDEs agree validation criteria with the customer and build evaluations before the delivery phase (The Pragmatic Engineer). If the data or systems rule out the original plan, rescope now and tell the sponsor why. A short validation step costs far less than discovering the wall halfway through delivery. Update the mission brief with anything that changed.

4. Build and ship inside the customer's infrastructure Deploy into the customer's environment using their tooling, security controls and change process wherever possible. Ship in small increments that deliver partial value and produce feedback, and keep the usual engineering discipline: Palantir's FDSE lists code reviews, deployability work and monitoring of production systems as routine field practice (Palantir blog). Resist building a parallel stack that is easy for you and impossible for the customer to run after you leave. Document as you go.

5. Run the learning loop during the engagement Keep a structured log of what breaks, what users work around, what they ask for and what they ignore. Tag each entry as specific to this customer or likely to recur elsewhere. Share it with the product team on a fixed rhythm while it is fresh, the way OpenAI's FDEs hold regular readouts with product and research (The Pragmatic Engineer). Pay most attention to gaps between what the customer says and what you watch them do.

6. Turn field learnings into product proposals Before the engagement ends, group the recurring observations into proposals for the core product. Each proposal names the customer segment it serves, the outcome it enables and a rough build cost. Palantir's FDSE describes asking how a feature built for one customer can be generalized into the base platform (Palantir blog). Raw customer requests without that abstraction rarely get prioritized.

7. Measure the outcome and close the mission At the end date, measure against the success criteria from step one and present the result to the customer and to your own team. If the mission fell short, run an honest retrospective: was it scoped wrongly, was the environment harder than expected, or did adoption stall for organizational reasons? Hand over documentation so the customer can operate the system without you. a16z gives similar advice, "Leave a trail," to companies that plan to pass services work to ecosystem partners, and tells them to document everything (a16z). A formal close stops the engagement from sliding into open-ended support.

When to Use

• Your product only delivers value after integration with each customer's data, systems and workflows, and self-serve onboarding cannot bridge the gap. This is the situation a16z describes for enterprise AI products that need deep integrations and context.
• You are deploying AI or data systems into regulated settings such as defense, healthcare or finance, where access controls and compliance rules differ per customer and cannot be designed from outside.
• You have a handful of early enterprise customers and each deployment is both delivery and product discovery. Cagan's point is that sending engineers to several customers lets them see what is common and build one product for all of them.
• A strategic account adopted the product but never reached the outcome it bought it for, and the cause is an integration or workflow gap that needs an engineer on site to diagnose.
• You are a customer facing engineer, or hiring one, and need a shared vocabulary for what the forward deployed engineer role covers and how its work is judged.

When Not to Use

• The product is self-serve and customers reach value through settings and a UI. An embedded engineer adds cost without matching value there.
• You cannot give engineers real decision rights in the field. If every technical choice needs central approval, the engineer becomes a relay between the customer and headquarters and Empowered Autonomy cannot work.
• There is no path from field learnings into the roadmap. Without it, engineers rebuild the same custom solution for each customer, which is the bespoke trap Cagan describes.
• The engagement is pure custom services that shares no data model, architecture or user patterns with your product. That is consulting work and deserves a services model with its own economics.