Subscribe now

Favorite resources from the last two weeks:

• I enjoyed this post by Andy. Not enough is written about the motivation for why the FDE model works well. A large part of it is that you want the person building the system as close as possible to the person using it. As Andy says:

By “land” I mean things are never only internal to certain humans, customers, sales people, teammates, or in a database somewhere. The work is literally to propagate behavior change via relationships and conversations that catalyze not only your company to do things differently, but my company too, on the other end…it's useful on an individual level to really be careful and thoughtful when reducing the distance between my mind and yours.

• Alexey as part of the AI engineering field guide writes that “Forward Deployed Engineer (FDE) is one of the fastest-growing titles in our AI engineering job data. We found 28 live FDE listings in February 2026 and 118 in July, a 4.2x increase in less than six months.”
  
  More interesting than the specific analysis (it’s obviously not comprehensive) is that he’s uploaded all the data, including where it was scraped from, and the analysis in a ipython notebook as part of the repo. I enjoyed cloning the repo and poking around to see what other cool analyses could be done. You can look at common frontend frameworks folks are using, or which locations for work are trending up.
  
  In some ways this is starting to look like the future - you can vibe code something and then share it with the world, but sometimes rather than sharing the “app” or the “website” you just share the code and data directly. Github seems to confirm that total contributions is dramatically accelerating. I’m very curious to see the 2026 data.

  

• The folks at Varick have been doing some particularly interesting content recently, including an appearance on Greg’s podcast, which was quite good if a bit too much of a presentation rather than a conversation, and then this excellent write up by Daniel who leads FDE there.
  
  The most thought provoking point for me was around how certain types of businesses (in Daniel’s argument, low margin businesses) are actually structurally set up really well to fundamentally change in the AI revolution, because cost reduction with automation directly translates to doubling or even tripling profits. High margin businesses usually can’t multiply their profits as directly, no matter how much they automate.
  
  It made me even more excited about the spaces I’m really passionate about (which happen to be very cost heavy even if not necessarily low margin - healthcare / life sciences) but also seemed to indicate there may be a huge opportunity in places with lots of admin overhead. USG for example. DOGE may not have been such a bad idea…

Favorite FDEverything roles from the last two weeks:

• Eric is hiring for an FDE at ConductorAI. Conductor runs a platform that helps government organizations run AI agent-driven workflows. (DC) Apply here.
  They also have my favorite flavor of job posting, which I’m surprised I don’t see more of in today’s world of rapid acquihires, a role where you can apply with someone else!

• Shannon at Foxtrot is hiring for a forward deployed engineer. Foxtrot is one of several excellent Palantir consulting shops run by Palantir alums, and many of my friends work with them. (US, EU remote). Apply here.

• Dylan at Figma is hiring for an FDE. That’s right - Figma! Apparently Figma is building workflows with enterprise - “you’ll work hands-on with customers adopting emerging Figma developer workflows, starting with Make Local, to understand their technical environments, unblock implementation, and translate real-world deployment patterns into product and engineering insights.” (SF, NYC). Apply here.

• Jake at Serval is hiring for a Head of Deployment. Serval is a unified help desk, access management, and automation platform with a built-in AI agent workforce. (SF). Apply here.

Looking to get hired?

• Our friends over at Nextplay are running a white-glove service to make intros and get you the perfect role. If you’re interested, please fill out the form here.

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. Or ping me with a quick reply! I respond to every email and my love of the game is unquenchable, though sometimes my calendar books up quickly.

• I’m going to start doing a few interviews with rockstar FDEs and FDE leaders. If there’s someone you want to hear from, let me know!

Subscribe now

Favorite resources from the last two weeks:

• Amazon launches FDE org, now valued at $1B. This continues the trend of the big labs building massive deployment arms to try to get enterprises to adopt their AI systems. In similar news…

• OpenAI DeployCo acquires Northslope. This is particularly huge - Northslope was a very big ex-Palantir shop, and as far as I know they were only doing deployments of a single piece of software: Palantir Foundry.
  
  Presumably now that they’re a part of DeployCo they’ll be focused on trying to sell as many OpenAI tokens as possible instead.
  
  Does that mean there’s a gap in the market for an FDE shop who wants to help deploy more Palantir? Perhaps this is good news for Fourth Age and Foxtrot, similar shops that are also run by Palantir alums.

• Tomasz Tunguz wrote about the $10B FDE boom. While his focus was on how the big tech companies are funding the forward deployed work, I think the thing that’s more interesting to me is whether those people and dollars can be productively deployed at speed.

  

  Selling into enterprise is hard. You can’t really just hire a bunch of FDEs and magic your way into it. You need to get stakeholder buy in, budget approval, and so on.
  
  I think all of these FDE orgs have to prove that they can actually serve a tangible market pull. Are enterprises so hungry for AI that you can hire an army of FDEs to deploy it? How many of those FDEs are going to be sitting on the bench?
  

  Perhaps the answer is yes. Every business out there desperately needs AI, but can’t implement it fast enough, and so these FDEs will meet the surging market demand. And perhaps the answer is no - many businesses do want AI, but they are slow to adopt or have enterprise-length sales cycles or they want to run an RFP. And in that case my guess is there’s going to be a lot of layoffs at these places in about a year.

• Jason Lemkin wrote about FDEs on the SaaStr blog. It’s interesting that even a SaaS veteran like Jason has pretty great intuition for how FDEs are different from traditional CS:

Traditional CS was built for a different era. The job was: help customers use software they’ve already decided to buy, make sure they hit their renewal metrics, escalate bugs. It was reactive, relationship-driven, and optimized for retention.

FDE work is different in almost every way. It’s proactive, technical, and optimized for deployment. You’re not waiting for a customer to have a problem. You’re going in before the problem exists and configuring the system so the problem never happens.

Favorite FDEverything roles from the last two weeks:

• Scott is hiring for a Deployed Engineer at Cognition. Cognition is the maker of Devin, the AI software engineer, and Windsurf, the AI-native IDE. (SF, Austin, NYC) Apply here.

• Isaac is hiring for an Agent Engineer at Sierra. Sierra is building AI systems for customer experience. Bret Taylor is Sierra’s CEO, and the story of him rewriting Google Maps over a weekend is legendary. (SF, NYC) Apply here.

• Karan is hiring for a Forward Deployed Engineer at Cartesia. Cartesia builds fast, highly expressive generative voice models. (SF) Apply here.

• May is hiring for an AI Deployment Engineer at Writer. Writer builds AI agents for marketing. (USA, UK) Apply here.

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. Or ping me with a quick reply (it’s Friday, you know you want to). I respond to every email and am always excited to talk about work.

• I’m looking to write more about individual companies and how they do FDE. If you’re at an amazing applied AI company that wants a write up, please reach out!

Subscribe now

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!

Subscribe now

Favorite resources from the week:

• Harry at 20VC interviewed Matan (FactoryAI) and Matan had this to say about FDE:

When we do FDE, the way I think about it is their goal should be acceleration.

If there’s a customer where we just give them our product, they’ll scale to like a million in six months. I’ll throw in FDEs if they’re going to scale them to a million dollars worth in three months. Great, they accelerated that.

If I’m sending in FDEs as services, like I’m not Accenture here. We are not a services company.

If we need FDEs to make the product work, we have a shit product. Like the point of FDEs should be accelerate and get them consuming faster.

The most interesting part of this is how several ex-Palantir FDEs chipped in to say Matan got this wrong. Here’s Barry’s take:

And Shyam’s:

The distinction between the FDE who helps accelerate an implementation of an existing piece of software, and the FDE who helps learn and build a new product, seems to be the biggest dichotomy in the field today.

I’ll write more about this in a future FDEverything post.

• Aaron at Box says that an “internal FDE” is going to be an incredibly popular role, that is, an FDE that works directly for the organization rather than being from a vendor.

First of all you need to understand today’s workflow and then figure out how to how to bridge the capability of the technology that is emerging and constantly changing with the workflows of that organization. Sometimes you can get lucky and you can kind of embed agents in an existing business process and it sort of just miraculously works, but oftentimes you actually have to re-engineer the process.

You have to migrate the data sources into a modern system. You have to change the workflow so agents can be more effective in that workflow.

All of that is effectively the work of the forward deployed engineer. That forward deployed engineer could come from a vendor like Box or Salesforce or Palantir or it could come from a systems integrator or maybe a new consulting firm.

I believe Aaron that “internal” FDEs will soon become a thing. And obviously the other two categories are already very prominent.

• Throwback - you should rewatch Bob McGrew talk about FDE on the YC podcast. His suggestions for what the Applied AI / FDE playbook will look like seems surprisingly prescient.

In particular, Bob talks about how in large enterprises / the US government, the market is very very segmented, and you want to understand deeply each part of the problem and build a solution for it. That lends itself well to an FDE style motion.

Favorite FDEverything roles from the week:

• Prince is hiring a Forward Deployed Creative at Luma. Luma builds AI agents for creative work. What is a forward deployed creative? I’m not sure but it sounds really cool. (LA, NYC, SF) Apply here.

• Vinoo is hiring for FDE at Kepler. Kepler is building verifiable AI systems for finance. (NYC) Apply here.

• Anna is running the a16z FDE fellowship, an 8-week cohort for FDEs and Applied AI leaders. Deadline to apply is today! (SF) Apply here.

• Omar is hiring an FDE at DeepMind. DeepMind won a Nobel Prize for AlphaFold, and invented many of the language model technologies that we use now. (London, EU) Apply here.

• Damon is hiring a Technical Deployment Lead at OpenAI. (SF) Apply here.

• Sanjay (that’s me) is hiring an FDE tech lead at Luminai. Luminai is building the AI platform for health system operations. I promise not to post about Luminai much, but we’re doing incredible work at Cleveland Clinic and other large health systems. (SF, NYC) Apply here.

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. It was so much fun getting responses to the first round up, and I respond to every email (albeit, sometimes a few days later). You can also forward along to a friend!

Subscribe now

Favorite resources from the week:

• FDE job postings are up 5x in the last 2 years. Of course, this might as well be a 100x - the reality is that the job got incredibly popular almost overnight, and before that there were only a few companies that were doing it. Many folks have changed their existing job titles too. One thing I’ve noticed is that now you have to do a lot of investigation to figure out which flavor of FDE people mean now.

• South Park Commons hosted a talk about FDE which had a few folks, including Nominal co-founder and the head of FDE at OpenAI. Pay particular attention to how they define the FDE role, and how AI assisted coding has changed the job.

• A veteran Palantir FDE talked about how product development happened while Palantir Foundry was being created in the late 2010s. Anjor is excellent, and has a great blog where he’s been writing more about the art of FDE.

• Andrew Ng (cofounder of Coursera) blogged about FDE and the future of AI engineering. Interestingly, Andrew’s take is that the demand for AI engineers will be even larger than the demand for FDEs:

  However, I believe the number of AI Engineer jobs will be far larger. A company might accept a few FDEs to be embedded within its organization. But most companies will want far more of their own employees working on their projects.

• OpenAI launched DeployCo and Anthropic launched a new AI services company. In both cases, it’s been interesting to see how the foundation labs are building their FDE teams, both internal to the company and by investing / incubating / spinning up their own separate services companies. Clearly the word is out, and the labs want a piece of the action. I’d recommend poking around at the team structures and the people involved - for example OpenAI bootstrapped the DeployCo team by acquiring Tomoro, which seems to be mostly ex-Accenture folks.

• Gergely of the Pragmatic Engineering blog wrote about FDE, including about the trend he’s seeing where FDE has become more consulting / solutions architect like, especially as the labs spin up services companies to go after the outrageous market demand. See his visual here:

Favorite FDEverything roles from the week:

• Jason is hiring for Deployment Systems Engineer at Nominal. Nominal makes software for industrial and hardware data. They’re growing rapidly and have customers making really cool stuff - my favorite is this plane. (NYC, LA, Austin) Apply here.

• Doug is hiring for an FDE manager at Candid Health. Candid is building the Stripe for medical billing. (NYC, SF) Apply here.

• Erik is hiring for a forward deployed ML engineer at Modal. Modal provides infrastructure that lets you run inference, training, and scaling of AI models. (NYC, SF) Apply here.

• Marina is hiring for an FDE Gen AI at Scale AI. Scale’s an interesting company - they started with data labelling, and now do all sorts of work building verifiable and reliable AI systems. The team is growing quickly as part of the Meta umbrella. (SF, NYC) Apply here.

• Arjun is hiring for an AI Strategist at Distyl AI. Distyl deploys AI-native automation that enables enterprises to change how they work, including in industries as disparate as telecom, finance, and hardware. (London, SF, NYC) Apply here.

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. You’d be surprised how often writing a newsletter feels like shouting into the abyss. And as always would appreciate forwarding to a friend who could find this useful.

A. Popular because seemingly all the hot startups are hiring forward-deployed engineers (FDEs). Some people are even calling it the critical key to the AI industry’s success.

B. Confusing because I am not sure many people actually know what FDEs do (or why they may be important).

To the best of my knowledge, the term “forward deployed engineering” was actually first used 10+ years ago at Palantir. It was a deliberate strategy Palantir used to solve problems for customers, and perhaps played a big role in their now giant success story (~$300 billion company at the time of writing this).

I know because I was lucky enough to start my career at Palantir. At the time, FDE seemed like a foreign idea. You would take fully-fledged software engineers, bring them onsite to the customer, have them deeply understand the customer’s way of working and the key problem to solve, then build something totally new to solve the problem. There was no product management. There was no design. Your job was just to get the problem solved. And you would do it by any means necessary.

In the early days at Palantir, there was no platform. There was no mechanism by which you could have leverage from one customer to the next one. We would rebuild the same sort of thing over and over and over. The life of an FDE was the life of pain. You would live out of hotel rooms, work a full day at the customer site, then come back and work late into the evening to get a product built, then show up the next day and get feedback. Repeat ad nauseam.

Eventually, just to save ourselves time, we started building products we could reuse from place to place. And after years of such iteration, we realized we’d been building the platform we needed all along.

In the end, Palantir’s platform became a foundation for their huge success across Fortune 500 companies, major Western governments, non-profits and more.

Inspired by Palantir, the FDE job title has spread to applied AI companies like Cursor and Harvey, to legacy companies like Salesforce and Oracle, to AI-native services firms that are building within verticals, and to PE firms that are looking to revamp how their companies work.

They’re all trying to do what Palantir did, and many of them are using the same tactic: use a forward-deployed engineering team, have them sit deeply with the customer and understand their problems, then build what’s missing.

But so far, there hasn’t been a great place to gather learning across FDEs. I’m now running an FDE team at an applied AI company, and there’s no clear playbook. Every week, I hear from AI companies trying to speed up their time to implementation, or trying to construct an FDE team, or trying to figure out how the FDE should contribute back to platform, or trying to understand the cost structure and revenue model for FDEs.

If the current zeitgeist is any indication, forward deployed engineering is here to stay. So we’re here to figure out the secrets, the new ideas, the ways of approaching it so that you can do your job better, whether that’s in a forward deployed role or if you think the learnings from FDE would be useful in your day to day.

Our aim is not to be prescriptive - FDEs now come in all shapes and sizes, from people who’ve never done software engineering before, to veteran staff engineers looking to understand their customer’s problems. We simply want to understand the stories of individual FDEs and FDE teams, as they go about bringing change for their customers and organizations. If you’re interested in a forward deployed role, or are excited to build a team at your company, or simply want to take the learnings from how FDE works into your own job, this is the place for you. Along the way, we’ll feature companies that are growing incredibly quickly using their FDE teams, and show how you can do the same.

Some things that we’re going to be highlighting as part of the FDE community include:

1. Interviews with prominent forward-deployed engineers and heads of FDE at various up-and-coming and successful companies.

2. Discussions about the meta of forward-deployed engineering: how do various companies think about it, how do they approach it, and how do they reconcile the FDE approach with the standard vanilla SaaS approach for go-to-market and engineering?

3. Roundups of what we see across the FDE community, what teams are hiring, and observations we have about how the industry is changing.

Thanks for reading! Email me (sanjay@fdeverything.com) if you have any ideas or feedback. I’m especially interested in knowing how I can be most helpful.

Subscribe now