How you can determine what the FDE job at Company X really entails.
Forward-deployed engineering isn't one role. It's seven. Here's how to tell them apart.
👋 Hey there - I’m Sanjay. I’ll be writing a little bit each week about what’s going on in the world of FDE. As always, would love to hear from you about how to make the newsletter more useful, and please do send along links or things I should be reading! You can email me at sanjay@fdeverything.com.
If you’re a job seeker looking for a step by step guide to what an FDE actually does, you’re going to be searching for a a while. "FDE" has gone from a Palantir-specific title to the most overloaded term in the valley.
Everyone is using it. And everyone seems to mean different things.
That said, there is hope! I’ve talked to dozens of companies running their version of the FDE playbook, and the roles all pretty much all fall into the same 7 categories. With just a few questions, you can figure out which category a company’s FDE role falls into.
Before we get into the details, here’s the summary in diagram form:
Overall, our goal is to understand what a company means when they say “FDE”. You can get there with just 3 questions.
Question 1: Where in the sales cycle are you doing the work?
The first thing to determine is where and at what stage are you doing work with a customer or potential customer. In vertical or horizontal “traditional” SaaS, there is always a step before the prospect signs the deal where you show how the customer could be successful using the platform.
How you show it usually depends on what what you’re selling, its price point, and the value it drives.
But in general you either show the value with A) a set of slides, or B) a demonstration of the software.
For most B2B customers, the demo resonates best if it’s custom-fit to the potential customer. Perhaps it shows the platform integrated with the customer’s existing source systems, or shows example data that replicates the kind of data that the customer usually works with.
In the AI era, it’s now possible (or even expected) to be able to show a lot of what the platform can do tailored to the specific customer requirements, use case, and problem statement, even if the customer knows that the problem is unique to their organization.
Question 2: How technically complex is the work?
The second parameter is around what’s actually being built.
The least technically complex work is just talking or presenting the software in a nice way. A set of slides, or a spreadsheet showing a value calculation, or just providing a vocal narrative to the prospect or customer.
Since custom demos can often be built without any sort of underlying platform or product, those come next in the hierarchy (and perhaps can be “one shot” with AI directly today).
Assuming there is at least a primitive version of the software platform, next is configuration. Usually there’s a set of knobs that can be used to wire things up so that the platform is at least somewhat tailored to the customer. That often includes boolean flags to enable or disable certain capabilities or structured config files to set up the customer’s “schema” or “ontology”.
Then there’s a range of engineering work that could be done.
For example, someone on the team might write code to connect the platform to the existing customer systems. Often such “integration” work is boring and repetitive, but inevitable since every piece of business software has to connect to other business software in order to be valuable. Software companies all know that their product is merely one piece of a larger technical architecture for their customers.
Some platforms have an experience where the FDE is expected to write code or transformations in platform. The idea being that the software being deployed is flexible and itself can be modified with code to suit that particular customer’s needs. Often such code is written to build custom dashboards or visualizations or automations for the customer to use, and is expected to be “one off” work. Palantir, Databricks, Snowflake, and other “data platforms” fall into this category.
In the AI era, there is often work to train, build a set of evals, and provide human in the loop feedback to an ML model built to solve a specific problem. There’s been a whole host of AI startups where FDE is pretty much this job - the underlying platform is the same, but you have to build novel tooling to handle the customer’s data in a way that’s valuable.
Lastly, but certainly not least, there is the FDE job of building the platform in the field with the customer. In my opinion, this was the original FDE job at Palantir. FDE was both a source of input to the platform and product teams, often by building the first version of whatever platform primitive was needed.
Question 3: What is your platform and how mature is it?
That brings us to platform maturity. It’s one of the main ways that an FDE role can change even at the same company over time.
In the early stages, which most startups are at, FDEs are the “swiss army knives”. They do anything and everything, and since the platform is still so early, that often means building the platform in the field with customers.
As the company matures and the platform gets better, it gets closer to “finished”. By definition then, platform iteration is at a minimum, and the FDE job probably does not include as much of building the next platform capability. Instead it becomes much more about building “on the platform”, configuring it, integrating with it, etc.
More importantly, when the platform is iterating more slowly, it also means that the other roles / jobs at the company tend to calcify and specialize. The sales roles break into the usual SDR, AE, solutions engineers. Specialty customer success, implementation manager, support, and maintenance roles come into existence.
As an FDE, your role gets less about “doing whatever it takes” and more constrained, depending on how the company thinks of their FDEs, you may get pigeonholed into one part of the process or one type of building.
The variety and strangeness of an individual deployment goes down, and it sort of pushes the type of work that needs to get done leftward on the axis above.
So what are the different types of FDE?
This finally brings us to this diagram:
The seven flavors of FDE that we’ve seen include:
Relatively non-technical FDEs, who tend to look a lot like management consultants or customer success team members. They tend to do very little if any coding day to day, but do build a lot of slide decks, run meetings and send emails. We’ll call these the “Consultant FDE” and the “Customer Success FDE” respectively.
Other FDEs tend to do a bit more up the technical stack. They are often segmented by the part of the sales cycle they’re in - usually if they are presales, they build a lot of custom demos for prospects like solutions engineers. If they are post sales, it’s usually to serve as implementation managers, who configure the platform and connect it to a customer’s other systems. I would call these “Solutions FDE” and “Implementation FDE” respectively. I think these folks are generally what people have in mind when they say that FDE is meant to “speed up implementation time” or “accelerate the customer’s time to value”.
The more technical FDEs run a very wide spectrum. Their work seems to depend on how sophisticated and mature the underlying platform is.
If the platform is still very early, and the product still somewhat immature, FDEs are often given a very wide remit. Their job is to do anything and everything to make the customer successful, AND to help unlock or build the platform capability that will be useful for the subsequent customers or prospects.
It’s often a very dynamic job, but it has the downside of not having a ton of platform leverage. I would call this the “Immature Platform FDE”. I don’t think immature is a condemnation by the way - most applied AI companies are looking for something in this role, because so much innovation is still happening in the industry right now. It just means that the platforms that are being built are still early, and so need more than just configuration from place to place.
If the platform is mature, then the FDE job is more constrained. They are writing code to adapt the platform to the customer system. Often this is a combination of integration code and code written in the platform itself. I would call this the “Mature Platform FDE”.
Interestingly, the very company that invented FDE, Palantir, may now be in this category. Many Palantir FDEs today don’t actually write that much platform code, nor do they build totally new capabilities for customers. Instead, they primarily configure and write code in the platform.
This “promised land” is actually a good thing, because in some ways it’s the only way to recover the type of margin profile that people are hoping to achieve in software. I’ll talk more about the revenue / margin calculation for a typical company running FDE in a future post.
In the case of “AI SaaS”, the equivalent work is often building evals, running human in the loop training, and building the customer data foundation that will allow the platform to be effective. This is in some sense a totally new role, because so many applied AI companies have to figure out the last mile to make their platforms useful to customers. I would call this last type the “Applied AI FDE”.
What if I’m building a team? Which flavor should I pick?
In some ways, you don’t really get to pick. You see how you’d evaluate your company on the parameters above, then make a decision.
Because everyone just says “FDE,” it’s easy to hire one flavor while picturing another, bringing on someone who writes integration code but can’t meaningfully contribute to platform, or bringing on someone who wants to be a “real software engineer” but ends up just building custom demos and configuring things. In my opinion, many of the “our FDEs aren’t working out” pain I hear about seems to be this sort of flavor mismatch.
I also expect the FDE job to continue to change. In some ways the early FDE’s job is to build the capability that eventually makes their own role narrower. And along the way, improved technology (AI today, perhaps something else tomorrow) rewidens the aperture of the jobs-to-be-done for the FDE. For example, the modern FDE almost always has to think about evals and infra and LLMs and prompt engineering.
So whatever shapes the FDE role has today, I would assume it’s temporary. The companies that get this right aren’t the ones with the perfect definition. They’re the ones who notice when the assumptions have shifted, and are willing to redraw the role to best provide value to customers.
Notes:
Thanks for reading! Email sanjay@fdeverything.com with any ideas / feedback / suggestions / important content I’ve left out!
If you found this helpful, respond with a thumbs up. As usual, I respond to every email, and my inbox is at a sparkly 0 right now. I dare you to email me. You can also forward along to a friend!