FDE vs software engineer: both write code, but the FDE owns one customer's outcome

Picture this: at 2am, a customer’s data pipeline stops running. On your old product team, you would have heard about it the next morning through a ticket that support had already triaged. As an FDE, you are the one who gets the call, and nobody stands in between.

Paraform, describing FDE work at Palantir, Runway and Greptile, puts it bluntly: there is no handoff to an implementation team; if the customer’s pipeline breaks at 2am, the FDE fixes it. That is the cleanest difference between the two jobs. Code is still code, with the same languages, the same git, the same reviews. What differs is who the code is for.

If you have a few years as a product engineer and want to move into FDE work, this is the thing to understand before learning any tool. Because the user of your code changes, the way you define “done”, the way you choose solutions and the way you talk to people every day all change with it.

Owning a component, or owning an outcome?

Aced.io sets the two roles side by side: a software engineer owns a feature, service or component, with the team and manager setting direction. An FDE owns the outcome for a customer, with a degree of autonomy the site likens to a startup CTO applied to a single account.

According to the same source, a core SWE rarely deals directly with customers, because they sit on a product team shipping features for everyone.

The difference is bigger than it looks. When you own a component, “done” means the tests pass and the PR is merged; who uses it, and how, is someone else’s concern. When you own an outcome, “done” means the customer has used the software to get done what they needed.

Noah Brier, in his Alephic newsletter, describes the FDE as someone who sits inside the customer’s organisation to actually get the software into operation, in contrast to traditional engineers, who usually work in the back office and are often deliberately kept away from customers.

Paraform notes that at Palantir, where these engineers go by the internal name Delta, they do not write a spec, pass it to the product team and sit back to wait.

A conversation that changes how you write code

Take a hypothetical case to see the skill at work. You are an FDE deploying an agent system that processes documents for a logistics company. In week two, the customer’s VP of operations calls: 40% of documents are still being kicked back to human reviewers, when they expected 10%.

A product engineer’s reflex is to open the logs and hunt for a bug. An FDE’s reflex is to ask first. The exchange might go like this:

VP: “The system isn’t working the way you promised.”

FDE: “I’ve looked at the numbers: 40% of documents are going back to reviewers. Of those, which kind causes your team the most trouble?”

VP: “Invoices from two big suppliers. Their format is completely different.”

FDE: “So if this week I handle those two formats specifically and get the rate below 20%, would your team be able to cut night shifts?”

VP: “Yes. That’s what we need most.”

Notice what just happened. You have not written a line of code, but you have changed the technical goal: instead of improving a general model for every document type, you will write dedicated parsers for two formats, something a product team would never prioritise because it serves only one customer.

Aced.io says plainly that an FDE who cannot talk to the customer’s VP is missing half the job. And as the scenario above shows, that communication half is what decides which code is worth writing.

But the work does not end with the customer. Paraform lists, as a typical FDE responsibility at AI startups, feeding lessons from the deployment back to the product team in near real time. Those dedicated parsers are data: if a third customer runs into the same suppliers, the product team has a reason to generalise.

You are both the person fixing things for one customer and the product’s eyes and ears.

How to practise while you are still on a product team

You do not need to change jobs to start training. Begin with how you define “done”. Each time you pick up a task, ask who the specific user is and what they can do once you merge; if you cannot answer, you are in component thinking, and that is the first habit to break.

Next, look for chances to hear end users describe problems in their own words. The question “which kind causes the most trouble” in the scenario above cannot be learned from documentation; it forms once you have heard enough people say “supplier X’s invoices” rather than “low precision on class Y”.

Then practise closing the feedback loop. Whenever you make a fix specific to one situation, write down why and send it to whoever owns the roadmap. That is exactly how an FDE brings lessons from the field back to the product team, and on a CV, a line such as “proposed generalising X after deploying for Y” says more than any framework you list.

When reading job descriptions, look for phrases like “own customer outcomes”, “embedded with customers” and “no handoff”. They match the FDE role as Paraform describes it: owning post-sale outcomes, with no handover to an implementation team.

If a JD only says something vague like “work with customers as needed”, do not jump to conclusions; ask in the interview who is responsible when a customer’s system breaks after go-live.

Three traps career-changers fall into

The most familiar trap is bringing a “generalise first” mindset to an account. Product engineers are trained to avoid single-use code; in FDE work, code used by only one customer is sometimes the right answer, provided you document it clearly and report it to the product team.

A subtler trap is waiting. The habit of writing a spec and waiting for another team to build it is hard to shake, but as Paraform’s description of Palantir’s Deltas makes clear, waiting is not an option. When Aced.io likens the FDE to the CTO of an account, the implication is that there is no one above you to wait on for a decision.

The last trap is treating customer communication as a side task, something to do once the code is finished. The right order is the reverse, as the scenario above shows: without the call with the VP, you would have spent two weeks tuning a general model without touching what the customer needed.

An old PR, rewritten for one customer

Pick a PR you merged recently. Rewrite its description as if you were the FDE for a single customer: name the (hypothetical) user, the outcome they need, what you would do if it broke at 2am, and one sentence you would send back to the product team once it was done.

Put it next to the original description and you will see clearly which parts of the job you have never had to think about.

The code does not change. Its user does, and the whole job changes with it.