[poemxo]

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.

[superfrank]

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...

[lolinder]

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?

[cweld510]

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.

[superfrank]

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.

[procarch2019]

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.

[trollbridge]

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.

[colechristensen]

It's looking like the answer is no. They're the same within the bounds of ordinary differences in the role between companies.

[paxys]

If you hear a pitch from McKinsey about being a consultant it will also sound like the coolest job in the world.

[fellowniusmonk]

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.

[randysalami]

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

[m3047]

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.)

[Schiendelman]

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.

[majormajor]

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."

[Schiendelman]

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.

[cweld510]

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.

[fmajid]

Good PMs are more than ICs, they are also a force multiplier for the engineers they work with.

[paxys]

If fable can solve the customer’s needs then why is the PM needed at all?

[Schiendelman]

What do you think a PM does?

[paxys]

What do you think an engineer does?

[Schiendelman]

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.

[indoorfish]

Pressing needs like AI responses to questions on HN to promote themselves.

[Schiendelman]

I don't use AI in any comments I make.

[stingraycharles]

LLMs don't really have anything to do with this, other than LLMs being useful for pretty much any (tech) role.

[Schiendelman]

What makes you say that?

[stingraycharles]

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.

[Schiendelman]

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.

[jdw64]

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.

[Schiendelman]

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.

[tclancy]

What’s a mini-PM? Something Apple offers?