Rise of the Forward Deployed Engineer
hfsresearch.comI 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.
Yeah. I've also seen Customer Success.
Customer Success is not engineering, or anything close to it. It's not even really technical.
There are Customer Success engineers. Any of the terms in this thread were full service teams comprised of engineers, product managers, business analysts and whatever else was needed (or could be sold).
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!'
"Technical sales engineer", in cisco speak ...
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.
The gap is not technological. It is operational.
enough read
The slop is not just thick — it's viscous.
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…
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.
Here is how I see it. Imagine you're an old fashioned Police Precinct. You're thinking of building a K9 unit. The FDE in this article, is a K9 officer, who will come along with a puppy shepherd(ai agents), and stay at your precinct until the puppy is ready for his first patrol. The ideal scenario, is for your precinct, to equip some of your officers with puppies(ai agents), and mirror the FDE. Guys, this is literally a rehash of SAP deployments. You guys remember those? A team of outsiders would come in and transition your workflow and processes to SAP. In this case, it's more like a traffic controller equipped with ai agents to assist him with the toil, and he serves as "human-in-the-middle".
"forward deployed engineering"
So, your old technical leads that got let go?
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 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.
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
Forward Deployed Engineer is just a title change for Solutions Architects.
In my experience, Solutions Architects don't do the implementation, they provide guidance. FDEs actually build things alongside the customer engineers.
I do think it's a lot clearer title than Solutions Architect.
"It's not {X} it's {Y}!"
I don't think a human being even proof read this before hitting publish
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
Buzzword compliant.
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 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).
TLDR "Please stop throwing away Ex-Palantir job applications"