I remember interviewing at Palantir back when they were making this role popular (probably a decade ago). I wanted to be an SDE and the recruiter kept pushing me towards this “forward deployed engineer” role. After hearing the pitch I went…oh so you want me to be a sales consultant? They did not take this well, I guess because Palantir was trying very hard to convince the world they were a tech unicorn and not a glorified consulting firm.
These used to be called "Sales Engineers" but Palantir wanted something more militant sounding. It's a shame others picked this gross term up and started using it.
I'm swimming against the current with this, but I think the role is really cool. Blessed by your own company to wear the vestments of an expert, and expected by the customer to deliver the sort of advice that will get a team "unstuck", a forward deployed engineer is in the perfect spot to prove just how much of a hotshot he or she is. Especially in fields like defense where the customer is staffed with teams that are highly risk averse. It's one of the few careers I get a bit jealous of, even though the burnout rate is probably pretty high.
I agree that the idea is cool, but from what I've heard from people in the role at most companies it's essentially a solutions architect role by another name.
Funny enough, the Pragmatic Engineer (author of the post linked) had a follow up from about a year after the post above and he reports the same thing.
Looking at the official description of a Forward Deployed Engineer I'm uncertain what even the nominal difference between this and a Solutions Architect is.
Is the nominal difference between an archetypal FDE and an archetypal SA greater than the difference in the SA role from company to company?
I think it is. I work for a (relatively) small company. I naturally grew from project engineer to senior/lead/sme (including pioneering tech _for my industry_) to SA. I had also stuck with my company for many years, so I have the industry connections and got to be known as a heavy hitter. That trust relationship with the customers mixed with technical know how = sales and consulting.
Again, because of the size of my company I can make my role fluid (including a good way), but call it what you will I engineer, I sell, I consult.
This job is really the stepping stone to product management - and it's the role that's going to really grow with LLMs. A mini-PM with Fable can solve tons of customer needs.
At that point what's the value add of the PM (and maybe even the consulting company entirely), if the PM is just doing doing custom stuff? How many of those can the customer solve themselves with Fable? OR the support agent at the vendor without needing to take it to a PM?
PM in this sort of company—where there's no grand unifying vision vs just responding to customer requests—is the sort of almost-entirely-paperwork role that starts looking less necessary when you can have LLMs summarize all those comms and "analysis."
I’ve done some of what I think this is, working on prem with customers, and I find it funny when I see jobs for FDEs that are somehow all in-office in San Francisco. The whole idea of being forward deployed I take to mean actually deployed.
I've done this too, just not under the official FDE title. I've never wanted to end it all so badly before. I felt like a tutor for a bunch of man-babies, who was stuck in a Groundhog Day-esque loop. Heavy breath of relief when the contract ended.
your FDEs shape your product strategy, and should be considered R&D. after making sure a customer deployment is successful (by any means necessary btw, even if it means building new systems outside of the product), the crucial next step is to drive the product improvement with PMs and core software engineers after contact with reality. this was a pretty radical idea from palantir in the era of saas
if you only do step 1 you're basically just solutions engineers / mckinsey, and if you only do step 2 with no customer learning to your product you don't improve your platform for all the other customers. the pain becomes the moat
There's a reason why this echelon of companies comp FDEs much, much more than services businesses is because you're trying to find engineering + product + customer facing in one (knew people making 200k+ 5 years ago as new grad FDEs, and the same flavour at the labs is 500k+ easy)
that being said the role has evolved a lot over the years, and depending on the company it could be indistinguishable from solutions eng, or sales eng, or even dev rel. I do recommend people on HN work at one of the elite FDE shops first before commenting though!
My understanding is Palantir used the term, and calling teams of them "Delta Force" to make a consultative-and-service-heavy software adoption cycle make sense to US Military clients.
They used the phonetic alphabet to categorize a number of different specialties on the BD team, including alpha bravo delta and echo. I never heard the phrase "Delta Force" used in 8 years there 2008-2016.
Palantir is also the kind of business where every engagement is somewhat to totally bespoke. That's a big departure from a more typical SaaS model where you focus on providing a platform that your customers build on top of with a more generic set of tools.
I am curious whether this FDE direction will result in more product and platform complexity that is more difficult to unwind.
to put it in simple terms, these are people who are so good at both usage/integration of the entire product and can help the company's clients to integrate the product seamlessly into their stack. We've seen this in rise, especially OpenAI engineers having office hours inside Nvidia's campus, etc.
As building becomes more and more easier, the value of pure swe goes down. I feel the only way to thrive in this environment is either a specialized engineer or a fde.
>FDEs are sometimes mistakenly thought of as consultants, but the difference between consultants and FDEs is that the former make one-off recommendations, whereas FDEs generally work with customers, long-term.
Id say the main difference is FDEs post-engagement need to drive product strategy back into the platform (non trivial ask)
you typically see FDE-driven companies' products be 'assembly' driven and very deep into integration, as they figure out the optimal primitives that assemble into the shapes required to solve new customer problems
The distinction really kinda depends on the situation.
FDEs have been around for a long time in the defense contractor space and Palantir picked up the term, broadening the meaning a decent bit. Then it spread to the rest of the software/tech space.
Historically FDEs in defense are engineers who would literally forward deploy out to other countries where the hardware was being deployed so that they could provide on the ground hardware and software support. They'd either literally be called FDEs, Engineer (forward deployed), field engineer, or some other title that roughly got the meaning across.
You'd deploy some platform and send along an engineer or two and a few technicians. Depending on the platform or the scale of the deployment the engineers would either be normal engineers forward deploying for a few months to a year or so or you'd hire a dedicated FDE for that given deployment/site.
AFAICT it became a lot less common as internet communications got better and you could do practical remote debugging and live video conferencing but you still see FDE roles in the traditional sense from time to time.
But yeah then Palantir and big tech came along and basically rendered it into a glorified consultant and/or systems integrator role.
The funny thing is I’ve worked at/worked with a ton of big tech companies (including FAANGs) where the most tenured people on some teams are external consultants.
> even if "long-term" was an important distinction, the term FDE itself became popular a very short time ago!!! [] so how can you assert FDEs work with customers for the long-term
That's pretty straightforward; even if the role came to exist two months ago, you can still have signed a five-year service contract.
This term is so eye rolling. Unless the FDE has legitimized pull within the core product team they are nothing more than a glorified field engineer/technical consultant.
I saw those comments and thought that too, but in Field Engineer and software consultant communities as well as Sales Engineering communities and Solutions engineering communities, there is a lack of relatability into the actual tasks because what Forward Deployed Engineers are expected to do is different enough
and on the other side, the companies hiring for them are figuring it out on the fly. It's mostly an engineer embedded in a 'fleet' of sales people to add legitimacy to them, and also accepting that a full software engineering team isn't necessary any more
and there often is pull within those company's client organizations
overall, a field engineer that's ai assisted specifically to make ai automation software could overlap completely with what FDE's are doing. FDE is associated with that specifically as opposed to any other kind of software, so language exists to convey a shared concept and the term fulfills that
TL;DR: Glorified contract role for integrating your employer's APIs with enterprise customers. Like working with mckinsey vibe PMs and being sold on fat margins you'll see none of? Perfect!
Every company I have seen implements more or less the exact same stack, with a few small variations. The problem is that it is often not very good and is usually months, if not years, behind. I have already seen this in several places, including a few F250 companies.
Frankly, it is a waste of time. It is expensive to build, expensive to maintain going forward, and often already dated by the time it is finished because things have moved on.
Also, as much as I like code, and would personally prefer to build things in code, a lot of internal innovation happens because end users have access to agentic tools. Yet, from the outset, both OpenAI and Anthropic FDE approaches seem heavily code-driven. I might be mistaken.
In my opinion, it is much better to deploy a more customisable harness that sits across the different technology stacks that is also user-friendly. But then I am biased, because that is what we do, so take this comment as you will.
I remember interviewing at Palantir back when they were making this role popular (probably a decade ago). I wanted to be an SDE and the recruiter kept pushing me towards this “forward deployed engineer” role. After hearing the pitch I went…oh so you want me to be a sales consultant? They did not take this well, I guess because Palantir was trying very hard to convince the world they were a tech unicorn and not a glorified consulting firm.
These used to be called "Sales Engineers" but Palantir wanted something more militant sounding. It's a shame others picked this gross term up and started using it.
I'm swimming against the current with this, but I think the role is really cool. Blessed by your own company to wear the vestments of an expert, and expected by the customer to deliver the sort of advice that will get a team "unstuck", a forward deployed engineer is in the perfect spot to prove just how much of a hotshot he or she is. Especially in fields like defense where the customer is staffed with teams that are highly risk averse. It's one of the few careers I get a bit jealous of, even though the burnout rate is probably pretty high.
I agree that the idea is cool, but from what I've heard from people in the role at most companies it's essentially a solutions architect role by another name.
Funny enough, the Pragmatic Engineer (author of the post linked) had a follow up from about a year after the post above and he reports the same thing.
https://blog.pragmaticengineer.com/the-pulse-forward-deploye...
Looking at the official description of a Forward Deployed Engineer I'm uncertain what even the nominal difference between this and a Solutions Architect is.
Is the nominal difference between an archetypal FDE and an archetypal SA greater than the difference in the SA role from company to company?
I think it is. I work for a (relatively) small company. I naturally grew from project engineer to senior/lead/sme (including pioneering tech _for my industry_) to SA. I had also stuck with my company for many years, so I have the industry connections and got to be known as a heavy hitter. That trust relationship with the customers mixed with technical know how = sales and consulting.
Again, because of the size of my company I can make my role fluid (including a good way), but call it what you will I engineer, I sell, I consult.
It's looking like the answer is no. They're the same within the bounds of ordinary differences in the role between companies.
If you hear a pitch from McKinsey about being a consultant it will also sound like the coolest job in the world.
This job is really the stepping stone to product management - and it's the role that's going to really grow with LLMs. A mini-PM with Fable can solve tons of customer needs.
At that point what's the value add of the PM (and maybe even the consulting company entirely), if the PM is just doing doing custom stuff? How many of those can the customer solve themselves with Fable? OR the support agent at the vendor without needing to take it to a PM?
PM in this sort of company—where there's no grand unifying vision vs just responding to customer requests—is the sort of almost-entirely-paperwork role that starts looking less necessary when you can have LLMs summarize all those comms and "analysis."
LLMs don't really have anything to do with this, other than LLMs being useful for pretty much any (tech) role.
If fable can solve the customer’s needs then why is the PM needed at all?
Pressing needs like AI responses to questions on HN to promote themselves.
What’s a mini-PM? Something Apple offers?
I’ve done some of what I think this is, working on prem with customers, and I find it funny when I see jobs for FDEs that are somehow all in-office in San Francisco. The whole idea of being forward deployed I take to mean actually deployed.
I've done this too, just not under the official FDE title. I've never wanted to end it all so badly before. I felt like a tutor for a bunch of man-babies, who was stuck in a Groundhog Day-esque loop. Heavy breath of relief when the contract ended.
If you are not issued body armor and K&R insurance FDE seems like the wrong term. (the use of "engineer" for non-PEs is... a fair debate)
the customers are also in san Francisco?
the main distinction i like to make is:
your FDEs shape your product strategy, and should be considered R&D. after making sure a customer deployment is successful (by any means necessary btw, even if it means building new systems outside of the product), the crucial next step is to drive the product improvement with PMs and core software engineers after contact with reality. this was a pretty radical idea from palantir in the era of saas
if you only do step 1 you're basically just solutions engineers / mckinsey, and if you only do step 2 with no customer learning to your product you don't improve your platform for all the other customers. the pain becomes the moat
There's a reason why this echelon of companies comp FDEs much, much more than services businesses is because you're trying to find engineering + product + customer facing in one (knew people making 200k+ 5 years ago as new grad FDEs, and the same flavour at the labs is 500k+ easy)
that being said the role has evolved a lot over the years, and depending on the company it could be indistinguishable from solutions eng, or sales eng, or even dev rel. I do recommend people on HN work at one of the elite FDE shops first before commenting though!
My understanding is Palantir used the term, and calling teams of them "Delta Force" to make a consultative-and-service-heavy software adoption cycle make sense to US Military clients.
No.
They used the phonetic alphabet to categorize a number of different specialties on the BD team, including alpha bravo delta and echo. I never heard the phrase "Delta Force" used in 8 years there 2008-2016.
Palantir is also the kind of business where every engagement is somewhat to totally bespoke. That's a big departure from a more typical SaaS model where you focus on providing a platform that your customers build on top of with a more generic set of tools.
I am curious whether this FDE direction will result in more product and platform complexity that is more difficult to unwind.
It's just a repackaging of the same old consultant class. Nothing wrong with it unless you want to be mad about semantics.
Back in the lat 90s we called ourselves a "Strike Team".
to put it in simple terms, these are people who are so good at both usage/integration of the entire product and can help the company's clients to integrate the product seamlessly into their stack. We've seen this in rise, especially OpenAI engineers having office hours inside Nvidia's campus, etc.
As building becomes more and more easier, the value of pure swe goes down. I feel the only way to thrive in this environment is either a specialized engineer or a fde.
Is it similar to Facebook’s Production Engineer role or Google’s SRE role?
No, it's a sales engineer/field engineer role borrowing military nomenclature because marketing
>FDEs are sometimes mistakenly thought of as consultants, but the difference between consultants and FDEs is that the former make one-off recommendations, whereas FDEs generally work with customers, long-term.
...sounds like a consultant to me!
Also, even if "long-term" was an important distinction, the term FDE itself became popular a very short time ago!!! https://trends.google.com/trends/explore?date=all&geo=US&q=f... so how can you assert FDEs work with customers for the long-term
Id say the main difference is FDEs post-engagement need to drive product strategy back into the platform (non trivial ask)
you typically see FDE-driven companies' products be 'assembly' driven and very deep into integration, as they figure out the optimal primitives that assemble into the shapes required to solve new customer problems
The distinction really kinda depends on the situation.
FDEs have been around for a long time in the defense contractor space and Palantir picked up the term, broadening the meaning a decent bit. Then it spread to the rest of the software/tech space.
Historically FDEs in defense are engineers who would literally forward deploy out to other countries where the hardware was being deployed so that they could provide on the ground hardware and software support. They'd either literally be called FDEs, Engineer (forward deployed), field engineer, or some other title that roughly got the meaning across.
You'd deploy some platform and send along an engineer or two and a few technicians. Depending on the platform or the scale of the deployment the engineers would either be normal engineers forward deploying for a few months to a year or so or you'd hire a dedicated FDE for that given deployment/site.
AFAICT it became a lot less common as internet communications got better and you could do practical remote debugging and live video conferencing but you still see FDE roles in the traditional sense from time to time.
But yeah then Palantir and big tech came along and basically rendered it into a glorified consultant and/or systems integrator role.
The funny thing is I’ve worked at/worked with a ton of big tech companies (including FAANGs) where the most tenured people on some teams are external consultants.
In the automotive industry it's not uncommon for contracts to require an on-site engineer, basically FDE.
I've always heard the term "field applications engineer" for the consultants the vendor supplies to integrate their product.
> FDEs generally work with customers, long-term.
In these days of mass layoffs every month, talking about "long-term" sounds like a cruel joke.
A consulting I used to work at started calling their engineers this. All of them. They just follow trends.
So much of everything is doing this (following trends)... It's a bit depressing really...
> even if "long-term" was an important distinction, the term FDE itself became popular a very short time ago!!! [] so how can you assert FDEs work with customers for the long-term
That's pretty straightforward; even if the role came to exist two months ago, you can still have signed a five-year service contract.
We have sales engineers at home.
Those might be called "Field Application Engineers" in some places.
Forward Deployed Financial Transaction Enablement Engineers
This term is so eye rolling. Unless the FDE has legitimized pull within the core product team they are nothing more than a glorified field engineer/technical consultant.
most companies will make the FDE role but not understand the value of the FDE org, which is to drive product strategy and function as R&D
I saw those comments and thought that too, but in Field Engineer and software consultant communities as well as Sales Engineering communities and Solutions engineering communities, there is a lack of relatability into the actual tasks because what Forward Deployed Engineers are expected to do is different enough
and on the other side, the companies hiring for them are figuring it out on the fly. It's mostly an engineer embedded in a 'fleet' of sales people to add legitimacy to them, and also accepting that a full software engineering team isn't necessary any more
and there often is pull within those company's client organizations
overall, a field engineer that's ai assisted specifically to make ai automation software could overlap completely with what FDE's are doing. FDE is associated with that specifically as opposed to any other kind of software, so language exists to convey a shared concept and the term fulfills that
TL;DR: Glorified contract role for integrating your employer's APIs with enterprise customers. Like working with mckinsey vibe PMs and being sold on fat margins you'll see none of? Perfect!
(2025)
Interesting choice of name for a website which contains no actual engineering.
Every company I have seen implements more or less the exact same stack, with a few small variations. The problem is that it is often not very good and is usually months, if not years, behind. I have already seen this in several places, including a few F250 companies.
Frankly, it is a waste of time. It is expensive to build, expensive to maintain going forward, and often already dated by the time it is finished because things have moved on.
Also, as much as I like code, and would personally prefer to build things in code, a lot of internal innovation happens because end users have access to agentic tools. Yet, from the outset, both OpenAI and Anthropic FDE approaches seem heavily code-driven. I might be mistaken.
In my opinion, it is much better to deploy a more customisable harness that sits across the different technology stacks that is also user-friendly. But then I am biased, because that is what we do, so take this comment as you will.