From consultant to FDE: knowing the customer is an edge, but job ads want code you wrote yourself

Palantir has posted a job ad for a Forward Deployed Software Engineer working on US government healthcare and civilian programmes. It says the hire’s responsibilities “look like those of a startup CTO”. A few lines further down comes a hard requirement: strong coding, with demonstrable ability in Python, Java or C++.

Those two lines explain why consulting experience on its own is not enough. Sitting with customers, untangling problems and working with stakeholders is only the first half of the job. The second half is building the solution yourself, and both Palantir and Anthropic write that half into their job ads as specific programming requirements.

If you work in consulting, implementation or solutions engineering and want to move into an FDE role, your advantage with customers is real. But for it to count, it has to come with production code. So what should you practise first? The answer is in the job ads themselves.

The line is drawn at what you hand over

The quickest way to see the difference is to look at what is left when a project ends. Anthropic describes its FDEs as people who work inside customers’ systems to build production applications with Claude models. It names the specific deliverables: MCP servers, sub-agents, agent skills.

None of these is a slide deck or a report. Even so, Anthropic does not shut the door on people with a consulting background. It simply places that experience alongside two other conditions: strong Python programming and a track record of shipping production applications.

Pave, a compensation data company, calls the FDE a hybrid of engineer and consultant who works on site with customers and writes custom code for each of them. Read closely, “consultant” is only half of that label. The other half is engineer, and no amount of customer experience can stand in for it.

Why do companies want people who write their own code?

SD Times explains the difference between the two roles in terms of speed. Implementation consultants, it says, tend to be slower and favour proven solutions. FDEs sit down and build whatever is needed themselves. A good FDE starts creating value within a few weeks, with a small team.

Picture a public health agency that needs to merge case data from three legacy systems. Done the consulting way, the project team runs discovery workshops, writes an architecture proposal and hands it to another team to build. Every handover costs time, and context gets lost along the way.

Done the FDE way, discovery still happens in the first week. But that same week the engineer has already written a Python pipeline joining the first two data sources, shown the results to real users, heard their feedback and fixed it on the spot. There is no handover, because the person who hears the requirements is also the person writing the code.

That is also why Palantir stresses end-to-end ownership of critical projects, in small teams where each person has to carry several responsibilities.

“Ownership” here means being responsible until the system actually runs, not stopping at a recommendation. A consultant who cannot write code cannot own a project in that sense, however well they understand the customer.

Knowing how to code is still not enough: the code must be reusable

People coming from consulting face a subtler trap too. An essay by an industry practitioner on Substack warns that if an FDE role does not produce reusable technical output, the company is effectively running a services business, except its staff are called engineers.

Consulting is used to tailoring work for each client. Bring that habit into an FDE role and you will write single-use scripts, one version per customer, repeating the consulting model under a new title. There is code, but its value does not compound.

Go back to the health agency example. An FDE with a product mindset would write the legacy-system connector so that it can be split out as a shared component, and document clearly which parts are specific to this customer. The things Anthropic lists, such as MCP servers and agent skills, are all blocks that can be packaged and reused.

Where the consultant’s edge lies, and what to practise first

None of this means you should discount what you already have. Palantir’s job ad describes the FDSE’s work as engaging directly with customers to quickly understand their hardest problems, then building solutions to them. The first half of that sentence is something many pure software engineers still have to learn, and you have practised it for years.

The task is to make up the second half with evidence recruiters can see. The table below matches requirements from several sources with the evidence you can prepare for each. The last column is a practice suggestion, not a quote from the job ads.

Requirement	Who states it	Evidence to prepare
Quickly understand the customer’s hardest problem, then build a solution	Palantir	A past case (anonymised) told from discovery to what was built
Strong coding in Python, Java or C++	Palantir	A repo you wrote yourself, with tests, that is readable
Strong Python and experience shipping production applications	Anthropic	A deployed application with real users
End-to-end ownership in a small team	Palantir	A project you did yourself, from input data to operation
Reusable technical output	Substack essay	A shared component, such as an MCP server wrapping a real API

If you come from consulting, start with the two requirements for strong coding and shipping production applications, because that is the part customer experience cannot replace. Pick a problem from a past project, anonymise it, then build it yourself in Python from start to finish: ingest the data, process it, deploy it, and get real users.

On a CV, the verbs decide which group the reader puts you in. “Advised”, “recommended” and “coordinated” are a consultant’s story. “Built”, “shipped” and “operated”, along with what is running and who uses it, are an FDE’s story. Customer experience should sit alongside those lines to give them weight, not take their place.

When reading job ads, look for three words: production, end-to-end, own. A role that talks only about workshops, configuration and customer relationships may be implementation consulting under a new name.

In interviews, ask directly: does code written during deployments get fed back into the product? The answer tells you whether you are about to join an engineering team or a services business.

The people who move successfully from consulting to FDE are probably not those who abandon their old craft entirely. They are the ones who keep their ability to understand customers and, for the first time, put what the customer needs into production with their own hands.