What separates an FDE from a consultant is not speed but where the lessons go

Palantir once turned down deals it called “Accenture-with-better-software”. A company that makes its living by sending engineers to work directly with customers said no to deals that, at a glance, looked exactly like what it already did. According to one analysis of Palantir’s FDE playbook, this was how the company set itself apart from the “consultant mould”.

If you are thinking of moving into an FDE role, the question “is FDE just consulting dressed up as engineering?” is not a matter of semantics. It decides what you will have to show for yourself after two years: a list of handed-over projects, or a piece of a product that bears your fingerprints. The honest answer is that it depends on where the lessons from what you build end up.

The arguments for FDE are weaker than they look

Advocates of FDE usually start with speed. An opinion piece in SD Times describes traditional implementation projects as often taking months, sometimes years, to bring a solution to market, whereas FDEs excel at delivering value within weeks with production-ready products.

The author adds a point about taste in technology: consultants tend to choose proven solutions over the newest options.

But speed and taste in technology describe people, not a model. A consultant who moves fast and likes trying new tools does not thereby become an FDE. The SD Times author concedes as much when discussing the habit of looking at the whole problem: traditional implementation consultants do that too.

The piece concludes that FDEs complement consultants, filling the gaps where consultants are weaker, rather than replacing them.

The second argument is stronger: accountability. FDE Academy, a business that supplies FDE talent, draws the line neatly: a technical consultant advises and hands over; an FDE builds and owns the outcome. A consultant’s deliverable, in its view, is a recommendation, a roadmap or a design, not a running system.

The argument is worth remembering, but so is who is making it. This is a source that sells FDEs, so “owning the outcome” is both a description and a sales pitch. And if the test stops at “builds working systems instead of writing documents”, a good systems integrator passes it too. The real line has to lie elsewhere.

The real line: where the lessons flow

Go back to Palantir. The analysis of its playbook identifies the most important structural point: at Palantir, FDEs are the primary input channel for product management. Not one channel among many. The primary one. What engineers learn while working with customers does not stay with that customer; it flows back to shape the product.

A Palantir insider quoted by Cloud Authority puts it more bluntly: the FDE model is a product development strategy that only looks like services from the outside. Oxagile, an engineering services firm, calls treating it as a consulting role one of the biggest misconceptions, and stresses that FDEs at Palantir are software engineers.

Seen this way, the refusal of “Accenture-with-better-software” makes sense. By that logic, such a deal generates services revenue but no product. Engineers finish, hand over and move to the next customer, and the company is no richer in product terms. That is consulting, even if the people doing it write code eight hours a day.

FDE Academy has a line that frames the same idea differently: FDEs close the gap between strategy and execution because strategy emerges from building. In consulting, strategy is the deliverable and execution is someone else’s job. In a true FDE role, you build first, and what you build teaches the company what product to make next.

But many FDE roles today really are consulting

The Palantir model is an ideal; the job market does not necessarily copy it faithfully. As daily.dev summarises the May 2026 issue of Gergely Orosz’s The Pragmatic Engineer, the modern FDE role at AI labs is, in essence, a consultant or solutions architect role.

Both things can be true. Palantir-style FDE work is not consulting, because it is a product engine. And many jobs carrying the FDE title today, by that assessment, remain close to consulting.

It is easy to see why: if an employer has no mechanism for carrying customer lessons back to the product team, then whatever the title, the work stops at deploying for the customer. Same title, different job.

So the question to ask is not “is FDE consulting?” but “is this FDE role consulting?”. The table below turns the signals from the arguments above into questions you can use in your next interview.

Signal	Consulting dressed as engineering	True FDE	Question to test it
Deliverable	Recommendations, roadmap, design, or a system handed over before leaving	A system running in production, with continued ownership	“After go-live, who is on call for this system?”
Where lessons flow	They stay with the customer; each project starts from scratch	Back to the product team, shaping the roadmap	“Which feature in the product originated with an FDE?”
Relationship with PM	Takes requirements, rarely pushes back	Is the primary input channel for product	“How often do FDEs meet the product team?”
Deals the company takes	Anything a customer will pay for	Turns down deals that produce no product	“Which deal has the company turned down recently, and why?”

The last column is the most useful. Treat it as a rule of thumb, not a verdict: a company that can answer “which feature came from an FDE” with specifics is likely to have the kind of feedback loop into product that Palantir describes.

A company that fumbles that question is showing a warning sign that the role may be closer to consulting than its name suggests.

Choose which FDE role, not whether to be an FDE

If you have two to eight years of experience and are aiming for FDE, prepare for both scenarios: an FDE role that is really consulting, and a true FDE role where lessons flow back to the product. If you have the choice, aim for the second.

The two scenarios demand largely the same skills, if the descriptions above are to be believed: building production-ready products within weeks, and owning the outcome rather than handing over and walking away.

The difference lies in what you bring back.

On your CV, do not just list “deployed solution for customer X”. Spell out what the lessons from that deployment changed in the product or in how your team works.

A line such as “spotted a recurring pattern across three customers, proposed it and built it into a shared module” tells a hiring manager that you understand FDE as a product engine, not a construction crew.

When reading job descriptions, look for phrases that point backwards: “feed back into product”, “shape roadmap”, “work with product team”. If a JD talks only about onboarding, integration and customer success without mentioning the product, treat that as a warning sign: the role is likely closer to consulting, whatever the title says.

There is nothing wrong with consulting; you just need to know what you are choosing.

To practise in your current job: every time you finish something for an internal “customer”, write down one thing the product should change because of it.

The habit trains exactly the mechanism that, according to the Palantir analysis, separates FDE from consulting: each deployment becomes a piece of input for the product instead of ending at handover.

Why did Palantir say no to “Accenture-with-better-software” deals? When FDEs are the primary input channel for the product, the most reasonable reading is that a deal which brings nothing back to the product is not worth doing. Use the same test when choosing your next FDE role.