I had a (non-Palantir) job with a description similar to an FDE a decade and a half ago and we were just called "field engineers". It was a job done mostly by people in their early to mid 20s. The business function was there long before AI.
Aren't "solutions engineers" the same thing? Typically smart, young people who want to get into core development, doing technical, client-facing work intended to maximize spend and stickiness? That's been a thing since forever.
This language is so lame 'forward-deployed engineer' oh you mean a software consultant/application engineer?
This entire article is a joke, look at the FDE SaS flywheel diagram: 'The FDE activates the SaS flywheel and then your stock price will 10x!'
The Forward Deployed Engineer role, as envisioned by Palantir, is qualitatively different from the other roles like partner engineers or solution architects, and I think it will be critical for enterprise AI adoption. I found this blog from an ex-Palantir FDE eye-opening on the sort of work they do: https://nabeelqu.substack.com/p/reflections-on-palantir
Note that many of the hurdles they overcome are not technical, they are political, bureaucratic, and organizational. TFA overlooks this key piece.
The role seems to require a very high-agency mindset, involving navigating departmental boundaries, regulations, access controls, bureaucracies and organizational politics to break down barriers like data silos (which is critical because inability to connect to data silos has been flagged as a recurring issue for agent effectiveness.)
In a sense, they are air-dropped into potentially hostile organizational dynamics and told to achieve measurable outcomes. The military connotations are a bit much, but better than "commandos" I suppose. I suspect Palantir's moat is more than its technology, it's also an operational model based on this insight into organizational psychology.
The reason I think FDEs will be critical for AI adoption is because the true impact of AI will be in re-organizing everything around AI entirely. As has been discussed on HN umpteen times, individual productivity gains do not translate well to overall productivity gains, largely because most of the time is still spent in meetings trying to figure out what to do. I call this "Conway Overhead" after Conways Law, because it is an unavoidable cost of coordinating across large org charts.
But if one AI-assisted person can do the work of an entire team or two, things change qualitatively. Today, a big change in some other team's code entails a bunch of meetings only for them to put something on their roadmap two quarters down. Tomorrow, a couple of AI-assisted senior engineers discuss over Slack and one of them merges the PR the next day.
This is a drastic change! A linear reduction in the lower levels of the org-chart causes a super-linear reduction in the heirarchy and the corresponding overhead, because a number of roles like program managers exist purely to manage this overhead. Reorganizing things will likely require refactoring the whole org, which will require navigating cultural issues, including AI-resistance... because let's face it, this means job cuts. FDE's will soon be operating in even more hostile territories.
For the first time I think that devs get a fair warning: you work together with the customer and you are accountable and responsible for where it evolves from there.
Social skills and likability, not being shy and actually enjoy being in the spotlight as well as putting the customer in the spotlight aka selling: this is really a tough call.
I know from having had to translate between business and developers for years in order to keep my developers busy with what they wanted: developing without interference.
Scrum failed so hard in this regard.
Big 5 was always funny to meet. Body selling is the term they use internally and since devs are focused on other things, they always meet me as a tandem: manager as spokesperson plus developer.
I cut the managers off, I speak developer perfectly, and yes, they are socially awkward but technical prowess was the only thing I cared. From their perspective business dudes are weird.
So yes, this won’t take long to either receive tons of money as a - pun intended - full stack forward deployed sales professional who codes or it will evolve into the common shit show consisting of a clueless sales guy and a decent developer having to do as told.
Nevertheless I like the term insofar as it is really a warning sign.
Social skills are the hardest to learn and adapt to.
Brutal, and I mean it.
I essentially did this together with at least one lead developer for years: advertising for our platform.
I went from solo contributor to sales and marketing in 5 years.
But alone? You miss so much.
At least we know that AI didn’t destroy any of the Big 5 and the customers learned nothing. No AI was harmed to get rid of PowerPoint consultants.
Of course, Palantir's sudden jump in stock price since November 2024 could also be explained by entirely different factors that have nothing to do with engineering.
This isn't just LLM written---it's a full ontology of the phenomenology of software deployment!
"Forward deployed engineer" just sounds more military to please the clientele of Palantir. Like "forward deployed troops", they fight artificial fires that are often created by the deploying entities.
I believe the mechanism, at its core, is that engineering or anything technical is to some degree a competitive field (not as in pay, but as in having clear performance differences between who is good and who is bad). This means any newcomer will be a reason for the team to flex and prove that they don't need the consultant. Similarly, the consultant is trying to show just how much of an absolute maven he or she is.
There is an element of truth in what you say. And yet, when people actually behave that way, it often becomes toxic, which ironically makes them worth much less as either employees or consultants.
Consultants generally don't work for one specific vendor. FDE's are just "Solutions Engineers" that are sitting on-site at the customer's offices indefinitely. I don't love the moniker, but I can't think of an existing word to describe this precisely.
The big contract shops have had customer engineering for decades, and still do.
When you'd buy a $1M+ machine, the real money is in the support contract, and it doesn't take much for the support contract to come with some dude straight out of college who's job it is to sit next to it and parrot back your actual engineering team's opinions.
In my experience, Solutions Architects don't do the implementation, they provide guidance. FDEs actually build things alongside the customer engineers.
"Forward Deployed Engineering" is a Palantir-coined buzzword that is nothing but military-branded marketing fluff. Maybe it sounds 'fancy', but it simply is the same old practice of "on-site" engineers that places engineers directly within a customer’s location / infrastructure.
There’s nothing revolutionary about it other than the little spin for a standard industry role to make the sorry plantir bros feel more appreciated while helping tech-fascists destroy democracies.
This is a lot of content-free stuff but the reality is that if you’re hoping that customers will just write software to integrate with your SaaS you have to ask yourself why they wouldn’t also just write your SaaS. So either you go to them, they come to you, or you’re past some particular implementation hurdle. I think it’s better you go to them. Just reduces the barrier to entry and people will happily pay you for additional technology capacity to get a sufficiently complex thing onboarded.
So sending your implementation team out is “not just smart — it’s required” (to use everyone’s current favourite phrasing).
Pretty sure there’s some stolen valor here — forward deployed engineers are disarming IEDs, breaching fortifications, and so on.
Not snowing customers with slop.
I had a (non-Palantir) job with a description similar to an FDE a decade and a half ago and we were just called "field engineers". It was a job done mostly by people in their early to mid 20s. The business function was there long before AI.
Everything old is new again, basically.
"Professional services" was the other common term. Most big software companies had them and/or subcontracted for them.
Aren't "solutions engineers" the same thing? Typically smart, young people who want to get into core development, doing technical, client-facing work intended to maximize spend and stickiness? That's been a thing since forever.
This language is so lame 'forward-deployed engineer' oh you mean a software consultant/application engineer? This entire article is a joke, look at the FDE SaS flywheel diagram: 'The FDE activates the SaS flywheel and then your stock price will 10x!'
The Forward Deployed Engineer role, as envisioned by Palantir, is qualitatively different from the other roles like partner engineers or solution architects, and I think it will be critical for enterprise AI adoption. I found this blog from an ex-Palantir FDE eye-opening on the sort of work they do: https://nabeelqu.substack.com/p/reflections-on-palantir
Note that many of the hurdles they overcome are not technical, they are political, bureaucratic, and organizational. TFA overlooks this key piece.
The role seems to require a very high-agency mindset, involving navigating departmental boundaries, regulations, access controls, bureaucracies and organizational politics to break down barriers like data silos (which is critical because inability to connect to data silos has been flagged as a recurring issue for agent effectiveness.)
In a sense, they are air-dropped into potentially hostile organizational dynamics and told to achieve measurable outcomes. The military connotations are a bit much, but better than "commandos" I suppose. I suspect Palantir's moat is more than its technology, it's also an operational model based on this insight into organizational psychology.
The reason I think FDEs will be critical for AI adoption is because the true impact of AI will be in re-organizing everything around AI entirely. As has been discussed on HN umpteen times, individual productivity gains do not translate well to overall productivity gains, largely because most of the time is still spent in meetings trying to figure out what to do. I call this "Conway Overhead" after Conways Law, because it is an unavoidable cost of coordinating across large org charts.
But if one AI-assisted person can do the work of an entire team or two, things change qualitatively. Today, a big change in some other team's code entails a bunch of meetings only for them to put something on their roadmap two quarters down. Tomorrow, a couple of AI-assisted senior engineers discuss over Slack and one of them merges the PR the next day.
This is a drastic change! A linear reduction in the lower levels of the org-chart causes a super-linear reduction in the heirarchy and the corresponding overhead, because a number of roles like program managers exist purely to manage this overhead. Reorganizing things will likely require refactoring the whole org, which will require navigating cultural issues, including AI-resistance... because let's face it, this means job cuts. FDE's will soon be operating in even more hostile territories.
I really laughed hard.
For the first time I think that devs get a fair warning: you work together with the customer and you are accountable and responsible for where it evolves from there.
Social skills and likability, not being shy and actually enjoy being in the spotlight as well as putting the customer in the spotlight aka selling: this is really a tough call.
I know from having had to translate between business and developers for years in order to keep my developers busy with what they wanted: developing without interference.
Scrum failed so hard in this regard.
Big 5 was always funny to meet. Body selling is the term they use internally and since devs are focused on other things, they always meet me as a tandem: manager as spokesperson plus developer.
I cut the managers off, I speak developer perfectly, and yes, they are socially awkward but technical prowess was the only thing I cared. From their perspective business dudes are weird.
So yes, this won’t take long to either receive tons of money as a - pun intended - full stack forward deployed sales professional who codes or it will evolve into the common shit show consisting of a clueless sales guy and a decent developer having to do as told.
Nevertheless I like the term insofar as it is really a warning sign.
Social skills are the hardest to learn and adapt to.
Brutal, and I mean it.
I essentially did this together with at least one lead developer for years: advertising for our platform.
I went from solo contributor to sales and marketing in 5 years.
But alone? You miss so much.
At least we know that AI didn’t destroy any of the Big 5 and the customers learned nothing. No AI was harmed to get rid of PowerPoint consultants.
Sad…
Of course, Palantir's sudden jump in stock price since November 2024 could also be explained by entirely different factors that have nothing to do with engineering.
The gap is not technological. It is operational.
enough read
The slop is not just thick — it's viscous.
unserious article written by inane consultancies feeding at the trough of linkedin. The diagram itself is hideous.
Software consultant, solution architect, solutions eng, all do what an "FDE" does without having the weirdly cringe palantir branding.
This isn't just LLM written---it's a full ontology of the phenomenology of software deployment!
"Forward deployed engineer" just sounds more military to please the clientele of Palantir. Like "forward deployed troops", they fight artificial fires that are often created by the deploying entities.
I believe the mechanism, at its core, is that engineering or anything technical is to some degree a competitive field (not as in pay, but as in having clear performance differences between who is good and who is bad). This means any newcomer will be a reason for the team to flex and prove that they don't need the consultant. Similarly, the consultant is trying to show just how much of an absolute maven he or she is.
There is an element of truth in what you say. And yet, when people actually behave that way, it often becomes toxic, which ironically makes them worth much less as either employees or consultants.
"It's not {X} it's {Y}!"
I don't think a human being even proof read this before hitting publish
The FDE engineers who will do well are the engineer's-engineer, someone well-rounded, easy to work with, can communicate, and have high empathy
And if you are that kind of person, why would you want to be an FDE? (Not rhetorical, btw, I'm literally interviewing for an FDE role tomorrow.)
Here I was thinking AI Engineer is the new hotness similar to React back in the day
I'll take Infantry Engineer or something
What is the difference between a consultant with coding experience vs a FDE?
Consultants generally don't work for one specific vendor. FDE's are just "Solutions Engineers" that are sitting on-site at the customer's offices indefinitely. I don't love the moniker, but I can't think of an existing word to describe this precisely.
The big contract shops have had customer engineering for decades, and still do.
When you'd buy a $1M+ machine, the real money is in the support contract, and it doesn't take much for the support contract to come with some dude straight out of college who's job it is to sit next to it and parrot back your actual engineering team's opinions.
Palantir branding
"forward deployed engineering"
So, your old technical leads that got let go?
Forward Deployed Engineer is just a title change for Solutions Architects.
I do think it's a lot clearer title than Solutions Architect.
In my experience, Solutions Architects don't do the implementation, they provide guidance. FDEs actually build things alongside the customer engineers.
Buzzword compliant.
I can't take this article seriously when it says vibe coding is part of engineering
"Forward Deployed Engineering" is a Palantir-coined buzzword that is nothing but military-branded marketing fluff. Maybe it sounds 'fancy', but it simply is the same old practice of "on-site" engineers that places engineers directly within a customer’s location / infrastructure.
There’s nothing revolutionary about it other than the little spin for a standard industry role to make the sorry plantir bros feel more appreciated while helping tech-fascists destroy democracies.
This is a lot of content-free stuff but the reality is that if you’re hoping that customers will just write software to integrate with your SaaS you have to ask yourself why they wouldn’t also just write your SaaS. So either you go to them, they come to you, or you’re past some particular implementation hurdle. I think it’s better you go to them. Just reduces the barrier to entry and people will happily pay you for additional technology capacity to get a sufficiently complex thing onboarded.
So sending your implementation team out is “not just smart — it’s required” (to use everyone’s current favourite phrasing).
[dead]
TLDR "Please stop throwing away Ex-Palantir job applications"