Forward Deployed Engineer: Role, Salary and the Non-Coding Skills That Matter

A forward deployed engineer is a software engineer who builds inside the customer's company and stays until the thing actually works.

Say you're two weeks into a customer project. The ticket says “automate the invoice approval”. You build it, the tests are green, it's live on Friday. On Monday the finance lead looks at it and says that's not what she meant. What she meant was: stop month-end from stalling because three people approve everything by email. Your code is fine. The project still fails.

That gap, between what the ticket says and what the customer needs, is a large part of this job. This post covers the role and the salary first, then spends most of its time on that part, because many FDE guides mention it in one line and move on to the tech stack.

What is a forward deployed engineer?

A forward deployed engineer (FDE) is a software engineer who works directly inside a customer's organization, builds and deploys the solution in their real environment, and stays responsible until it works in production. The role started at Palantir and is now one of the fastest-growing jobs in tech: job postings grew 350% from Q1 2025 to Q1 2026, according to Paraform.

Palantir created the role because its government customers needed security clearances and NDAs even for a demo, so the engineers simply moved in with the customer. Internally they were called Deltas, and until 2016 Palantir had more of them than regular software engineers (The New Stack).

AI turned it into a mainstream job. The models work. Getting value out of them inside a real company is a different story. MIT's NANDA initiative found that 95% of enterprise generative AI pilots delivered no measurable return, and its report puts that down to a “learning gap”: the tools don't adapt to how the company actually works (Fortune). So OpenAI, Anthropic, Google, Databricks and a long list of startups started sending engineers to their customers.

The week is roughly half code and half everything else: mapping processes, meetings with stakeholders, infrastructure work. Most of both halves happens with the customer. FDEs spend 60 to 80% of their time on site or inside the customer's systems, and travel 20 to 50% (PostHog).

Compared with a regular engineering job, this is what changes:

How much does a forward deployed engineer earn?

In the US, the median FDE salary in job ads is around $174k, and the AI labs pay far more. In Germany, an FDE in Munich earns around €94k base and €107k in total. All figures as of October 2026, and this market moves fast.

Germany sits clearly below the US, but the figures come from different kinds of data, job ads on one side and salary reports on the other, so don't read too much into a direct comparison. The jobs exist in Germany too: Glassdoor listed 310 open FDE roles in Germany in September 2026, with Salesforce, Anthropic, Google, OpenAI, Palantir and Databricks among the companies hiring.

Why the hard part of the job isn't the code

The New Stack put it in two sentences: “The model is usually the cleanest part. The hard part is finding the workflow nobody documented, the data source people actually trust, and the person who knows why the process works that way.”

The job ads say the same. Of about 1,000 FDE postings, 47% explicitly ask for customer-facing work and 68% require travel (Bloomberry). Palantir's own postings talk about “increasing your pain threshold to deliver real value”.

You see it in the interview too. The signature round is the decomposition interview, which started at Palantir: “A city wants to reduce 911 response times using your platform. Design the solution in 60 minutes.” Strong candidates don't start with a tech stack. They ask clarifying questions first, cut the problem into smaller pieces, propose a small first version and talk through the trade-offs (Hashnode). The round tests how you ask, scope and explain as much as what you know.

Which non-coding skills does a forward deployed engineer need?

Six skills matter most here, and none of them is new. We covered the general version in Software Engineer Skills. The difference here is pressure: the person on the other side of the table pays the bill, and you're in their building. Each skill below comes with a situation, a tool from our course The Senior Shortcut and one thing you can try this week in the job you have now.

1. Turn a vague request into a spec

Back to the invoice approval. The finance lead and you both left the kickoff sure you'd agreed. You hadn't. People leave conversations with different pictures in their heads and don't notice, because the words matched.

The tool is simple and almost nobody uses it: restate the request in your own words before you build anything. “So the goal is that month-end closes on time, and the approval emails are what's blocking it, right?” If she says “not exactly”, you just saved two weeks. The second tool is a shared vocabulary. Write down what “approval”, “invoice” and “done” mean for this customer, and use their words in your code and your updates.

I've been on the asking side of this. We once wanted to build a styleguide step by step, and the agreement was to start small: buttons, colors and so on. I expected to see a demo of the simple things. The engineers wanted a solution that worked for all the possible ways we might define things in the styleguide. So they took the technical path first and set up a larger infrastructure that fit our Rails environment, with full Rails-like components defined in the styleguide together with the React framework we used. Four weeks went into the setup, and we still had no usable prototype to test and iterate on.

Try this week: before you start your next ticket, restate it to the person who wrote it, in your words.

2. Explain it to the person who signs off

The customer's VP doesn't care about your retry logic. She cares whether month-end closes on time and what it costs. If you open with the architecture, you lose her in the first minute.

Before any meeting, answer a few questions about your audience: what do they get measured on, what do they want to hear, what keeps them up at night, what should you avoid saying. Then bring a decision proposal, with the options and your pick: “We can go live on the 15th with two workflows, or on the 30th with all five. I'd go with the 15th, here's why.” In writing, use BLUF, bottom line up front: the decision or result first, then context, details and the next step.

Try this week: send your next status update with the bottom line in the first sentence.

3. Sell the outcome, not the feature

You built a smart matching algorithm and you're proud of it. The customer doesn't buy matching algorithms. They buy “finance closes the month two days earlier”.

A value proposition has three parts: the need, the solution and the added value. Also check who you're talking to: the user of your tool is often not the person who pays for it, and they want different things. As we put it in Refactoring vs Rewriting: management buys speed, not frameworks.

Try this week: write one sentence on what your current feature is worth to whoever pays for it.

4. Make a technical problem land with the business side

The pilot worked, so the customer's VP wants three more workflows on top of it. You know the prototype was hacked together for the demo date. “We need to refactor first” sounds like an excuse to her.

Translate it. Use an analogy from her world, like building three more floors on a house with a temporary foundation. Then name the consequences in business terms: every new workflow takes longer, bugs show up in month-end, the team can't react when requirements change. Best of all, put a number on it: “This costs us about four days of extra work every month.” Numbers in euros or days convince people who don't read code.

Try this week: put a monthly cost on one piece of technical debt you're carrying.

5. Handle a promise you didn't make

Sales promised the customer a feature in the last call. Nobody asked you. Now the customer's team lead asks when it ships.

Don't blame sales in front of the customer. It costs trust in your whole side, you included. First find out from sales what exactly was promised, then restate it to the customer to check they understood the same thing. From there, treat it like any new request: ask for the business value, the urgency and the priority. The promise often shrinks once someone has to explain what it's for. If the full version still can't be done, you have three honest answers: yes, by a specific later date; a smaller first version that covers the real need; or a polite and firm no. Afterwards, sit down with sales. Overpromises often come from distance, and the fix is being in the loop before the next customer call.

Try this week: the next time someone commits you to something, ask what exactly was promised before you estimate it.

6. Keep your head when the room turns on you

The customer's CTO looks at your work in a team meeting and calls it amateurish. Everybody is watching you.

Two reflexes make it worse: getting defensive and going silent. Silence is the bigger one, because then people without your expertise decide how it gets fixed. Separate what the criticism says from how it's said. Take the point seriously (“Which part doesn't meet your standard? I'll look at it today”), and if the tone crosses a line, address it later, one on one.

Try this week: in your next critical code review, answer the point, not the tone.

Can a junior developer become a forward deployed engineer?

Rarely, at least not straight away. Only 12% of FDE job ads are open to people with 0 to 2 years of experience, and 60% ask for 3 to 5 years. The most common way in is through regular software engineering: in a sample of 100 LinkedIn profiles of current FDEs, 45% had been software engineers before, 22% solutions engineers or architects and 15% data engineers or scientists (Bloomberry).

So the realistic path is mid-level engineer first, with the customer skills trained along the way. The six skills above are also what gets you promoted in a normal engineering job, as we lay out in Software Engineer Career Ladders. By the time you apply, you want to show both: solid engineering and stories where you turned a vague request into something that shipped.

FAQ

What to actually do this week

Pick one of the six tries above, just one, and do it this week. Restating your next ticket takes two minutes and will probably surprise you.

To be clear about what this post doesn't cover: the technical half of the job (Python, cloud, data pipelines and AI agents) and formal preparation for the interview rounds. Both need other resources.

The non-coding skills are what we work on. Utterskills trains the skills beyond code that decide who advances: communication, ownership and judgment. Built for developers, usable the same day, in our course The Senior Shortcut.