Forward Deployed Engineering Is About To Get Diluted
But AI vendors need enterprise adoption at any cost
Hi, fellow future and current Data Leaders; Ben here 👋
Over the past year we’ve seen the FDE role continue to grow in popularity and in the past few weeks there have been several announcements of large tech companies investing billions into FDE organizations. So let’s talk about it!
Before we jump into talking about FDEs I wanted to share a bit about Estuary, a platform I’ve used to help make clients’ data workflows easier and am an adviser for. Estuary helps teams easily move data in real-time or on a schedule, from databases and SaaS apps to data lakes and warehouses, empowering data leaders to focus on strategy and impact rather than getting bogged down by infrastructure challenges. If you want to simplify your data workflows, check them out today.
Now let’s jump into the article!
Microsoft recently announced a $2.5 billion investment for an army. An army of 6,000 FDEs.
AWS also announced a $1 billion investment into a new Forward Deployed Engineering organization.
Both are joining the hype cycle Palantir helped start, and now every AI startup seems to want in.
Microsoft did try to distance themselves by stating:
This goes beyond what has been labeled as Forward Deployed Engineering (FDE) and will be the largest, most capable, outcome-driven engineering organization in the industry. - Microsoft
Now by saying that, they are really only putting a spotlight on the FDE term and what it is. They just want to make it sound cooler.
Like the Zune, it’ll be like the iPod, but better!
Here is my bold prediction.
FDEs will eventually become the new SIs or contractors.
Like my prior article about Anthropic looking to partner with consultants, this is very much a similar response. AI vendors need to make AI useful inside enterprises. They need people burning tokens and they need them using their products.
Ok a better way of putting it is that deploying AI in a way that is valuable inside of companies besides chat is hard. There isn’t a playbook for how healthcare or banking can truly use it to drive value. So you need people that both understand the technology and understand the domain well to see the opportunities for what the technology can do.
But with this sudden demand for a role that hasn’t really existed outside of a single company for more than a few years, there is a big gap between the talent pool and said demand.
What Is An FDE?
Like many roles in the past, I am sure the term FDE will become highly debated. Similar to how what a data scientist was and continues to be debated today.
Is an FDE just a consultant that actually implements, a system integrator (SI), a combination of all the things? And what’s the bar for who is allowed to be called one.
I like the end conclusion from Gergely Orosz ‘s piece on FDEs where he states that:
The FDE role looks like it’s two roles rolled into one: working for the customer, and also contributing to their employer’s core product. - Forward Deployed Engineers
He also later breaks it down into three types of FDEs, which opens up the role for a further breakdown. Similar to the way data engineers broke up into data and analytics engineers.
Focusing back on FDEs, I believe it best to go to the source of the role. Palantir. In particular, I wanted to focus on their article, Dev versus Delta: Demystifying engineering roles at Palantir. Here were several takeaways from their perspective of the role.
FDEs are measured by customer outcomes
They combine product knowledge, engineering, customization of said product, and problem-solving for one customer.
FDEs differ from traditional consultants because they build/deploy long-term software solutions, rather than one-off recommendations.
They also serve as a feedback loop into the core product.
I believe the important point in this article is that this is not just “a consultant who can code.”
FDEs are close enough to the customer to understand the real business problem. They are technical enough to deploy the product. And they are tied closely enough to the product team that what they learn in the field can eventually shape the product itself.
I think one of the themes that really sticks out across the articles I read and conversations I have with FDEs is that product feedback loop.
But there is a very fine line between that, and just sending a smart engineer who understands how the product works to integrate inside of a customer’s tech stack.
Don’t get me wrong, it is both valuable work and complex work. But it is also much closer to the work consultants, contractors, and SIs have been doing for decades.
So when I see Microsoft, Amazon, Salesforce, and every other enterprise AI company starts using the FDE term, I don’t think the question is “are these real FDEs?”
The better question is: which part of the FDE role are they actually copying?
What is the result they are actually trying to get?
The Future Of FDEs - The Dilution Problem
Now that you know what an FDE is. Let’s talk about what is likely going to happen to the role.
The role will quickly start to broaden in terms of what and who will be called an FDE.
I believe we are getting a precursor to what is happening in this line from Microsoft’s announcement.
We have robust FDE partnerships with our Global SI partners, including Accenture, Capgemini, EY, KPMG, PwC and others.
FDEs will just become a new iteration of SIs. I am not saying that this is what FDEs are. I am saying it’s likely what this role will become.
After all, if a part of the role is meant to act as a feedback loop that adds back to the original product, will those SI partners add back to the Microsoft products? Will they be building general products or one off solutions?
I think it could be argued this is a crucial part of the FDE role. So if you outsource that role to other companies, will they help you build your product?
Salesforce already referenced this tension in a recent article.
It may sound like forward deployed engineers do the same work as Salesforce partners, but they play different roles, and their collaboration can help customers launch agents more successfully. Partners still do the nitty-gritty work of helping customers implement technology, but FDEs can provide behind-the-scenes knowledge from Salesforce that a partner may not have. - Today’s Hottest Role: Forward Deployed Engineer
The problem here is this quote creates a weird hierarchy.
I mean they literally said FDEs “can launch agents more successfully.”
Really taking a shot at all their partners who probably spent money and time getting certified in Salesforce Agentforce. Those partners, aren’t going to be as successful as the FDEs.
But don’t worry, they’ll leave the SIs the nitty-gritty work.
What does that even mean? Like the partners have to do the hard real work while the FDEs get to have all the fun with AI?
It really feels like they can’t make up their minds and further creates confusion for customers who are looking to set-up all of the new features Salesforce is trying to sell.
Do companies need to hire both an SI partner and bring on FDEs?
Do they just need to pay for your AWS, Palantir, Snowflake FDE AI solution?
I get it, these companies have to keep their partners happy. Partners are a massive distribution system for them.
Salesforce also needs to keep up and show that they are also a hip company with FDEs like everyone else.
Most companies do not have the margin to pay for AI tokens, an SI partner, an FDE team, and a new AI platform all at once.
More than likely what will happen is that SIs will be forced into picking up some of the slack of FDEs, or they will just title their current contractors and consultants as FDEs even if it is purely cargo culting.
The Hiring Problem - Where Do All These FDEs Come From?
Suddenly hiring 6,000 rock-solid FDEs or even upskilling them will be far from easy. Especially as it seems every new AI company and all the current SaaS/Cloud platforms want them.
The problem with turning FDEs into an army is that I don’t believe the original role was meant to be mass produced.
Palantir’s FDSE role has long had a reputation for being selective. I found a few interview reports on JoinTaro that put the pass rate around 6-10%, which is not an official Palantir number, but it does fit the role’s reputation for being selective.
That makes sense given the combination of skills the role requires. It wasn’t meant to be a role that any developer could fill.
If every company wants FDEs then likely two things will happen. Either the hiring bar stays high and the army of tens of thousands of FDEs never materializes, or the title expands until a lot of people who would have been called consultants are now called FDEs.
We’ve seen this dilution happen in many roles because companies are looking for specific types of talent and there is a limited pool and employees want to have certain titles because it will help them stay competitive.
It’s just the reality of work. I’d love to tell people entering the market that title doesn’t really matter(because I do believe it). But it’s kind of like saying money doesn’t matter. Sure, its kind of true after you have enough to deal with a baseline set of your problems.
The same thing goes with title. Once you’ve proven you can deliver at companies, they likely will care less about your title. In fact, you probably can start making your own. If you’re early on in your career, you have to have something that says you drive value and title is one of those things.
Why This Was Inevitable
I am not someone who generally likes being pedantic for the sake of it. Like I said, I think getting stuck on titles is not a great long-term career plan.
But the broadening of the FDE title was always inevitable.
LLMs created a real enterprise adoption problem. Everyone wants AI in the business, but very few companies know where it should actually go inside the company.
Companies are also blowing up their token budgets and not finding ROI on the other side. They are developing ethereal MVPs and PRs that get churned quickly. In turn, there is a need for engineers and developers who can translate business problems into technical solutions(a tale as old as time really). Having engineers who understand where AI could integrate well and understand your company will be a premium for the next few years.
The market will eventually have two kinds of FDEs. The types that can dive deep into a company and understand their problems and turn that into outcomes that can be generalized across the industry and those that are really just doing implementation work.
I believe this is inevitable.
AI vendors need enterprise adoption. Enterprises need help making AI useful.
And if you’ve worked inside enterprises, you know most engineering teams are already busy keeping the lights on, migrating to the next data warehouse, and dealing with the backlog they already have.
Someone has to do the work of integrating LLMs into workflows. More importantly, someone needs to figure out where it’s valuable to do so.
There is no way around this. OK, I do think the one possibility is that LLMs allow engineers to spend more time juggling both the technical and business side of problems. The question becomes do a large enough swath of software engineers want that?
Final Thoughts
The demand for FDEs is growing. Maybe the title changes again in a few years. But every tech cycle only has a handful of titles people chase.
Analyst in the 2000s.
Data scientist in the early 2010s.
Data engineer and analytics engineer in the mid-2010s and early 2020s.
Now, maybe, Forward Deployed Engineer.
These roles often combine old skills and needs with newer ones while trying to answer a current market need.
Until then, the FDE role will continue to extend beyond its original usage.
Of course, I’d love to hear your thoughts, and as always thanks for reading.
Video Of The Week - If AI Can Replace Workers, Why Is It Hiring Consultants?
Articles Worth Reading
There are thousands of new articles posted daily all over the web! I have spent a lot of time sifting through some of these articles as well as TechCrunch and companies tech blog and wanted to share some of my favorites!
Most companies think they’re building a software factory. They’re actually just shipping bugs faster
Industrialized factories changed how the world produced physical goods: more output, lower costs, faster than anything that came before. Now a similar shift is happening with software.
LLMs have lowered the barrier to writing code, increased individual output, and pushed organizations to think about software development as a production system. The standard software development lifecycle and CI/CD practices that have held for decades won’t hold up under that pressure. That’s where the software factory comes in — and like physical factories, it needs more than speed to actually work.
The idea of a “software factory” started to solidify over the past year. Luca Rossi’s“The Era of the Software Factory” made the case plainly: AI is not just changing how fast people write code — it’s changing the whole production system around software.
Building Trust and Credibility is the New Moat for Engineering Leaders
We hear the word “moat” a lot these days, especially in the context of AI.
“Good judgment is the new moat for engineers”. “Harness is the new moat for AI products”. “Loop engineering is the new moat”.
So, in the spirit of a trending word, I’ll be sharing what I believe is the new moat (competitive advantage) for engineering leaders in this article.
The insights are based on what I am hearing and seeing regularly from talking with different engineers and engineering leaders across the industry, and what I recommend they do in order to become valuable at their company and grow in their careers.
End Of Day 221
Thanks for checking out our community. We put out 2-4 Newsletters a month discussing data, tech, and start-ups.
If you enjoyed it, consider liking, sharing and helping this newsletter grow.