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.
The FDE is really the consolidation of two existing roles: solutions architect and engineer.
In the old days, sales would close a client with the help of someone in technical sales and a solutions architect that would come up with a high level spec for a solution. That spec would be fleshed out post sales and then given to an engineer to develop.
Today the FDE often does both.
The difference between Palantir and pure consulting is that Palantir has a core software platform that they customize per client. The business model is more akin to IBM or SAP products.
This is the *intended* difference. As with all of these new terms, it's quickly becoming co-opted and winds up being the case that most companies using it treat it no different than the old term.
Yeah, I'm reading this and find myself wondering what's so new about this. Haven't tech companies always had this role? I suppose Forward Deployed Engineer sounds more like an engineering role than Sales Consultant, which sounds like you're a salesman rather than an engineer, so it feels to me like this is mostly PR to make the role more attractive to engineers.
It's certainly working on me, because I like talking with stakeholders and identifying problems I can solve, and I don't like sales. I'm far more likely to apply as Forward Deployed Engineer.
Orwellian speak for ... you won't get paid like our base engineers and when we want to get rid of you, we send you to our Siberian customer because you are a forward deployed engineer haha
Still i want to believe i'm wrong and it's a good job.
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.
Sales engineers are pre-sale, FDE are both pre- and post-sale. FDEs are also much more involved in the client implementation, often they are the ones actually doing all the work, specially in government bureaucracies or large ossified corporations where no one there actually knows how to get things done.
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?
The skillset is different. SAs everywhere I’ve worked are solidly salespeople. They can do AE work in a pinch, they use Salesforce, they know how to understand the state of an account, etc. They tend to be more limited technically and as such are generally deployed for the sale of a product which is “finished”, and as such spend most of their time mapping customers onto existing patterns that are already known to work, and identifying those patterns.
FDEs are different in that they’re deployed to sell and integrate products which are unfinished in some way. For example Palantir sold a fairly low-level generalized product which required bespoke technical work to integrate with a customer. This integration work is more like normal engineering work in that lots of code may have to be written and there’s technical creativity required. The reason why FDE is increasingly in vogue now is because AI companies haven’t yet found a high-level product shape which is generalizable across many customers, because the market is immature and customers probably don’t know what they want. So there’s lots of engineering work required to take a lower-level offering (e.g some sort of agent) and figure out how to use it to generate value for one particular customer.
Based on what I first heard it described as, yeah, I think so.
In most places I've worked SAs are generally just connecting existing pieces of a system together to meet a customers needs. They may write code, but it's often just glue to connect two bits of the system together or transform some data or something like that. They're not really contributing to the underlying product, they're just using the product and some custom code to meet a specific customer's needs.
An FDE is supposed to be closer to a regular software engineer on a product or platform team in that their goal is to solve a specific customers problem, but they're supposed to be more focused on the big picture and using their learnings to build a better product. They're still using existing systems to solve problems and writing plenty of glue code, but they're also supposed to have the leeway to contribute to the underlying product to make it better for all customers.
The simplest example I can think of would be something like a customer saying something like they need a way to convert a bunch of their data to a CSV and then send that to a certain email address every Friday. A more traditional SA mindset may be to write a Python script that runs on a cron that connects to that customers DB pulls the data, converts it to CSV, and then emails that specific email address. Even if the SA knows that's not the best way to do it, it's the tools they've been given to work work. A FDE should have the leeway and skills to go talk to a PM and their engineering team and just build an in product, self serve tool to do that (assuming everyone is aligned that that is good for the product).
Again though, what I've heard is that most FDEs at most companies are just SAs by another name.
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.
If I did that to the best of my ability, I’d want to be a boss and not a chump. The real question is how do they actually reward the people who excel in this role, and do they really recognize who’s delivering or do they look at gamey metrics and pedigree. These are important questions for the EV calculation
As a professed "hacker tourist" I've been rewarded with the trust and respect not to set myself or my coworkers on fire, in cultures which didn't see a lot of outsiders. Several times I've threatened to quit within the first month if things didn't change; one time I walked in the door, turned around and walked out. Once I paid for my own plane ticket for the interview, and didn't come home to visit for two months (worked there for six). Pay has been ok, but not stellar. Duration has been three to nine months. (I've been a licensed business since 1984.)
I basically did this for a couple years around 33. I was the highest paid IC for a multi billion dollar "digital transformation". I was writing code in 5+ languages, doing hardware retrofits, had r/w access to every system, climbing ladders to deploy hardware for my own skunkworks projects.
The whole thing was crazy. I mean actually insane. I look at my productivity from the time period and it blows me away.
Really enjoyed it. Being the one guy who was damned adamant I wouldn't manage anyone kept me out of the political fray as well. I drank and I knew things. I probably had more freedom and access than anyone ever has had at a company that size, I mean they literally ended up paying for me to have some degree of DHS clearance to operate unrestricted in passport zones, it was wild.
Is it good for a company to have those roles or not? I don't know, after starting several companies and also working in corporate, that was the most fun I think I've had. Moving the needle, unfucking things, reducing complexity.
Providing accountability where there was none before.
I left because they wanted to me to move. I was flown out every Monday and flew back every Friday but I didn't want to move cities and I had a startup I wanted to launch. I took 3 months traveling and then 2 months writing code for my 4th startup.
There are _almost_ no universal rules, my work saved them an insane amount of money and generated even more, but the methods only made sense to dig them out of the completely unaccountable traffic jam they had built for themselves.
If you ever read the James Bond books as a kid, there is inner monologue explaining why he is so overt, his whole modus operandi is to be conspicuous and to shake things loose in opaque situations. When your works starts holding peoples feet to the fire you have to come extremely correct and it paints a target on your back until you have sufficient track record. It helped me learn a lot about myself and ultimately taking the time to inhabit the role fully and lose myself in it helped me understand what I really value.
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.
Edit: I guess I'm not surprised to see the downvotes on this; I get that a lot of people on HN don't really understand product management, or don't value it. The path from engineering to product management can really start with getting closer to the customer - putting more time into understanding their needs.
The reason this shifts a lot with LLMs is that a sales engineer / forward deployed engineer can tackle customer needs much more quickly with Claude Code than they could have themselves, which means these feedback loops can become a crash course in customer experimentation and understanding.
Teresa Torres wrote an amazing book about continuous discovery that I use with my teams (https://www.producttalk.org/continuous-discovery-habits/), and a third of the book is about talking to your customers every week if you can. Someone in a customer facing role who can also build code has a huge leg up compared to someone coming at product from an academic setting. Case studies in an MBA are great for strategy, but they're usually fixed points in time. Getting that nimble feedback to hone your product sense is the hardest part of getting good.
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 edited my comment to make my point more clear, since I think a lot of folks don't know what a PM does.
If your PM isn't defining a clear strategy, your PM is probably inexperienced and/or overloaded. It sounds like you might have experiences like that.
I think a good PM needs three big skillsets: Customer discovery, Strategic planning, and leadership alignment. The second and third are easier to learn academically. This kind of role is ideal for learning the first.
The PM’s job in this situation is to articulate some sort of high level strategy generalizable across customers, based on information gathered from customers, which includes feature requests but is more than just that.
Well for full disclosure, I lead a team of forward deployed engineers at a database company. The role typically means that our engineers are embedded within the customer for extended period of times, and they work on basically devops, software engineering + some more traditional solution architecting, which is basically what the article describes.
They use LLMs in similar ways that regular engineers use. This is an engineering role, not a product / project management role. I don’t think this role is anything super special that will be revolutionized in any different way than that other engineering roles are affected.
In the end their value add is that they’re both embedded within the customer’s and our company, they’re our eyes and ears within the customer. Their purpose is not to make sales demos, their purpose is to make our software actually work properly for the customer’s needs.
I'm saying giving an FDE the ability to significantly modify code for customer needs using a powerful frontier model will make their job more about customer discovery and strategy than about engineering, a big shift of ratio of where they spend their time. It will make the feedback loops tighter, let them experiment faster.
In East Asia, 'SI' is looked down upon, but one of the strengths often mentioned about SI is understanding the client's business, that is, the domain. It's true that in the industry, which is based on job-hopping and career building, it gets a lot of criticism. But from a startup perspective, it's often evaluated positively as having strong business insight. So I think your opinion is valid.
In fact, from what I've observed on HN, most people seem to be obsessed with 'programming purity' rather than 'product cycles.'
When you're doing product-focused or delivery-oriented development, there are inevitably black boxes you don't understand, points you can't control, and product management isn't about 'perfection.' It's about whether you can get fast feedback from customers and iterate. But here, it seems like most people assume that everything should be ideally perfect.
I agree with your opinion. Because if you go to the field rather than just dealing with services, you can clearly see how imperfect domain modeling really is. If a business is large enough, you can reshape the domain with capital power to fit your service, but as you know, most of the time when you go on-site, there's a conflict between an imperfect domain, most clients don't really know their own requirements, and implementation capabilities.
Actually, I think your post is more high-level. Don't worry too much about the downvotes.
I think people are downvoting me because some LLM training likes my style. ;)
And thank you! It is higher level. I'm not worried about product management as a field at all now, because software engineers will have more trouble upleveling their thinking to the business than product managers will building high quality software with an LLM.
In the semiconductor industry this role is called Field Application Engineer. They do serious work, not just slideware, as your chip probably ships with drivers that were designed months or years before you could get significant time from the customers engineers (which generally only happens after you manufacture, but you need software to prove it works well before that). So these guys are the ones who adapt it, and their feedback is valuable as they are the ones who build understanding of the customer.
However, at my old employer they didn't get commit rights to the main software repos. They had to carry around a bunch of patches which were gradually cleaned up and integrated. As I didn't directly work with them, I don't know if this says more about them or the guys managing the internal development.
It's a role that fits a different personality to that typical among software engineers. If you're bored as a dev it may suit. Pointless to try to shoehorn people into the role that don't suit it 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.
This is useful context, but given that you're saying "delta" was in use over a decade ago and that you don't have any firsthand knowledge in the time since, it seems at least a little presumptuous to confidently asset that people didn't start colloquially saying "force" afterwards.
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.
I've been a Forward Deployed Engineer practically speaking, and properly construed the title correlates well with the personal sobriquet "hacker tourist". I've been to Prudhoe Bay, places I won't name here; factories; other things which were basically factories but maybe you wouldn't realize this from the outside. I've done some odd remote contracts, such as hunting medical devices on hospital networks (they're like SCADA, but without the Purdue Model).
I've bridged between the customer's technical team and the vendor / provider's technical staff... when there was vendor technical staff. Other times it's been more like a treasure hunt or something (sometimes there are real bad guys) and I've been there to bridge a gap between broader industry knowledge and the onsite technical team.
I'm getting pings from recruiters based in the Bay Area about "forward deployed engineers" in SF metro. It's not one of the labs, there are no mech or electrical engineers, nothing is going to escape, catch fire, or explode, nor is the inventory heavily guarded. It is bullshit; a con, so you won't notice you're being asked to establish nexus in CA.
I'm tired of flying (although if you need me to literally parachute or rappel in, I'm getting a little old but we can talk), but I'm happy to drive anywhere in the greater Pac NW (no more than two days out from Puget Sound metro).
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 put something similar another comment. What you describe is a tough job that requires dedication and the ability to objectively differentiate yourself through your work across multiple disciplines. I’ll copy it here:
“The real question is how do they actually reward the people who excel in this role, and do they really recognize who’s delivering or do they look at gamey metrics and pedigree”
I worked at a technical consultant out of college and it was a lot of the first category but often my small team did step 2. Yet it was never promoted by the larger corporate hierarchy because the incentives were not there. I would love to a job like this because I’m so nerdy but also charismatic and have perspective. Knowing myself and how dedicated I would be, I wouldn’t take anything less than 250kz
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.
In this AI era, we would also require a new role named "Backward Stability Engineer" whose job would be the exact opposite of FDE. The core of this role would be to defend from modern AI slop code updates, 0 downtime integrations, deterministic automation etc. Fusing LLM with Legacy systems will be their art.
>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.
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.
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
> 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.
> That's pretty straightforward; even if the role came to exist two months ago, you can still have signed a five-year service contract
Does the contract require that keep the same person "forward-deployed" with them the whole time? If not, then it's pretty presumptuous to claim that we know they'll be there in the long term because of the contract, and if so...that's some pretty incredible job security!
Tech is becoming from a margins heaven to the worst of all worlds. Super high capex (like manufacturing) in addition to headcount requirements for each additional customer (like consulting).
In East Asia, there's a role called 'SI' (Systems Integration), but it's rarely recognized as proper career experience. It seems to be different in the West. The reason it's hard to get career recognition is that every company uses different stacks, so you're expected to know a lot of different technologies, but it's hard to go deep in any of them. And the company-specific technologies don't help when you change jobs, so you're effectively treated as bottom-tier. That's what I do for a living too.
In fact, most hardware manufacturers stick with legacy technologies for 'stability' reasons, but that experience is rarely recognized as valuable career capital
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.
Some skill overlap but that's it. I was incredibly surprised to find what I thought was a Site Reliability Engineer role was actually 'forward deployed'. I've taken to calling it Sales Recovery Engineering (lol), or realistically, consulting while someone else negotiates, enjoying less freedom/compensation and completing extra work.
In fewer words: people want you to think so, but not really. I'd argue FDE is a change for the worse (as an employee). Less about managing your direction/service, and instead, customers.
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.
In the classic FDE model palantir pioneered, one of the main features was that you would use your learnings from one customer and integrate that back into your in house product, so that similar customers are serviced for cheaper later on.
With AI coding agents FDEs are now everywhere. One because they can demand a higher salary due to simply doing more due to AI. And two, because AI really accelerates the whole bespoke solution implementation thing. However, from what I hear, none of the actual "integrate that back into your in house platform" stuff is actually happening. So it's a tiny bit of a farce.
It’s just a field engineer but with a more military-sounding name in order to attract the worst bros. A job that has existed since the 60s in computing and likely long before 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!
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
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.
The FDE is really the consolidation of two existing roles: solutions architect and engineer.
In the old days, sales would close a client with the help of someone in technical sales and a solutions architect that would come up with a high level spec for a solution. That spec would be fleshed out post sales and then given to an engineer to develop.
Today the FDE often does both.
The difference between Palantir and pure consulting is that Palantir has a core software platform that they customize per client. The business model is more akin to IBM or SAP products.
This is the *intended* difference. As with all of these new terms, it's quickly becoming co-opted and winds up being the case that most companies using it treat it no different than the old term.
Yeah, I'm reading this and find myself wondering what's so new about this. Haven't tech companies always had this role? I suppose Forward Deployed Engineer sounds more like an engineering role than Sales Consultant, which sounds like you're a salesman rather than an engineer, so it feels to me like this is mostly PR to make the role more attractive to engineers.
It's certainly working on me, because I like talking with stakeholders and identifying problems I can solve, and I don't like sales. I'm far more likely to apply as Forward Deployed Engineer.
I think an FDE is a post sales thing. It’s basically the sale has been done and as a company you don’t have enough expertise to scale what you bought.
If you are sales then you get a (hopefully fat) sales commission.
If you are forward deployed then you get deployed forward (away from comfortable home office).
Orwellian speak for ... you won't get paid like our base engineers and when we want to get rid of you, we send you to our Siberian customer because you are a forward deployed engineer haha
Still i want to believe i'm wrong and it's a good job.
It's a well-paying job, but probably poison to your future career development, much as SRE or QA roles are, because you are now pigeonholed.
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.
Sales engineers are pre-sale, FDE are both pre- and post-sale. FDEs are also much more involved in the client implementation, often they are the ones actually doing all the work, specially in government bureaucracies or large ossified corporations where no one there actually knows how to get things done.
Sales engineers do post-sales work. Typically if they're going to do a significant amount of real work, they'd just be called "consultants".
Used to? Are you implying that the term “Sales Engineers” does not exist anymore?
They used to be called "Sales Engineers". They still are, but they used to, too.
Palantir used to call them that and no longer do.
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?
The skillset is different. SAs everywhere I’ve worked are solidly salespeople. They can do AE work in a pinch, they use Salesforce, they know how to understand the state of an account, etc. They tend to be more limited technically and as such are generally deployed for the sale of a product which is “finished”, and as such spend most of their time mapping customers onto existing patterns that are already known to work, and identifying those patterns.
FDEs are different in that they’re deployed to sell and integrate products which are unfinished in some way. For example Palantir sold a fairly low-level generalized product which required bespoke technical work to integrate with a customer. This integration work is more like normal engineering work in that lots of code may have to be written and there’s technical creativity required. The reason why FDE is increasingly in vogue now is because AI companies haven’t yet found a high-level product shape which is generalizable across many customers, because the market is immature and customers probably don’t know what they want. So there’s lots of engineering work required to take a lower-level offering (e.g some sort of agent) and figure out how to use it to generate value for one particular customer.
Based on what I first heard it described as, yeah, I think so.
In most places I've worked SAs are generally just connecting existing pieces of a system together to meet a customers needs. They may write code, but it's often just glue to connect two bits of the system together or transform some data or something like that. They're not really contributing to the underlying product, they're just using the product and some custom code to meet a specific customer's needs.
An FDE is supposed to be closer to a regular software engineer on a product or platform team in that their goal is to solve a specific customers problem, but they're supposed to be more focused on the big picture and using their learnings to build a better product. They're still using existing systems to solve problems and writing plenty of glue code, but they're also supposed to have the leeway to contribute to the underlying product to make it better for all customers.
The simplest example I can think of would be something like a customer saying something like they need a way to convert a bunch of their data to a CSV and then send that to a certain email address every Friday. A more traditional SA mindset may be to write a Python script that runs on a cron that connects to that customers DB pulls the data, converts it to CSV, and then emails that specific email address. Even if the SA knows that's not the best way to do it, it's the tools they've been given to work work. A FDE should have the leeway and skills to go talk to a PM and their engineering team and just build an in product, self serve tool to do that (assuming everyone is aligned that that is good for the product).
Again though, what I've heard is that most FDEs at most companies are just SAs by another name.
It’s an SA, except too many places started using SA for sales roles, so now we have the FDE role which… is starting to get polluted by sales, too.
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.
If I did that to the best of my ability, I’d want to be a boss and not a chump. The real question is how do they actually reward the people who excel in this role, and do they really recognize who’s delivering or do they look at gamey metrics and pedigree. These are important questions for the EV calculation
As a professed "hacker tourist" I've been rewarded with the trust and respect not to set myself or my coworkers on fire, in cultures which didn't see a lot of outsiders. Several times I've threatened to quit within the first month if things didn't change; one time I walked in the door, turned around and walked out. Once I paid for my own plane ticket for the interview, and didn't come home to visit for two months (worked there for six). Pay has been ok, but not stellar. Duration has been three to nine months. (I've been a licensed business since 1984.)
I basically did this for a couple years around 33. I was the highest paid IC for a multi billion dollar "digital transformation". I was writing code in 5+ languages, doing hardware retrofits, had r/w access to every system, climbing ladders to deploy hardware for my own skunkworks projects.
The whole thing was crazy. I mean actually insane. I look at my productivity from the time period and it blows me away.
Really enjoyed it. Being the one guy who was damned adamant I wouldn't manage anyone kept me out of the political fray as well. I drank and I knew things. I probably had more freedom and access than anyone ever has had at a company that size, I mean they literally ended up paying for me to have some degree of DHS clearance to operate unrestricted in passport zones, it was wild.
Is it good for a company to have those roles or not? I don't know, after starting several companies and also working in corporate, that was the most fun I think I've had. Moving the needle, unfucking things, reducing complexity.
Providing accountability where there was none before.
I left because they wanted to me to move. I was flown out every Monday and flew back every Friday but I didn't want to move cities and I had a startup I wanted to launch. I took 3 months traveling and then 2 months writing code for my 4th startup.
There are _almost_ no universal rules, my work saved them an insane amount of money and generated even more, but the methods only made sense to dig them out of the completely unaccountable traffic jam they had built for themselves.
If you ever read the James Bond books as a kid, there is inner monologue explaining why he is so overt, his whole modus operandi is to be conspicuous and to shake things loose in opaque situations. When your works starts holding peoples feet to the fire you have to come extremely correct and it paints a target on your back until you have sufficient track record. It helped me learn a lot about myself and ultimately taking the time to inhabit the role fully and lose myself in it helped me understand what I really value.
[dead]
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.
Edit: I guess I'm not surprised to see the downvotes on this; I get that a lot of people on HN don't really understand product management, or don't value it. The path from engineering to product management can really start with getting closer to the customer - putting more time into understanding their needs.
The reason this shifts a lot with LLMs is that a sales engineer / forward deployed engineer can tackle customer needs much more quickly with Claude Code than they could have themselves, which means these feedback loops can become a crash course in customer experimentation and understanding.
Teresa Torres wrote an amazing book about continuous discovery that I use with my teams (https://www.producttalk.org/continuous-discovery-habits/), and a third of the book is about talking to your customers every week if you can. Someone in a customer facing role who can also build code has a huge leg up compared to someone coming at product from an academic setting. Case studies in an MBA are great for strategy, but they're usually fixed points in time. Getting that nimble feedback to hone your product sense is the hardest part of getting good.
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 edited my comment to make my point more clear, since I think a lot of folks don't know what a PM does.
If your PM isn't defining a clear strategy, your PM is probably inexperienced and/or overloaded. It sounds like you might have experiences like that.
I think a good PM needs three big skillsets: Customer discovery, Strategic planning, and leadership alignment. The second and third are easier to learn academically. This kind of role is ideal for learning the first.
The PM’s job in this situation is to articulate some sort of high level strategy generalizable across customers, based on information gathered from customers, which includes feature requests but is more than just that.
Good PMs are more than ICs, they are also a force multiplier for the engineers they work with.
Pressing needs like AI responses to questions on HN to promote themselves.
I don't use AI in any comments I make.
If fable can solve the customer’s needs then why is the PM needed at all?
What do you think a PM does?
What do you think an engineer does?
You asked why the PM is needed. I'm trying to understand what you think a PM does so I can help answer your question.
LLMs don't really have anything to do with this, other than LLMs being useful for pretty much any (tech) role.
What makes you say that?
Well for full disclosure, I lead a team of forward deployed engineers at a database company. The role typically means that our engineers are embedded within the customer for extended period of times, and they work on basically devops, software engineering + some more traditional solution architecting, which is basically what the article describes.
They use LLMs in similar ways that regular engineers use. This is an engineering role, not a product / project management role. I don’t think this role is anything super special that will be revolutionized in any different way than that other engineering roles are affected.
In the end their value add is that they’re both embedded within the customer’s and our company, they’re our eyes and ears within the customer. Their purpose is not to make sales demos, their purpose is to make our software actually work properly for the customer’s needs.
OK, we both have the same understanding.
I'm saying giving an FDE the ability to significantly modify code for customer needs using a powerful frontier model will make their job more about customer discovery and strategy than about engineering, a big shift of ratio of where they spend their time. It will make the feedback loops tighter, let them experiment faster.
What’s a mini-PM? Something Apple offers?
I don't understand why you're getting downvoted.
In East Asia, 'SI' is looked down upon, but one of the strengths often mentioned about SI is understanding the client's business, that is, the domain. It's true that in the industry, which is based on job-hopping and career building, it gets a lot of criticism. But from a startup perspective, it's often evaluated positively as having strong business insight. So I think your opinion is valid.
In fact, from what I've observed on HN, most people seem to be obsessed with 'programming purity' rather than 'product cycles.'
When you're doing product-focused or delivery-oriented development, there are inevitably black boxes you don't understand, points you can't control, and product management isn't about 'perfection.' It's about whether you can get fast feedback from customers and iterate. But here, it seems like most people assume that everything should be ideally perfect.
I agree with your opinion. Because if you go to the field rather than just dealing with services, you can clearly see how imperfect domain modeling really is. If a business is large enough, you can reshape the domain with capital power to fit your service, but as you know, most of the time when you go on-site, there's a conflict between an imperfect domain, most clients don't really know their own requirements, and implementation capabilities.
Actually, I think your post is more high-level. Don't worry too much about the downvotes.
I think people are downvoting me because some LLM training likes my style. ;)
And thank you! It is higher level. I'm not worried about product management as a field at all now, because software engineers will have more trouble upleveling their thinking to the business than product managers will building high quality software with an LLM.
In the semiconductor industry this role is called Field Application Engineer. They do serious work, not just slideware, as your chip probably ships with drivers that were designed months or years before you could get significant time from the customers engineers (which generally only happens after you manufacture, but you need software to prove it works well before that). So these guys are the ones who adapt it, and their feedback is valuable as they are the ones who build understanding of the customer.
However, at my old employer they didn't get commit rights to the main software repos. They had to carry around a bunch of patches which were gradually cleaned up and integrated. As I didn't directly work with them, I don't know if this says more about them or the guys managing the internal development.
It's a role that fits a different personality to that typical among software engineers. If you're bored as a dev it may suit. Pointless to try to shoehorn people into the role that don't suit it 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.
This is useful context, but given that you're saying "delta" was in use over a decade ago and that you don't have any firsthand knowledge in the time since, it seems at least a little presumptuous to confidently asset that people didn't start colloquially saying "force" afterwards.
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.
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?
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.
I've been a Forward Deployed Engineer practically speaking, and properly construed the title correlates well with the personal sobriquet "hacker tourist". I've been to Prudhoe Bay, places I won't name here; factories; other things which were basically factories but maybe you wouldn't realize this from the outside. I've done some odd remote contracts, such as hunting medical devices on hospital networks (they're like SCADA, but without the Purdue Model).
I've bridged between the customer's technical team and the vendor / provider's technical staff... when there was vendor technical staff. Other times it's been more like a treasure hunt or something (sometimes there are real bad guys) and I've been there to bridge a gap between broader industry knowledge and the onsite technical team.
I'm getting pings from recruiters based in the Bay Area about "forward deployed engineers" in SF metro. It's not one of the labs, there are no mech or electrical engineers, nothing is going to escape, catch fire, or explode, nor is the inventory heavily guarded. It is bullshit; a con, so you won't notice you're being asked to establish nexus in CA.
I'm tired of flying (although if you need me to literally parachute or rappel in, I'm getting a little old but we can talk), but I'm happy to drive anywhere in the greater Pac NW (no more than two days out from Puget Sound metro).
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 put something similar another comment. What you describe is a tough job that requires dedication and the ability to objectively differentiate yourself through your work across multiple disciplines. I’ll copy it here: “The real question is how do they actually reward the people who excel in this role, and do they really recognize who’s delivering or do they look at gamey metrics and pedigree” I worked at a technical consultant out of college and it was a lot of the first category but often my small team did step 2. Yet it was never promoted by the larger corporate hierarchy because the incentives were not there. I would love to a job like this because I’m so nerdy but also charismatic and have perspective. Knowing myself and how dedicated I would be, I wouldn’t take anything less than 250kz
Don't forget to mention how modest and humble you are.
Modesty and humility? Then they would need to pay me 400k!!
Everyone got tired of renaming sysadmins so they moved on to a new role to rename.
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.
"Customer-embedded engineers" or "Site engineers" are two useful non-military way to phrase this.
In this AI era, we would also require a new role named "Backward Stability Engineer" whose job would be the exact opposite of FDE. The core of this role would be to defend from modern AI slop code updates, 0 downtime integrations, deterministic automation etc. Fusing LLM with Legacy systems will be their art.
>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
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.
> FDEs generally work with customers, long-term.
In these days of mass layoffs every month, talking about "long-term" sounds like a cruel joke.
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
I've always heard the term "field applications engineer" for the consultants the vendor supplies to integrate their product.
In the automotive industry it's not uncommon for contracts to require an on-site engineer, basically FDE.
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.
> That's pretty straightforward; even if the role came to exist two months ago, you can still have signed a five-year service contract
Does the contract require that keep the same person "forward-deployed" with them the whole time? If not, then it's pretty presumptuous to claim that we know they'll be there in the long term because of the contract, and if so...that's some pretty incredible job security!
Tech is becoming from a margins heaven to the worst of all worlds. Super high capex (like manufacturing) in addition to headcount requirements for each additional customer (like consulting).
Is this the same as a GTM (Go-To-Market) Engineer?
In East Asia, there's a role called 'SI' (Systems Integration), but it's rarely recognized as proper career experience. It seems to be different in the West. The reason it's hard to get career recognition is that every company uses different stacks, so you're expected to know a lot of different technologies, but it's hard to go deep in any of them. And the company-specific technologies don't help when you change jobs, so you're effectively treated as bottom-tier. That's what I do for a living too.
In fact, most hardware manufacturers stick with legacy technologies for 'stability' reasons, but that experience is rarely recognized as valuable career capital
Used to be called Sales Engineers. Also Customer Engineers. Also Field Engineers. Also: Solutions Architect.
Same shit. Different day. The wheel begins a new turning.
This sounds like wearing too many hats, I don't think it's the best use of people.
We have sales engineers at home.
Those might be called "Field Application Engineers" in some places.
Forward Deployed Financial Transaction Enablement Engineers
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.
Because the software platforms are so jank you need dedicated support personnel...
That, and you laid off all your FTEs so you could afford the shiny platform your execs bought after a disgusting night of excess debauchery.
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
Some skill overlap but that's it. I was incredibly surprised to find what I thought was a Site Reliability Engineer role was actually 'forward deployed'. I've taken to calling it Sales Recovery Engineering (lol), or realistically, consulting while someone else negotiates, enjoying less freedom/compensation and completing extra work.
In fewer words: people want you to think so, but not really. I'd argue FDE is a change for the worse (as an employee). Less about managing your direction/service, and instead, customers.
Back in the lat 90s we called ourselves a "Strike Team".
This is a paywalled thing that's bloaty in the visible portion and then hits a subscription block before the interesting parts. Bah.
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.
In the classic FDE model palantir pioneered, one of the main features was that you would use your learnings from one customer and integrate that back into your in house product, so that similar customers are serviced for cheaper later on.
With AI coding agents FDEs are now everywhere. One because they can demand a higher salary due to simply doing more due to AI. And two, because AI really accelerates the whole bespoke solution implementation thing. However, from what I hear, none of the actual "integrate that back into your in house platform" stuff is actually happening. So it's a tiny bit of a farce.
It’s just a field engineer but with a more military-sounding name in order to attract the worst bros. A job that has existed since the 60s in computing and likely long before that
[flagged]
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)
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
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.