The Forward-Deployed Engineer

Live from Schenectady, New York, it's the Metrics Brothers, Growth and CAC.

And I'm Growth, better known as Ray Wright, founder and CEO of Benchmarkit.

And I'm CAC, better known as Dave Kellogg, EIR at Balderton Capital, independent consultant, and the author of Kellogg.

And together we are the Metrics Brothers.

And we go together like sails and military metaphors.

Ah, we're going to do a little Sun Tzu, The Art of War, tied to sales strategy today? Or maybe Leadership Secrets of Attila the Hun, which I know is one of both your and my favorite books.

I didn't know you liked it too. Yeah, my management style has sometimes been compared to Attila's, but I'm leaning more in the direction of military metaphors around sales and go-to-market today, Ray.

Things like beachheads, flanking Yes, even everyday words like campaigns, targets, beachheads, and launches— and we said beachheads again— are all based on military metaphors.

They are indeed, Ray. And we're not here to play word police today because I know some people don't like the military metaphors. We're just going to first observe that they're all over go-to-market today, um, already in fact. And today we're going to talk about Yet another new one, or a new one, the forward deployed engineer, or FDE.

You know, I've been hearing about FDEs and also FTEs, but FDEs more of late. And I think about 2 episodes back, when we reviewed the iconic State of Software 2025, they actually included a slide on the rise of the forward deployed engineer.

They did, Ray. And the reason Ray and I are both saying FDE as opposed to FTE is because one sounds like the other. So if you hear this for the first time, you may be confused. Um, but yeah, Ray, in ICONIQ's State of the 2025 Software Report, they did include a slide that talked about the rise of the FDE. Um, and basically it showed them growing 10x year over year, roughly. It's about a 15-month period from like 20 companies looking for them to 225, and from about 30 vacancies to 375. So greater than 10x growth. This is clearly a hot topic. But before we dig into the forward-deployed engineer, let's hear a word from our sponsor.

The Metrics Brothers is proudly sponsored by Benchmarkit, the B2B AI and software industry's largest, broadest, and most contextualized benchmarking index. Dave Kellogg and Ray Groth Wright have put the Metrics Brothers podcast on hiatus for the remainder of 2026. All episodes we have ever recorded are still available on your favorite podcasting app. You can reach Dave @kellogg and Ray on LinkedIn @rayreich. Thank you so much for listening to the Metrics Brothers podcast. Okay, Dave, let's start at the beginning. What is a forward-deployed engineer?

Sure. So, basically, in short, it's a software engineer who works directly with customers. There's a number of posts written about FDEs that we'll talk about today. One is from a guy named Sandeep Teki, and I like his definition. The FDE represents a fundamental reimagining of the technical role in high-stakes enterprise software environments. At its core, an FDE is a software engineer embedded directly with customers to solve complex and ambiguous problems. What do you think, Ray?

Well, so it sounds like it is a true software developer that goes out to a customer engagement. They write code specific to that customer's requirements, but it could be code that's repackaged into the core product. Is that right?

Could be. You're adding some distinctions there between kind of application-level and system-level stuff. But yeah, I think it's important. They are probably first and foremost a software engineer, like somebody who you might hire in your engineering organization, or somebody who just graduated with a master's from Carnegie Mellon in computer science, right? So, they are very much engineers and they are forward deployed. So, one question that comes up quickly here, Ray, is— and by the way, we're going to spend most of this episode talking about what the job is, because at the very end, we're going to cover how it affects metrics. Because I don't know if this thing affects your CAC ratio, Because I don't know whether sales expense is included, and I don't know if it affects CPP because I don't know how it hits gross margin, if at all. So we're going to spend most of the time today talking about what this job is, drilling in, and then hopefully at the very end we'll have time to say, okay, now that we know what it is, here's where you put it. So one of the questions is, is this just a new name for post-sales consultant? Do I just update all my spreadsheets to change the department name And I'm done. That I used to just have post-sales consulting and I now say forward deploy engineers and nothing else changes. Is there more to it than that? What do you think, Ray? Old wine in a new bottle or is there something more?

I think there's something more there because, you know, I used to have these technical implementation consultants and they would do not only the software deployment, maybe they did some integration. Sometimes we even did some script language, et cetera. to make it work in a specific way for that environment, but they were not engineers. They were lightweight engineers, but we also very seldom did we take that code and bring it back to the core R&D team.

And that's an important point, Ray, because in— and look, there are many variations on the FDE model. So, just getting the name isn't going to tell you what your org is doing. But in many of the variations, in my favorite of the variations, these people have source code access to the core system and can check in and check out code. So they're very much system-level software engineers. They're not kind of building application-level templates that people are reusing. So, and that to me is a key distinction between professional services as traditionally defined, because look, PS people would reuse work from prior assignments. They'd reuse documents like statements of work, right? And they'd reuse code and templates. This is more than that. Now, the term, Ray, is military in origin. So, we opened up talking about military metaphors. And the reason I did that is because forward deployed is certainly a military metaphor. In the military, it refers to positioning troops, equipment, or facilities in a foreign country. So, they're not here, they're there to maintain an enduring forward presence, allowing for quicker responses to regional threats, and serving strategic goals like deterrence and power projection. So forward-based units are strategically placed to reduce response times and demonstrate commitment to allies. So that's where this word comes from. We're moving engineers who are normally not on the front lines, right? They're normally back deep inside corporate headquarters, and we're forward deploying them out with the customers. Thoughts?

Well, I just say this has to remind me of my favorite comedian ever, George Carlin. And I don't know if you've ever heard his bit on football versus baseball.

Mm-mm.

Where football was like a military operation. We're gonna get on the gridiron. We're gonna have an aerial assault downfield led by the field general. We're gonna march downfield to the enemy's territory versus baseball where they played in a park on a diamond and we celebrate when a player is safe and the goal's to get home. So sorry I took us off path, but it does remind me of the military metaphor versus the baseball metaphor.

Yeah, that's funny. And this is clearly in military metaphor country. Where did it come from? It came from Palantir, who started out doing a lot of government defense and intelligence work. In the early days, they actually called them deltas. I'm guessing that that derived from Delta Force, but I'm not sure. So yet again, more military stuff. And this is not a new idea, Ray. I wrote a blog post, get ready for it, 14 years ago. I wrote a blog post called Why Palantir Makes My Head Hurt. And in that post, I discussed the forward-deployed engineer. So this idea is at least that old. Palantir had probably been doing it for 2 or 3 years before that. And I would say, by the way, that the overall conclusion of that post was that Palantir was a new kind of services firm. PS firms always dreamed of driving up gross margins by getting reusable software assets, right? And selling the solution, but making it less work because we were capturing more and more in software. And I think Palantir did that. They kind of broke the code on how to do that. They weren't just a body shop. They hired one, incredibly smart people, kind of this recruiting at the same level as Google and Meta, right? They were at all the top schools recruiting engineering majors into these jobs. And then capturing that kind of field-learned knowledge into the software product slash offering. Because one of the interesting things about Palantir is they don't break services revenue and software revenue. There's no distinction. Hey, at Palantir, we just got revenue. So, you can't tell what's coming from the software product and the extent to which it's packaged versus how much this is coming from people. So, I really, I believe now, as I believed 14 years ago, that Palantir is a new type of services firm. Today, this is sometimes called services-led growth. Andreessen Horowitz has done a post on that, kind of the opposite of product-led growth. And I'll come back to an example in a minute. But what do you think, Ray?

Well, the only thing I will say is if they're a new age services firm, they've really created a an amazing model because last quarter their gross margin was 82%. The last 12 months it was 80%. So those sure sound like software margins to me.

Yeah, and that was always the goal, right? The grass is always greener. Every services firm wanted to deliver solutions but have software-like margins. And once again, back to my theory that Palantir is a new type of services firm that, by the way, is very technical and has a very advanced quote-unquote product But the product revenue isn't broken out, right? If you look at Snowflake's revenue, I, I know they call it product revenue. They don't call it subscription revenue because it's, it's not technically all subscription, right? It's credits and overage units and other stuff. At Palantir, they just call it— even better yet, they just call it revenue. Um, and we know in that revenue is a mix of technology and services, and you can't tell how much because they don't break it out. So Um, I'm going to skip the example we talked about earlier, Ray, and just say, as we start talking about places to get information on what an FDE is, one of the good places is Reddit. You can have a lot of fun on Reddit. And on Reddit, they offered this definition of an FDE. You're a solutions engineer doing consultancy work, but Palantir loves cosplaying with the military aesthetic. So this is what I would call a cynical view on the FDE, but many people hold this view too, because Palantir does love to kind of cosplay with the military aesthetic. Um, but I think they're a little bit more than a solutions engineer doing consultancy work. Um, and I'm going to kind of move into where could we learn more about those distinctions, because really we could rabbit hole for 20 minutes on You know, basically doing what Lenny did in one of his blog posts called, What Are Forward-Deployed Engineers and Why Are They So in Demand? And he's got a bunch of Venn diagrams that kind of intersect solutions engineer versus solutions architect versus product engineer. And he's got a bunch of these on his blog. So rather than do that, I want to direct you to 2 places, well, 3 places. One, to Reddit, just say Reddit FDE. To a blog, Lenny's blog is called The Pragmatic Engineer, to go there and find a post called— oh, it's actually not Lenny, I'm sorry, take it back, it's Gergely. I mixed these 2 blogs up, but I'm probably butchering the name. It's G-E-R-G-E-L-Y, Gergely Orzózs, and the name of the blog, which I can pronounce, is The Pragmatic Engineer. And the post is called, What Are Forward-Deployed Engineers and Why Are They So in Demand? And that post is the one that does all the Venn diagrams between software engineer, forward-deployed engineer, solutions architect, etc. The other post I want to refer people to is one from Sudeep Teki, who we talked about earlier, and that blog post is simply called— Teki is spelled T-E-K-I, and the blog post is simply called Forward-Deployed Engineer. And those 2 posts plus a Reddit search will get you a lot of the nuance in this role. Ray, did you have any thoughts on the nuance before we kind of dive into the next topic?

No, no real additional thoughts there. I'm just kind of wondering, you know, if Palantir has been doing this for so many years, why does it seem to be like the hottest new trend and word that everyone's talking about? And a lot of times around the concept of native AI software companies.

Yeah. So, so, so given that this idea is not new, it actually kind of makes it even more interesting, right? Because if you thought it was new, they'd be like, oh, there's a new thing somebody just thought up. Um, and it's not a new thing. It's been around for, you know, decade and a half. So what's going on here? Did this thing just fall into fashion or is something else going on? And I have a 3-part answer to that question, Ray. One, first we need to confess that Silicon Valley does love fashion. From words to concepts, fashion runs through Silicon Valley. You know, Jevons paradox is all the rage these days. It's been around for 160 years, uh, but, but only in the last year or two is everybody from Sam Altman to Sundar to everybody else to us at last week's episode Uh, talking about Jevons paradox, right? So things don't need to be new for Silicon Valley to love them. Sometimes old things fall into fashion, and FDEs fit in that category. Second, I think something else is going on as well, which is Palantir, in my opinion, found a way to hire highly talented people to do a lot of what we used to call post-sales. And they can— and they did that by hiring engineers, so people with CS majors from top schools, Calling them engineers and then just sending them out to customers. And while rotation was not a big part of the early model at Palantir, I don't believe it was. They can— it can be. Maybe in the very early model it was. So, but in any case, while rotation is not necessarily automatically built into the FDE model, in the models that I like, it is. So you're actually rotating engineers. These are people who you could have hired to just stay in the engineering org at home and build software. But instead, you're sending them out to the field to work directly with customers. And that enables you first to send out some of your best people to make customers successful. And second, for them to take what they learn doing that and put it directly into the core system. We're not talking about application-level templates here. We're talking about the product itself. And by the way, in general, software companies stink at that. Let's be clear. Software companies are not good at taking field-learned technical knowledge and packaging it up. And then finally, Ray, the third thing going on here is that AI did 2 more things to things. So one, we do love fashion in Silicon Valley. 2, Palantir cracked the code on a problem that just got a lot more relevant because of AI. And if in AI you're going to be selling outcomes, as we talked about last week, then delivering outcomes matters more than ever because you're pricing based upon them. So the last mile just got real important. So given that we don't make money unless the customer makes money, let's go send engineers on site to make sure they're successful. And so that's what I think is going on.

Yeah, I think there might be one other variable, and there's probably a lot of other variables, but one other I think about is these large language models, the foundational models, or even some of the small language models, they're evolving so quickly. That people don't really understand them. The people who understand it is the vendor and the developers who help build the model. And I think they almost needed some time to, let's say, complete the product to truly be used by corporate America. And then a lot of that knowledge in the deployment process and development process for a customer project goes back into the core system and platform. So I think that's a virtuous cycle that's going on because we're moving models so quickly.

Yeah, and partly I'd argue because we're in the very early days of a new era, and that's not atypical, right? But back in the early days when I worked at a database company in the mid-1980s, I would go onsite from the support organization. We'd often send an engineer with me, right? 'Cause we weren't sure to make the customer successful, whether we needed to change something core in the system or we needed to do something different at the application layer. So I think part of it is AI itself is complicated, but more importantly, AI is new. So we don't have huge numbers of people who understand it well enough enough to configure it for customer success. And therefore, this old idea of the FDE suddenly got real relevant. Hey, wait a minute, why don't we hire people from top schools who are top engineers and send them out to customers to make this stuff work? So, agreeing with you here.

So, Kev, we are the Metrics Brothers, and we need to talk about some metrics, I think.

We do.

Where does the forward deployed engineering expense go on the P&L?

Yeah, as promised, we're 17 minutes in and now we're going to talk. Now that we've tried to understand what this job is, where do you put it? And the answer is always, as always, it depends. Right now, is it services COGS? Right. Post-sales unambiguously was charged to services COGS. Right. You hire a consultant, they go out and bill. Where does that go in the P&L? Cost of goods sold. Which type? Services. Right now, sometimes I'll pick customer success this time where, hey, you buy a subscription to a thing and it comes with a CSM who helps you onboard, yada yada. And let's just say that CSM never tries to sell you anything. They're just trying to help you use the product. Well, that would go to COGS, cost of goods sold, but it wouldn't go to services COGS because there's no associated services revenue stream. It goes to product COGS. Right? So, FDEs could go there, right? In theory, they're services, so they could go to a services COGS line. Or they're just part of what you bought, so it could go to a product COGS line. Or because they're really, you could kind of see them like field-based PMs who happen to be very technical, it's R&D. Hey, what they're actually doing, actually for 2 arguments. One, what they're learning about the customer environment is similar to what a PM does. Hey, they're out there kind of gathering requirements. Oh, and by the way, they're also coding up the answer to those requirements. And both of those arguments would say it should be R&D expense. So, Ray, I've got 3 candidates here. Where do you think it should go?

Well, I thought I was a pretty smart guy. So I'm like, well, if Palantir has been doing this for 14 to 15 years, let's go read their 10-Ks and 10-Qs and they're going to tell me, right?

Good idea.

All the research that I did, they never clearly state whether it's in COGS Or if it's in OPEX, they don't report any revenue on their filings except for revenue. They don't even show subscription and services. And then they confused it even more on me. And I don't want to go down this rabbit hole, but they introduced this thing called contribution margin, which they basically say, I'm going to take my revenue minus my cost of goods sold minus sales and marketing expenses. And I'm going to call that contribution margin, but they never say whether the FTE is going to cost of goods sold or the sales and marketing expenses. So I don't know, Dave, it's up in the air to me.

Yeah, okay. So, so good idea to check in Palantir. I think the moral of Palantir is kind of back to what I was saying, which is they don't want to break all this stuff out. They would stare at you and say, look, we sell solutions to customers, we charge this much money for them, and those solutions are effectively a mix of people and technology, and the technology is productized to various degrees. So we don't know, I think, would be their answer, roughly. So therefore, what that contribution margin is kind of a substitute for gross margin, because they're basically just saying we're going to take the COGS, the traditional COGS, out, and then we're going to reduce sales— we're going to further reduce it by sales and marketing Partly because, look, they're not a sales and marketing intensive company. They never have been. And second, because they're saying when we send an engineer on site, partly they're doing upsell, partly they're doing deployment, partly they're gathering requirements. So I'm guessing the FTEs are actually sales expense, but I'm not sure. And they don't seem to say that given a quick look at the P&L. But the thing we do know for sure is because they don't have a services line item, they're not services COGS. We know that.

Yeah.

They don't seem to be R&D because Palantir does not have very high R&D. And by the way, if you put these things out of COGS and into OpEx, that has the effect of increasing gross margins, which if you're trying to argue that you're the next generation services company that finally cracked the code, that would be a good thing. So a lot of speculation in there, but, but let's just say Palantir doesn't help answer the question. So, so the answer to the question for you has to be, what do these people do all day? And then derive where you put it based upon what the actual job is at your company, right? Yeah.

And then I go further down the rabbit hole. If I don't know if it's an R&D or COGS, I'm not sure how I'm going to create my CAC ratios or CAC payback periods or some other SaaS metrics, which are dependent upon knowing if it's an OpEx or COGS.

Absolutely, right? Because if you put this in COGS, it's not going to be sales expense, and that's going to relatively, you know, ceteris paribus, increase your CAC ratio and increase your LTV to CAC. If you put it in R&D, right, just say they all report to the head of engineering, if you even have that structure in the company, which I doubt Palantir does for that matter, but, but say they all work in engineering, then, uh, it would be high R&D expense, right? Which in general Wall Street and Silicon Valley like. So, but I think the correct answer to the question here, Ray, I'm going to start to wrap this up for the audience is, well, I'll do the big wrap-up. One, FDEs are hot and new. You're going to hear about them coming soon to a P&L near you, the forward-deployed engineer. You can be cynical about them if you want, but I think that would be to miss the point. They are a new role with a new job description and a new hiring profile. These people don't look like the PS people we used to hire of yore, nor Do they do the same job? Most notably, like PS people don't have source code access. These people typically do. In an outcomes-based— I'd say often do. In an outcomes-based world, they matter more than ever because no outcome, no money. So, I want to send the best people we can hire out to the customers to go make them successful and capture what they learn and put it back in the product. That's roughly what the FDE is. So, the question is, Where do you put them on your P&L? And the answer is, it depends on what they do. Do they spend most of their time— so just say they're primarily in engineering and they're rotating out to customers once in a while. Pretty clearly R&D expense. Say they have no source code access. They work for a VP of professional services and do project plans and project management. Boy, it's pretty hard to call that anything other than services COGS. And if you don't have services COGS, then it has to just be COGS COGS. Right? In my opinion, it's right, i.e., just COGS, right? So, thoughts, the final thoughts here, Ray?

My only final thought is, I think we're entering the world of agentic AI. And the more agentic AI platforms we see, I think the more FTEs are going to be required to build out the, maybe it's the application logic for customers that could or could not be reintegrated back into a library of templates that could be used at the next company in that vertical.

Got it. Okay. Yeah, well, clearly AI is driving a lot of this, Ray. Um, that's a good wrap on things. Um, thanks for listening and we'll see you next time.

Bye everyone.

The Metrics Brothers AI, SaaS, and More is a production of The Metrics Brothers Growth and CAC and a member of the Benchmarkit Podcast Network. By accessing this podcast, you acknowledge that The Metrics Brothers make no warranty, guarantee, or representation as to the accuracy or sufficiency of the information provided or the humor content of the jokes told. Ray, information, opinions, and recommendations presented are, according to our spouses, probably wrong and provided for information purposes only. This podcast should not be considered professional, or for that matter, unprofessional advice. We disclaim any and all liability for any direct, indirect, indirect, misdirect, incidental, special, ordinary, consequential, inconsequential, or other damages arising out of any use of, or God help you reliance upon the information presented here. Ray Grothreich is based in New York City and available on X @rayreich. Dave Kellogg is based in Silicon Valley and available on X @kelblog. Schedectady, which is French for unspellable, is not our actual production location. Thanks for listening.