Software engineer to forward deployed engineer: how to make the move

Yes, a working software engineer is well placed to become a forward deployed engineer, because every FDE posting we read asks for the strong hands-on coding you already do^3,4,5. What you need to add is proof that you can own an outcome for one specific customer: run the discovery conversation, scope work that arrives as a business problem rather than a ticket, build inside systems you do not control, and stay until it is used in production^3,10. You can start building that proof in your current job, in four stages over about 90 days.

Coming from a different background, or want the whole role first? Start with our roadmap for becoming a forward deployed engineer.

How is an FDE’s week different from a product engineer’s?

Palantir, which hires for both titles, sums up the difference in a 2019 post: a product engineer works on one capability for many customers, while a forward deployed engineer works for one customer using many capabilities⁸. The table compares the two jobs using current postings from Palantir, OpenAI and Anthropic, PostHog’s public handbook and that post, all checked on October 22, 2026. Each source is one company’s description at one time, so read the table as a pattern, not a definition.

The overlap is bigger than the job titles suggest. O*NET’s task list for software developers already includes analyzing user needs, consulting with customers on technical issues, coordinating software installation and training users¹³. OpenAI’s product posting asks for engineers who take a capability from an ambiguous starting point through launch¹¹. The switch changes the proportions of the work, and who you answer to, as much as it changes the skills.

What carries over, and what do you have to build?

Your strongest asset is the engineering every posting asks for. OpenAI asks its FDEs to write and review production-grade code across frontend and backend, Anthropic asks for strong Python and experience shipping production applications, and Palantir asks for a strong coder^3,4,5. Anthropic’s London posting names a software engineer with consulting or product experience as one fit⁴. Debugging, system design, code review and running live systems all transfer directly.

Four things may not come with a product engineering job, and they are where to focus:

• Discovery. Anthropic describes walking into a discovery conversation with only a business problem and leaving with a defensible technical strategy¹⁰.
• Scoping against someone else’s deadline. OpenAI’s FDEs scope work, sequence delivery and trade off scope, speed and quality³. PostHog’s FDE team writes a brief with a measurable outcome, a rough timeline and a shared definition of done before delivery starts, and sends it to the customer to confirm⁶.
• Owning the outcome after launch. Anthropic expects its FDEs to anticipate security and procurement gates and to deliver production systems the customer can operate¹⁰. Shipping is the middle of the job, not the end.
• Working inside systems you do not control. Legacy systems, identity and access, and compliance requirements are part of the environment Anthropic describes¹⁰. Back at your own company, product teams still own their code: PostHog’s FDEs follow the same review standards as everyone else and work with the owning team rather than around it¹⁴.

FDE roles at AI labs add a fifth item: hands-on work with language models. OpenAI asks for experience building or deploying systems powered by LLMs, and Anthropic’s London role asks for production LLM experience^3,4. Anthropic’s staff-level posting expects hands-on LLM and agent experience but says side projects and prototypes count and you need not have shipped agents to production¹⁰.

Should you switch? What you give up and what you gain

The costs first:

• Deep focus time. An FDE week mixes customer meetings, travel and code. In a 2018 survey of 141 software developers, respondents saw considerable similarity between the disruptiveness of task switching, planned or unplanned, and random interruptions, and named high cognitive cost and low performance as the main consequences⁹. It measured perceptions rather than output, but it is a fair warning if you do your best work in long uninterrupted blocks.
• Depth in one codebase. A Palantir product engineer belongs to a team that owns one platform component end to end⁸. As an FDE you trade that depth for breadth across many systems, and at PostHog, for one, FDEs do not own product direction¹².
• A predictable schedule, and being the face of the company. The postings we read list travel from up to 25% at Palantir to as much as 50% at OpenAI^5,4,3, and a customer’s deadline does not move for your sprint plan. Anthropic expects its FDEs to represent the company at the highest level in customer environments⁴, and Palantir’s posting says driving projects to deployment increases your pain threshold⁵.

The gains are as concrete. You see the people you built for use the work: asked what they like most about the role, one Palantir forward deployed engineer says how fulfilling it is to watch the customer use what the team built, and FDEs quoted in the same 2019 post describe engaging with other areas of the business, including strategy⁸. Your field reports also shape the product: OpenAI’s FDEs share feedback meant to change product and model roadmaps³, and PostHog calls its FDE team one of the fastest feedback loops between real customer usage and the roadmap¹⁴.

Pay is not a reliable reason either way. At Palantir in New York, the forward deployed software engineer posting and a backend software engineer posting publish the same estimated salary range, $135,000 to $200,000^5,7. At OpenAI in San Francisco, the FDE posting lists a salary of $185,000 to $300,000 and a Codex Enterprise engineering posting lists $230,000 to $385,000, both plus equity^3,11, though the two roles may sit at different levels. All four ranges are base salary as listed on October 22, 2026; Palantir says total compensation may also include restricted stock units⁵.

What is the roadmap from software engineer to FDE?

This roadmap follows the approach Torchlane publishes. Its AI FDE training page lists four responsibilities of an AI FDE, which we use as four stages: define the business requirement, build and integrate the system, test errors, access and unfamiliar cases, and deploy, explain and improve¹. The page also groups the skills an AI FDE uses into business and product judgment, technical implementation, reliability and security, and communication and ownership¹. You arrive with much of technical implementation; the stages add practice in the rest.

We have a business connection with Torchlane.

The 90-day pacing is ours, not Torchlane’s, and it is not a timeline to an offer: we found no published data on how long the switch takes.

Stage 1: Define the business requirement (days 1 to 30)

Torchlane describes this stage as talking to the people doing the work and identifying the bottleneck, the decision, the source information and the constraints¹.

• Read the postings. Read five FDE postings at companies you would join and list what they repeat: languages, customer work, LLM experience, travel.
• Treat an internal team as your customer. Pick a team outside engineering with a manual, painful workflow, such as finance, support or operations, and hold the discovery conversation yourself before you write any code.
• Shadow your solutions engineers. Join at least two customer calls and offer to own the technical follow-up. You hear customers describe problems in their own words.
• Write the one-page brief: a measurable outcome, a rough timeline and a definition of done, the format PostHog’s FDE team uses before it commits⁶.
• Tell your manager what you are building toward, and ask about escalations, rotations or an FDE team.

Stage 2: Build and integrate the system (days 31 to 50)

Torchlane describes this stage as designing a workflow, connecting the required systems, putting models where they add value and using ordinary code for calculations and deterministic rules¹.

• Volunteer for integration and migration work. These projects put you inside someone else’s systems and schedule. Complex implementations, migrations and integrations are among the triggers PostHog lists for bringing in its FDE team¹².
• Ship a first version into the team’s real workflow, not a demo environment.
• If you are aiming at AI labs, build one LLM application against a real workflow. Anthropic says side projects and prototypes count¹⁰.

Stage 3: Test errors, access and unfamiliar cases (days 51 to 70)

Torchlane describes this stage as creating meaningful evaluations and checking unfamiliar cases, incomplete inputs, permissions and how the system behaves when something fails¹.

• Build a small evaluation set from real cases, including odd and incomplete ones, that you can explain to a non-engineer.
• Check permissions and failure behavior with the team that owns each system you touch.

Stage 4: Deploy, explain and improve (days 71 to 90)

Torchlane describes this stage as helping people use the system, documenting decisions and operational steps, monitoring the result and responding when reality changes¹.

• Support the project through real use and write down what changed for the team, with a short runbook someone else can follow.
• Take escalations for a key account. Product engineers may already carry support duties: one Palantir team lead lists responding to support tickets among hers⁸. Ask to be the named engineer when your largest customer has a production problem, and join the follow-up call, not only the fix.
• Ask about customer rotations. Palantir says its Foundry software engineers may be offered Frontline, a short-term assignment embedded with customers⁷.
• Move to an existing FDE team inside your company. If your employer has one, this can be the lowest-risk route, because the people deciding already know your work. Palantir’s 2019 post describes a lot of movement between its product and forward deployed roles⁸, and OpenAI’s Codex Enterprise engineers work closely with its FDEs¹¹. We found no published data on how often internal moves happen, so ask the FDE team’s manager what they look for.

Check your evidence, then retell it

Torchlane assesses its AI FDE projects in seven categories: problem framing (15%), correctness (20%), engineering quality (15%), security, privacy and compliance (15%), product and usability (10%), business value (10%) and communication (15%). Passing requires at least 3 out of 4 in every category and no critical failure¹⁵. Use the seven as a checklist for an internal project; the weights are Torchlane’s.

We have a business connection with Torchlane.

Then retell the work in the shape postings use. OpenAI asks for people who have scoped and delivered complex systems in ambiguous environments and who communicate clearly with customer stakeholders³; Anthropic asks for the communication skills to run discovery with customers⁴. Rewrite your strongest projects in that shape: the customer problem, the environment and its constraints, what you built or ran, and what changed for the customer.

The second version shows discovery, scoping, work inside another team’s system and ownership of the result, with no change of title. Use the same material in interviews, with three stories: you found the real problem behind a request, you cut scope to protect a deadline, and something broke in front of a user and you fixed it. Apply internally first if your company has an FDE team, then externally, and practice explaining one trade-off you made to a non-technical listener in two minutes. Our guide to writing a forward deployed engineer resume has bullet rewrites for each starting background.

Should you use a program to follow this roadmap?

You can run all four stages inside your current job. A structured program can add outside review, a fixed set of projects and a portfolio. Our top pick for that is Torchlane’s AI FDE training, which reviews projects against published criteria² and describes the AI FDE role the way this roadmap does¹.

For an engineer, Torchlane’s page says to use the program to add customer discovery, applied model evaluation, client communication and a portfolio of business-focused implementations¹. You choose one of three guided builds, complete three to six projects from a bank of 12 simulated client engagements and finish a capstone, with a 90-day training goal, a starting plan of about nine hours a week and 120 days of access^1,2.

Torchlane says production architecture and complex integrations may require experience beyond the program, so compare your engineering depth with each employer’s requirements¹. It is career preparation, and completing a program does not guarantee hiring, a salary or a promotion^1,2. Its projects use simulated clients², so treat them as a complement to real customer work, not a replacement.

We have a business connection with Torchlane.