What a forward deployed engineer does and how to become one

Transcript

Every lab that promises autonomous intelligence is hiring humans as fast as it possibly can go to sit inside companies like yours and make that intelligence work. That is a confession, right? It’s a confession from the labs about how much they need people. Anthropic said it would train tens of thousands of engineers to go install AI inside banks and airlines and insurers. Do you know how many it actually trained? 86.

And that gap is the entire story of the hottest job in AI, and it’s why this job pays what it pays. OpenAI is hiring forward-deployed engineers at up to $280,000 in base pay plus equity, and they’re not the only ones. Handshake has posted the same title at $300,000. Those numbers have a lot of us trying to figure out what a forward-deployed engineer actually does and whether they have any realistic route into the work. So this is what I made this video to help you answer.

By the end of this video, you should be able to look at the job you have now and see which part of the FDE skill set you may already have, whether you’re an engineer or not, which part you’re missing, and what you could build in the next month or so to make the case for an interview. AI is a general-purpose capability, and the last mile in AI is really hard. FDEs bridge that gap. That’s why FDEs matter.

Let’s say you run a claims operations at a regional insurance company. Yes, we’re getting specific because specifics helps us generalize principles we can all learn from. We’re going to call you Maya in this story. Your CEO has seen enough AI presentations to know that technology can read documents, and now he wants claims processed twice as fast. By the way, if you’re wondering where I got this story, I have talked to these CEOs before, and I’ve talked to Mayas before too. Now, this sounds like a clear goal from the CEO, but it’s not a buildable job, as anyone in engineering or product will tell you, because a claim might include a policy and photographs and repair estimates and medical information and police reports and fraud review and customer calls and several different approvals.

If, if our friend Maya gives all of that to the technical team and all Maya says is speed up claims with AI, Maya hasn’t done a great job and the team has to make most of the product decisions for her. Maya is a great PM. So Maya instead pulls up actual files. She takes one claim that moved through intake in a day and another that sat there for almost a week as counterexamples, right? In the slow file, the repair estimate arrived on, say, a Tuesday, but the signature page was missing. And nobody noticed until Friday.

3 days disappeared before an adjuster made any kind of insurance decision at all. And she finds much harder problems in the files as well, right? Injury claims can take weeks. Fraud review is very expensive. Deciding whether to pay a complicated claim is clearly worth a lot of money, but those cases really vary. They need a lot of experienced judgment, and a wrong decision can send money out the door or create a lot of legal exposure for an AI initiative.

The missing document problem has a very different shape. And this is where we get to the generalizable principle and why I’m telling you this story. Because you see, the missing document problem happens all the time. It sits at the front of the process and everything behind it waits on getting that right. If this company receives, say, a few thousand claims a month and several hundred, say 600, 700 arrive incomplete and each one of those loses multiple days before anybody even notices and recontacts the customer. That’s, say, 1,800, 1,900, 2,000 days of claims sitting still every month.

And here’s what kills me on that. The input to make a good decision and contact the customer and say, hey, we need more docs, that already exists in the claim packet. Any adjuster can check and get that answer really fast, and a flag can be sent out before any kind of delay happens. That rationale is exactly why Maya picks intake to work on in our story. And it’s a rationale I’ve seen play out specifically in the insurance industry before, but it’s also a little flag hint of how FDEs grab these skills and apply them other places.

So if you’re looking for a larger rule of thumb here, think about it as Maya finds a point of leverage for the AI work that she wants to do. And finding leverage is a generalizable FDE skill. In this case, Maya is looking for the point where a relatively small build moves the largest amount of work without giving the model a dangerous amount of authority. This is leverage. It’s leverage applied inside a workflow. The service only has to notice that there’s an incomplete file when it arrives.

It just points to the missing item and it prepares communication appropriately. That’s Yeah. Everything else that’s more complicated— injury decisions, suspected fraud— all of that remains with real people in our story. Now, choosing that point in the workflow, regardless of whether you work in insurance or you work in any other industry, that is the FDE skill that people are desperate for. The same month of engineering can remove 1,800 days of waiting or make a rare-edge case slightly better. Like, you’re applying the engineering either way.

A company may have 20, 30, you know, hundreds of plausible places to add AI. The FDE needs to work out which delay occurs often enough to matter, which pain point is painful enough, and which fix releases a bunch of work farther down the process. How you unbottleneck stuff. I used to do this very manually when I did Kaizen Black Belt process mapping, and you map out a process and find bottlenecks. These days you’re taking similar skills out of a formal kaizen context and you’re putting them into the real world where you’re trying to figure out how you can apply AI to debottleneck real work. And the advantage of picking work like this is that now Maya has something she can measure.

She can really quickly track how long it takes to spot missing material, how often the AI service she’s built raises a false alarm or misses a document, and how much time the adjuster then spends checking it. And the project can then be measured appropriately, graded as a success, and she can move on to the next AI project.

And so when we think of Maya’s story, that’s the kind of work I want you to picture when you hear forward deployed engineer. And by the way, if you hear that and say, that sounds really producty, that’s kind of the point. One of the interesting things about forward deployed engineers is it mixes a lot of product in with a bunch of engineering technical skills. The title can move around. At one company, it can mean a very strong software engineer who works directly with customers. Somewhere else, it may more look like applied AI or implementation or a technical product role.

But the common part is that you stay with the problem from choosing where to start all the way through the working system because you’re committed to enabling the capability inside a complex real-world environment.

Every time I have run enterprise technology deployments, and I’ve run a bunch of them over the years, they always run into the same wall. Buying the product from the sales guy, that’s the easy part. Then someone has to get access to the data and understand the policy nobody wrote down, and fit the tool into the way people actually work, and deal with the first pain point that comes back from a real customer. All of this is something we’re familiar with in enterprise tool deployment, but AI makes that job even harder because the software is no longer just passively moving data around. It might be making intelligent decisions, right? It can decide what’s missing in a document.

It can draft a response. It can take actions and write in other systems. So small misunderstandings or small pain points can travel a lot farther in the age of AI. And that brings me to FDEs. That is why FDEs are so important in AI software, because Maya has to choose where the technology can do the most work with the least potential for downstream harm. And so she has to take this big challenge around cutting claim time, and she has to decide where is the right point to apply AI to get And if she does her job well, by the time she’s finished, she and the engineers side by side can build, and the business gets really clean measurable results that it can check.

In other words, Maya is a translator. Maya is a translator from the vague large claims CEOs make, from the generalized capabilities AI models have, and she takes that larger context and applies it and translates it specifically for her codebase, specifically for her product context, specifically for her customers, so that value is realized. That’s what an FDE does.

Now, there are roughly 3 parts to the FDE job, and almost nobody starts equally strong in all 3. So if you feel like you’re behind as you listen to this story, you’re probably not. An FDE first has to understand the business well enough to find the leverage point, build and inspect the system, and then stay around after the launch long enough to learn whether people actually use it and whether the result is worth the cost.

Software engineers may find that the building part is actually the part they’re least worried about. They’ve got that part, right? But the harder move for them is getting close enough to the customer to understand why, you know, a particular document issue matters, why a missing field matters, and then figuring out how to connect the build architecture they’re working on to money and time and risk and capacity. So if you’re coming from operations, let’s say you’re not from engineering, let’s say you’re from product or, or maybe from consulting, you may have the opposite feeling to those engineers. You may know why a clean process diagram doesn’t fit the real world. You may know which exceptions matter to customers, but your work is now getting technically deep enough to actually build the solution, inspect what your AI is working on, and understand where that solution can fail.

If you’re coming from solutions engineering or implementation or even sales engineering, you’re often somewhere in the middle. You already have to translate between customers and systems. And so the question for you is whether you can remain responsible after the traditional handoff point for those roles, after configuration, after handoff, when you have to actually own the result and the bad cases start coming in and you have to change your design.

If you’re trying to practice demonstrating workflows and business judgment, I would not begin by digging into an entire job. And this is something I often see as a failure mode with PMs as well. Get specific. I would figure out how you pull the last 10 instances of the problem you’re working on, how you get some recent specific data, and then I would start to dig into those issues and understand really specifically what’s going on and why, what corrections already exist, where there are pain points in those specific common issues that you can go after. And as soon as you start to find recent issues, you’re going to start to classify them and then do some rough math, right? Differences you find across a sample of 10 or 20, count how many cases are hitting the problem, and you start to be able to estimate rough notes how much problem you’re solving if you solve some of those specific pain points.

You don’t need a perfect financial model to be an FDE person. You just need enough evidence and you need to know how to get it so you can talk specifically to the pain point, right? Because in, in our story with Maya, Maya can now compare incomplete intake with fraud review because Maya did rough math what each of those specifics are. And if you’re wondering if you can get that kind of data in interviews, typically when you’re given cases to work on, they specifically provide that type of data so they can see if you go after it.

The next step, if you can, is to sit next to the person doing the work and watch the process happen, right? One of the things that I find most valuable, that I’ve found valuable in product, and it’s a very producty thing to do, just sit next to the customer, sit next to the client, see how they do the work. A lot of what they do may not appear on the official process, and you’re going to have to learn it to effectively map the pain points. And so you may begin by classifying your 10 top pain points, and you have rough math, and you may come back after you sit with a real client or real customer and say, “Well, five of those are fake, or five of those are really a bad description of what’s going on, and here’s the real thing.” Let that reality change how you assess the problem.

One thing to note as you’re going through this process: industry knowledge has a very practical role with a lot of FDEs. And so another thing that can encourage you if you’re wondering how do I get this is look at the industry knowledge you already have, right? Like a claims adjuster can just intuitively know when a repair estimate is correct and when it’s not. A finance operator can just know when 2 reports use the same name but have different numbers inside them. A support lead can just know that one ordinary-looking sentence usually means the customer needs a person right away. You can’t substitute for that kind of knowledge.

The researchers looked at roughly 400,000 Claude Code sessions, and people rated as experts in the task reached verified success more than twice as often as novices. That domain expertise, it matters.

The second part of FDE work is technical delivery, and this is where I want people to read their job descriptions carefully because it can be scary. OpenAI is asking its FDEs to write code across both front end and back end. Palantir describes people building applications, working with data, making architecture decisions, and owning the work through deployment. That’s a different job description. Now look, if the job says production software engineering, industry knowledge in general absolutely doesn’t get you past that requirement, and I don’t want to pretend it does, and so whether you are Maya and you’re just doing a small technical version in our story, which is very much an FDE thing, or whether you’re trying to build full front-end and back-end applications, your mileage will vary. You will have to look at the descriptions because this particular job role has a really wide range of technical expectations.

Now, the good news is, if you need to learn technical skills, you absolutely can do that. There are boot camps for technical skills, but I will also say you can actually work with AI to learn front-end and back-end engineering now, and you can do so by simply practicing building small projects. It’s something that I see people in my Substack community do all the time. I’ve seen people skill up to the point where they are technical founders in 12 months doing just simple projects where they’re calling a model, they’re asking for a structured output, they’re displaying the results, they’re learning to authenticate users. They’re just going through all the steps that you do with software, and they’re just building and building and building until they really understand what they’re doing working with AI. Why does that work?

Because these days, AI engineering is not about individually writing lines of code. You don’t have to individually write the code. You have to understand how the system works and know the pitfalls and know how to get AI to go where you want to go. And that’s what matters. So you don’t have to become an expert in every technical piece before you start. You just have to understand the system in a way that gives you confidence that you can ask the model to build responsibly.

As an example of responsible decision-making. In our story, Maya’s service needs the intake documents and a small part of the claim record. But of course, you’d want to lock off payment and medical history because the model doesn’t need to know that stuff, right? You need to think about those kinds of things when you’re designing systems as an FDE.

The other thing that’s really important for FDEs that is not a traditional engineering skill, but is becoming an engineering skill and is one that all of us can learn from, is testing and evals. Because you are telling models to build things, you have to tell them what criteria to In our example, Maya may absolutely go with 50 different correctly adjudicated examples that say this is missing documents, this is not missing documents as part of her test set. And so she can then find out if the model is able to write software that passes the test, et cetera, et cetera. Eval are a key part of building agentic workflows, and constructing evals is a really important part of the engineering job these days. And it’s not, it’s got nothing to do with code. It’s, it’s key to FDE skill sets.

It’s usually considered technical, but it doesn’t have anything to do with code. You can absolutely learn it. And part of why I’m making this video is I don’t want people that have a lot of the translation skills that I’ve described to run away from the FDE role simply because they’re scared of the word code. Don’t be scared of that. In fact, in the same study I mentioned with Claude Code, the non-technical users who started using Claude Code to code got within a few points of the technical users and the engineers on the code they were able to produce. The larger point here is that you can get AI to write good code if you are willing to take the time to understand systems and willing to take the time to build good evals.

The third big part of the role here is deployment ownership. Maya can have a system that scores really beautifully on the files, and it still might actually not work in production. And so she needs to be able to put live work down to notice what actually happens and to make corrections so that what gets built is actually useful. That cycle of measuring and learning from reality and coming back and building the capability is especially important for FDEs and AI. Because what I find is that when you have an AI capability that’s general and you’re bringing it into contact with specific code and specific workflows, it is an iterative process. It’s a process where you have to turn the flywheel a few times to make sure that you’re zeroing in on where the value is actually applied.

And that is a process that has a ton of nonlinear value. In other words, getting AI to really deliver extraordinary value to save those 2,000 hours a month or whatever it is in your case, that’s, that’s absolutely the impact you need to demand and expect. And if you’re at a point where it’s saving 20 hours, for example, or 200 hours, you’re not where you need to be. And you need to look at the causes and figure out how to get the larger value that you know that you can unlock with AI. And that is not a skill that comes intuitively, except I find to PMs and engineers who index highly on ownership. Those 2 job families have been trained for a long time.

You have to own the code you put in production. You have to own the impact to the customer. It’s the same mindset with an FDE.

Now I’m going to give you some clues on the job description next, because like I said, there’s a whole range of them and I want to give you a sense of what works and what doesn’t for different skill sets based on my analysis. So if it’s forward deployed engineer, forward deployed software engineer, those usually have the highest coding expectations. Applied AI engineer, customer engineer, solutions engineer, implementation engineer, technical deployment lead, AI operations, and AI product jobs may contain a lot of the same work but a different technical balance. And so you can look at those if you really want to get to FDE as skipping stones along the way. Like, you can hop along and get to FDE by taking some of those adjacent titles.

Now let’s turn this into something that you can use specifically. If I were trying to prove skills around FDE over the next month or so, the first thing I would do is I would pick a recurring process that I can actually observe in detail. And I would need access to a few people who do the work, and I would need at least 10 or 20 completed instances that I can go through and see how the work ran. During the first week, I would actually pull as much real work as I can, and I would reconstruct what happened. I would try to understand differences. I would try to classify issues.

I would try to start to find the leverage points, right? Then I would talk to the person who’s doing the work. I would sit there. I would sit next to them, which is what I described, and I would figure out from that lived experience where the intervention points that I’ve mapped out are likely to be most impactful. Where is the leverage, but in real life sitting next to a person? And I would use that understanding to start to do back-of-the-napkin math so that I can figure out the impact, because FDEs have to have that business impact.

And by the end of that second week, by the end of sitting there observing the person, I should be able to say very, very clearly, This is how much work I’m, I’m gonna save. This is what I’m doing, and this is why it matters. And if you’re like, wow, 2 weeks is a long time, I have seen people speedrun this in 2 days. People can absolutely, if they’re experienced, dive into the data and sit with someone for a day, and they’re done. It may be your first time, so give yourself a minute. And whatever the answer is, the scale and the safety of the intervention should be visible before you build.

You should be able to say, this is why it’s going to have an impact, and this is how I’m securing the guardrails, right? The point is to keep you from asking AI to invent a product before you understand the real person. AI is really good at inventing stuff. You got to understand the actual pain point.

Now, get started building from there. You want to start to build the simplest possible solution, and I do mean build actually get to code. Work with your AI agent and figure out how to build a solution that solves for the leverage point you’ve identified. I have written a ton on Substack about enterprise implementations and guardrails. I would recommend going there if you don’t know where to start, but you can absolutely dig in, understand typical expectations around permissions, typical expectations around data, typical expectations around authentication, authorization. Take those seriously, even if this is just an exercise, because FDE deployments are almost always in enterprise contexts, and you have to understand how to work with enterprise workflows, enterprise logins, enterprise decisioning, enterprise IT teams.

Those are decisions you will need to explain in interviews.

Now, once you’ve built the system, you need to start trying that system against those old cases. You should be doing that by the end of the 3rd week. You should be able to like try clean cases, try ugly cases, whatever it is that’s actual work, run it through your loop, run it through the thing you’ve built, look at the failures, rerun them after every meaningful change, sit there and make it work so it works locally on all of your test cases. This is where that evals piece comes in. Finally, in week 4, let 2 or 3 people use it while you watch, learn from them, and fix the loop. That’s really the key.

That’s that last part. That’s that ownership part. And again, I have seen people speedrun this whole process in 3 or 4 days. It can be much, much faster, but I’m giving you a chance to dig in if it’s your first outing at this Finally, you want to actually summarize the impact you had. That’s the last piece. However long it takes you, you should be able to say, I came in, I sat down, I saw how real people worked.

I mapped out the problems. I built this to fix it. When I built it, I was able to put it into production and actually get it to work at enterprise grade. That’s the whole FDE skillset right there.

Now, if you would like a place to start, I put together a companion FDE skill builder that has a self-assessment for It has that 30-day project brief. It has a portfolio checklist. And I’m also going to link to my AI jobs guide and the full interview guide so that you don’t have to turn this video into your own curriculum. I also think that this is a particularly good use of the Substack community. Lots of us are there building and trying interesting stuff. I would recommend posting a real workflow in the place where you’re stuck.

You might say, hey, vendor applications arrive through email. Half of them are missing one of 4 documents. Here is what I’m trying to solve for, and here’s where I’m getting stuck. And people will just jump in. Like, I’ve seen folks come back and just jump in. It’s a really sort of rich experience that way.

So where does this leave us? We’ve talked about training. We’ve talked about your first 30 days, resources that I have in my community. Ultimately, this is a job that is growing exponentially. There are a few thousand FDEs now, but there’s demand for tens of thousands or even hundreds of thousands. Anthropic recently announced that DXC will train tens of thousands of existing engineers as Claude-certified FDEs for banks and airlines and insurers and manufacturers and government agencies.

And I think that the starting point here is interesting to note, right? DXC is taking people who already work inside complicated systems and adding AI training tied to those industries. You can use the same approach for your own career. Remember I said domain knowledge matters because the background you bring to the table is actually really important as a forward-deployed engineer. Your industry context matters a lot. If you’re deep in healthcare, don’t try to jump over, right?

If you’re deep on manufacturing, don’t jump over. That’s where you’ll be an FDE that’s most effective. And if you’re in a company and trying to figure out how to sort of jump to FDE, I don’t think you need to wait for a title. All you do is need to find that piece of work, show that you can solve the problem with AI, and you’re going to start working your way there.

Do you want to know how I know that? There are people in my community that come up and buttonhole me at my happy hours, and they’re like, Nate, look at where I got, right? I got to an FDE. I got to an AI engineer title because I did exactly this, because I jumped in and I started solving problems with AI. That is the way forward, and that’s why I talk about it with such confidence. I’ve seen it happen over and over and over and over again.

You can do it too.

I hope this has been helpful. FDE is going to be a dependably hot job for the next few years. This is not just a fad. The reason why is really simple. AI is a general-purpose capability, and the last mile in AI is really FDEs bridge that gap. That’s why FDEs matter.

If you’re an FDE, let us know in the comments and let us know how you got there. If you would like to be an FDE, drop the project you’re working on in the comments or head over to the Substack and share what you’re working on. We’d love to hear about it. All right. Cheers. Cheers.