FDE: The $1M/Year AI Job Explained

0:00I know it's crazy, but there are people making a million dollars a year as Ford deploy engineers. But what exactly is an FDE? I know you've probably seen it, but I feel like a lot of people aren't clear as to what it is and how they could become one. Well, in this episode, I brought on my friend Voss. And Voss is a leading expert when it comes to FDEs with his company Varick Agents. and in this episode he gives you his entire playbook how you could become an fde in 30 days now this episode is for people who want to become an fde but also for people who are just interested in what it means how they can actually use fdes in their business to be make more money to be more productive and i just think this is the clearest episode the clearest piece of content on the internet, the clearest masterclass for how to understand clearly what an FDE is, how you could become one, and why it matters.

1:02Enjoy the episode, and I'll see you at the end.

1:13Voss is here, and Voss, by the end of this episode, what are people going to learn? They're going to learn exactly how to break into forward deployed engineering or become a better FDE in 30 days. The full roadmap for AI forward deployed engineering. I don't feel like this has been shared anywhere. I feel like the term forward deployed engineer is just on my X feed everywhere. So what I'm hoping for, Voss, is for you to clearly explain what this means and just all the concepts to it and just break it down for me in a clear, easy to understand way. so I could learn from it, but so others can learn from it too.

1:55Absolutely. And there's a lot of different definitions. Everyone has their own, and I'm going to give you what I think is the clearest explanation. Okay, let's do it. Sweet. So yeah, this has never been shared before. This is something our team put together. It's how to break into FDE in 30 days. Let's start off with recent developments and the facts of today. The reality is every company can now buy intelligence. You know, you have a frontier model being released every single day. Just yesterday, we had Kimi 3 being released. Last week was Fable 5, you know, or GPT 5.6 Soul. Every company can now buy intelligence.

2:29And the reality is intelligence is becoming commoditized. So the same foundational capability is becoming available to anybody who can pay for it. And that's most companies today. So you'll see here is a graphic where every company has access to the same foundational model. So if everyone can access it, intelligence can no longer be the mode. I think there was this huge theory that people will be priced out of intelligence and that could be the case in the future. But the reality is today, everyone has access to the same tools. If you go and talk to 50 different enterprise clients, they're all using the same stack.

3:04They're all using Cloud Code, Codex. They're using Cursor for model agnosticism. They're using GitHub Copilot. It's all the same thing. So the reality is everyone has the same capability in terms of what intelligence tap they have access to. So where does the advantage go? It goes into deployment. So the edge is no longer who has the intelligence. It's where, how, and why they use it. And that is the role of an AI forward deployed engineer. It's allowing companies to harness and take advantage of AI intelligence or software previously to make sure that they apply it the best to their specific company context.

3:42Every single company is different in terms of how their business is structured, what processes they have, how things run, etc. And the job of an FDE is to make sure that the intelligence, which is general, is specifically applied to this company in a way that benefits them the most. And the advantage will start to become who has that best bridge, that connection between their own processes and the intelligence stack that they have access to. And Voss, this was a term that, correct me if I'm wrong, was popularized by the Palantir team, right? That's right. So can you tell me about how Palantir works with FDEs?

4:25I mean, I feel like for a lot of people, Palantir is this black box. Can you go a little more into that? Yeah, it's funny. So I lived in New York for a few years and I had a ton of buddies who are Palantir Forward Deployed Engineers. So I have a little bit of insight into this. Without sharing what I think of proprietary, Palantir has an ontology. They have a software stack that they work off of. And this is full of connectors to software, but also data lakes, which allow enterprises to pipe their data into a unified interface. And what Palantir FDEs then do is they'll actually be deployed on site.

4:56So this is either like enterprise customers or the military, the government. and learn their workflows and then spin up kind of workflows, dashboards, you know, agents that will solve the problem for these companies. So Palantir really popularized the idea of essentially what was consulting, but from the software space, they coined the term forward-deployment engineer and it really started to allow their business to take off. They had a centralized platform, but its beauty was not in like how tech forward it was. It was it was in how customizable it was. And then these forward deployment engineers would go on site, customize it for a client, and it would really solve their pain points better than a generalized service.

5:36Cool, and I guess the thesis is that if it works for Palantir, it can work for everyone else, right? That is sort of the thesis, yeah. Palantir, I think, really solved it when it came to the data age, where you wanted to unify your data sources and then visualize it in more unique ways. I think the AI age is going to demand that 100 times more, where every single company is going to need customized agents. And that's actually what we're here to solve as well with our OS. But everyone is sort of coming to the same realization that forward deployed engineers are a massive reason why AI is going to be powerful for businesses.

6:14Cool. Let's keep going. Sweet. So someone has to decide where intelligence belongs, not just where it's applied. And that person is a forward deployed engineer as well. So there's kind of three stages to afford to put engineers involvement at a company. The first is understanding the business reality. So it's how the work actually happens today. And I think this is the part that gets glossed over by people who are, you know, very deeply in tech. You know, in Silicon Valley, we have a mindset where like, OK, well, the beauties in the software, like it doesn't really matter what the business processes are.

6:44But I can tell you firsthand, every business is so different, even in terms of like the same process across multiple businesses. Let's go like accounts payable, for example, or sales, for example, at two different companies. The way that they do that is so different. One has a 10-step process. One has a 30-step process. One is using Salesforce, Gong, and Chili Piper. The other one is using HubSpot and Apollo and Clay. There's the software differences, but there's also the process differences. And there's the things that matter most to the business being very different. when things go wrong, like exception handling, the way that that's being done at a company needs to be documented as well.

7:27So forward deployed engineers go on site. They'll either interview people or just observe them work or get access to their systems like their ERPs, their CRMs to figure this stuff out. And this is where the bulk of the time goes, in my opinion. It cannot be understated how important this is, both in terms of understanding the business, but also to bring that business along the journey. and this is where communication and analytical ability is incredibly important for a forward-to-put engineer. The way I like to think of an FDE is the best combination of someone very deeply technical who can understand it, but also someone with fantastic communication ability and the ability to get the information out of people that they need to.

8:09And this is all-encompassing for business reality. And you say the FDE goes on-site. when you say on-site, is that literally walks in the office and starts speaking to people and stuff like that? It can certainly be done remotely. There's certain times where that's required because the company itself is remote or the people at the function are not all in one office. But I will say a large majority of the time it is on-site. I know that Palantir does this very heavily. we do this as well and it's not just because you know you can't get the information remotely but it's it's actually more so because the relationship that you build with the person like you know you're on site you're part of the team you'll uncover far more information that way right like if somebody will if you schedule a one-hour meeting for example somebody will walk you through what they think is the job but if you're on site with them for the full eight ten hours whatever it is you're actually experiencing the job.

9:12Like when something goes wrong that's not really documented in an SOP or in a Word doc or a Google doc somewhere, you're going to see that play out. Even consultants at McKinsey, they do this. They'll go on site to a mine and they'll sit with the miners and they'll watch them do their work because it's so much more powerful to establish that relationship and get the information that way. Cool. Yeah, the second step is FTE judgment, which is where does intelligence belong and where does it not? I think when the AI wave first started, we saw a lot of, you know, let's just slap AI everywhere. Let's give everything to the model and let's let's let it figure it out.

9:49And this is what led the token maxing and hallucinations. And you have the MIT stat that 95 % of generative AI pilots fail. Again, now the industry is sort of shifting gears and they're realizing that, okay, we actually need to be very selective about where we apply this intelligence. And we also need to be selective about how we design the new stack for this intelligence to play out. So again, for example, you have a 10-step workflow. It might be that that workflow should not be changed by AI. Maybe it's too risky, or maybe it's not high enough ROI. Maybe it's already pretty automated. Why do we need to bring AI into it?

10:27It also could be that of those 10 steps, only three of them actually need judgment, right? So categorization of this, you know, lead in a CRM tool, that might be a little bit more non-deterministic. So we're going to bring in an LLM there for judgment. But the rest can be solved with, you know, if, then, else statements. It can be solved with API calls. And this sort of judgment is actually, you know, far more complex than I'm making it out to be even, but it belongs with the FDE. So the FDE both has, again, the business reality, which is the consulting style, like communication style approach, but also the technical judgment so that they can determine based on their technical background, okay, I think that this design is going to be risky.

11:11We're going to have 80 % accuracy. It's not worth it versus this other workflow will have a much higher ROI. We'll be able to build it much faster. It's lower risk, et cetera. And that sort of back and forth judgment is where an FDE really shines. It's bridging the gap between the business and the technology. If someone listening to this wanted to become a Ford-deployed engineer in New York City that's doing this sort of stuff, how much money could they make? A lot of money. You have no idea how expensive it's gotten, both from a we're hiring perspective, but also in terms of what the market's demanding.

11:47This is the hottest role in technology right now. You could make anywhere from$150 ,000 base with considerable equity. to I've seen the roles go up as high as a million dollars a year, and I'm not joking. These are extremely well-compensated roles if you are the best combination of consulting and technology. Cool. Deployed AI system, finally, the last step is actually going out and building the software itself. This is where it varies wildly company by company. For example, at Palantir, even, they have some FTEs that you're not actually writing code. You're mostly spinning up workflows, is like text, you're chatting with the software of the Palantir Ontology to create like some dashboards and to the extent that you're writing code, it's SQL.

12:32But there's other companies where you are fully writing like production code, either onsite with a client or you'll go back and do this, but it varies wildly. So there are some FTE roles where you're going to be writing production code. You need to have a background in software engineering and like really be confident in your ability there. There's other FTE roles where it's far more technically light and you can chat to build on top of an existing platform. So this is the part that varies wildly. But either way, you need to have a very good understanding of the software because when the client has an issue with, hey, this doesn't work right or we have an issue in production, it's basically your ass on the line.

13:10And you have to know who to call, what to do, and how to fix it. In summary, FDEs are in demand because they control how intelligence enters the business, how it's used, and that is where all the value is today in the AI age. Everyone is coming to this consensus and that's why FDs are extremely valuable. Well, it's also in demand because it's new as well. There was super intelligence on tap five years ago. So not only is the idea of super intelligence on tap just absolutely absurd, many trillion dollars of money is going to be changing hands over the next few years, but the idea that now you need a person to actually, people are realizing, hey, you actually need judgment and hey, you actually need to be a systems thinker and hey, actually token maxing isn't the best strategy.

14:05There was a moment in time where token maxing, people basically were agreeing that token maxing was the strategy. It was just like, hey, these models are so good, let's just let them do their thing. That was the thinking. Yeah, that was a funny period in time. I would argue we're still not fully out of that. But yeah, you're totally right. I mean, this is a brave new world for everyone involved. And I mean, I have horror stories of people, of like C-suite executives I've talked to who have blown through their entire$10 million clogged budget in like three months. It was supposed to last them a year because they gave it to everybody.

14:43It's token maxing and everyone's spinning up whatever they need. And the sad reality is it didn't really move the needle for the business either. And it's because that business didn't really invest heavily into forward-point engineering. And so I think you're totally right. Cool. Let's keep going. Sweet. So we've already alluded to this pretty heavily prior, but I want to really make sure I hammer down this point, which is that there's two streams of kinds of judgment that are required. And it's very rare in a single person. So I think the unfortunate reality is, and this is what's going to happen, and it's already starting to happen, is as we go from the token maxing, let's go all in on token maxing, go, go, go, to now the same thing on FDE, let's go, go, go, let's hire a bunch of FDEs.

15:29I want to be very clear about what the role really demands. I think there's a lot of FDEs who are, unfortunately, neither the best communicators and neither the best software engineers. I would strongly urge them to strengthen both of those skills. It's both the understanding of workflows, cost, incentives, risk, adoption, business value, the politics of the internals of a company. These are all things that you have to manage. And consultants here are incredibly strong. You'll talk to McKinsey engagement managers, BCG, Bain engagement managers. They'll be very good at this side. The other side is what they might need some more support in.

16:04And same thing, software engineers will be very good at the right side with models, systems, APIs, data, code, reliability, evals, guardrails, you know, more AI-centered terms, harnesses, post-training, fine-tuning. These are things that are more on the technical side of the aisle, and software is really very good at this, but they need to also then kind of drift towards the business side by understanding the left side of the aisle. And FDE is the best combination of both of these. It's not an average combination. It's not the worst combination of both where you're not the best communicator but you also can't code it is truly the best of both and that is the million dollar hire where the FDE can turn business understanding into working software end to end they can do both sides perfectly yeah I mean put another way it's like if you understand art and you understand science and you can speak both you have what it takes to become the million dollar FDE the hard part is like usually the people that are good at science are sort of good at science.

17:06And the people that are good at art are kind of good at art. But there is some overlap in the Venn diagram. Absolutely. And that's why it's such a rare role. But I also firmly believe, and that's kind of the whole point of this presentation, is that you can become this. It's not out of the realm of possibility to become much better at both of these things. It's just, you need it cleanly laid out. You need a roadmap. And that's what I hope that I can provide by the end of this call. Cool. All right. All right, Voss. Let's go. So firstly, for example, it's understand how the work is really done.

17:43Because the documented process is very rarely the real process, right? So an email might arrive. Now, this is extremely simple, but the reality is it sounds like a clean trigger, but it's far more complicated than that. It arrives from 40 plus senders. No two of them are formatted alike. The data is different. Some of it's in a PDF, some of it's in a screenshot, some of it's in an Excel spreadsheet, or it's buried in a forwarded thread. It's far more complex than it makes it out to be. So if you didn't look into this, if you weren't an FDE and you just asked the person for, hey, what's the first step of the workflow?

18:15They'll tell you when email arrives. And all of a sudden you're building for a system that doesn't map to reality versus the reality, which is that it's so complicated. And half of them are exceptions. It's the same as last time, and ignores the second attachment. Sarah already signed off on this one. There's no consistent subject line. So you can't route without actually going into it. And usually the reality of how to play this is in one person's head. So one person will know like, okay, yeah, well, when I see this email from this person, I'll send it to this vendor or to this part of our procurement team.

18:45But that's not written down. And if you don't sit with that person and kind of coax this all out of them, they're not gonna remember to even tell you. You would think about like at your job today, I asked people viewing this, is how easy is it for you to really write down every single exception that might happen in your job? I was a software engineer at Meta, and if people asked me for my job, I'd say, well, yeah, I code all day. I'll get a task and I'll work on it. But that's not the reality, right? The reality is I have meetings, you know, this happens, something breaks in prod, I have to go fix it.

19:14That's what we're getting at here. The second step is, oh, it's copied into a spreadsheet. Same thing here. You get the idea. One's a real one, two are stale, data validation. It's rekeyed by hand, columns drift, same thing with checking into an internal system. I won't get into all of this. You get the idea. Every step is extremely complicated. So that's what understanding the work really means. It takes time and it takes effort to sit with a person responsible and sometimes multiple people responsible. Usually, usually it's multiple people. Very, very often. Yeah. I mean, if this company has like 5 ,000, 10 ,000 people working in it, chances are you have a lot of people working on the same thing.

19:51Then you decide how the work should operate when intelligence is built in. So again, where does deterministic software live in? Where does the agent act? Where does the human approve? Where does the record get updated? I think the best combination of, sorry, the best solution of AI for most companies is a very good combination of deterministic software. Probably the majority of it is that, but then obviously the judgment that API calls to LLMs can provide. And finally, human in the loop. So this is just a fancy little digest, but it's really the agent that can then be deployed into existing systems.

20:24It's doing the first half, which is intake validation, agent drafting. Then you have a human in the loop for approval. It's something that I strongly recommend my FDEs to push for in an agent implementation. Once you get approved, it'll then go through the latter half of the steps. And that's what you're building. So the job of an FDE, when you're building, has three parts. It's obviously auditing, then creating evaluation suites to make sure the system behaves correctly. This is extremely important in the AI age. And then finally deployment, which is both hand-holding the client to make sure that they're adopting it, it's working well for them, but then also the software side making sure that nothing breaks.

20:58You're monitoring all the metrics that matter, you're monitoring KPIs, SLAs, and everything needs to be top-notch for somebody to really trust you as an FTE. And every stage is a prerequisite for the next. So for an eval, so prove the system behaves correctly. So in a scenario where the outcome is non-deterministic, meaning it's tough to say what success looks like, how do you create an eval? Or can you create an eval for more creative tasks or tasks that are hard to understand if it's successful or not? Yeah, obviously for more non-deterministic tasks, it's much harder. It's much easier to say, okay, was this email categorized correctly because we have 10 ,000 previous emails to go off of and it'll be the basis for our eval set.

21:48But even for tasks where it is non-deterministic, like for example, creating a presentation, there's a million different ways to do it. And sort of the beauty is in the eye of the beholder where one thing looks good to me, it might look bad to you. Here, it's very helpful to have as much previous data as possible. Obviously, if you have 5 ,000 previous presentations to go off of, it makes it a lot easier to create this golden data set of what we think matters. You can say, always put the logo in the top left, always have larger font of the styling, et cetera, et cetera. But this is obviously where you'll never get to a perfect result with just evals.

22:26You need human-in-the-loop feedback to make sure that going forward, you at least have a feedback mechanism that improves your harness, if not post-train or fine-tunes the model that you're working under. so on one hand get as much data as you can and determine what looks good, what looks bad identify what matters to you but also then always bake in human-to-loop feedback because even with a good data set even with good evals you'll need to have them constantly improved and that's where that feedback mechanism comes into play And I've noticed in this entire presentation this entire podcast we haven't really spoken about which LLM to use Are you basically agnostic in terms of working with Anthropic or OpenAI or Google?

23:12If you're an FDE, basically, how do you think about which LLM to work with? Yeah, great question, actually. Something I probably should have touched on. We as a company are extremely model agnostic. So we think our value lies in our ability to be switching from one model to the next and making sure that your accuracy only improves, your cost only goes down, and you're not marrying to one intelligence provider, which we think will be an asset going forward. You don't want to monopolize your intelligence, your inference layer. That being said, if I was an FDE today or if I was trying to become the best FDE today, I would stick to one model and one agent-building platform.

23:53OpenAI has one, Claude has one, Agent SDK, et cetera. Every single model provider has one. Get very, very good at one of them because that will be the foundation that you then, let's try out Claude tomorrow if I'm already good at OpenAI's Asian building platform. Okay, I feel more confident about that. Let's go to Kimi3 or GLM 5.2. Let's see what the open source models can do. Let's build a proprietary harness. That's how I would go about it. But I wouldn't really worry about being model agnostic when you're starting out as an FD because that's again, not where your value lies. Your value lies in how good are you at understanding both sides of the aisle because that can then apply to any model.

24:29Totally. And we're getting to a point where the models are very similar in a lot of ways. Yeah. And a lot of the big players, like Google will have their frontier model, but they'll also have an open source model, for example. And so now you're getting to this place where it's like, okay, you can play with their open source model. You can play with their frontier model. And so I expect that the arrow of progress around LLMs is they're going to have a bunch of different products for you to play with. So, yeah, I agree. Like, if you want, you know, pick an ecosystem, bet on an ecosystem that you believe in for whatever reason.

25:15Be the best at that ecosystem. And then as you become the best, then it's like, OK, if you want and you're working with a client, for example, and for whatever reason another model makes more sense, then great. You can go and recommend that. Absolutely. I would say that's exactly right. And then just to really hammer the last point in, your ability to determine what model is best for a task relies on your understanding of various different models. You're benchmarking them along the way, but to your point, don't put the cart ahead of the horse. Really get good at one before you then try to venture out and make that understanding.

25:54I would totally agree. Yeah, I mean, that's like, yeah, you don't want to hammer a specific model when you don't understand what the system and the set of tasks are. It's like the equivalent of you're a waiter and you just hand someone a glass of Pinot Noir and they're like, I didn't ask for that. A good restaurant has a sommelier and sommelier's job is to understand what is your palate do you like dry wines do you like wines from