ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
86% Positive
Analyzed from 2354 words in the discussion.
Trending Topics
#role#engineer#product#customer#fde#more#engineers#term#customers#fdes
Discussion (59 Comments)Read Original on HackerNews
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...
Is the nominal difference between an archetypal FDE and an archetypal SA greater than the difference in the SA role from company to company?
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.
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.
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.
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."
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.
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.
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.
I am curious whether this FDE direction will result in more product and platform complexity that is more difficult to unwind.
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.
Same shit. Different day. The wheel begins a new turning.
...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
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.
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
In these days of mass layoffs every month, talking about "long-term" sounds like a cruel joke.
That's pretty straightforward; even if the role came to exist two months ago, you can still have signed a five-year service contract.
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
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.