Forward Deployed Engineers: the skills, overlap with Solutions Engineers, and the differences (281)

If you have spent any time in an SE community this year, you have probably heard the title. For what deployed engineer, we actually had one episode already on the topic in German. Today is English, as you can tell. What does FDE, in short, stand for? FDE, right? That's the action most people use. Open AI is hiring by the dozens and forping has the data bricks, has the volunteer invented the title and has had them for 15 years. And in every SE Slack and every SE leader dinner, I have been at recently, the two questions come up on regular basis. And the first one is, is this just our job with a new name and a bigger salary? And number two, what do these people actually do and what do they need to be good at? So today I want to do something a bit different. I want to go through the FDE robot task by task and understand what does an FDE do on a Tuesday by which of those tasks does a solution engineer also do and which ones are genuinely different. And then, well, as part of the context of this podcast, what we care about most, which type of skills decide whether an FDE engagement succeeds or fails because I went through a lot of job postings and the accounts from people who have done the job and the investor commentary and the answer is maybe not entirely what job posting postings say that it is. Welcome to episode 281. Can you believe it? Of presets unleashed. This is your podcast for sales engineering in B2B software sales. My name is Tim and today I'm flying solo while my co-founder Jan is on holiday, which is why I wanted to experiment with an English episode for a change. So between us, Jan and I, we bring more than 25 years of experience and pre sales, helping us and IT companies unleashed their pre sales potential for high wind rates, happier customers and of course, for more fun in the role. So on the agenda today, you already heard it in my so-called cold opening. There is a marketing term for you and I'd like to share some thoughts and some research I did this week on the Forward Deployed Engineer. And with that, let's dive in and please enjoy the episode. I would like to start with what a typical week of an FDE looks like. And there is a great first-hand sub-stack account from and I'm hoping I'm pronouncing the name correctly. You can find his substack under FDEHub.org, he's an FDE at a company called Leverage with a double L and he wrote up what his weed actually looks like and his summary is roughly this. 50% meetings, 50% building and that means half of the time in front of customers and half of the time writing code basically. And his conclusion about the job and I'm quoting him here is that it's less about building AI systems and more about understanding businesses well enough to know what to build. And that quote alone I find already rather telling. Now fair enough, one person's week is an anecdote, so let's look a little bit at some of the data. A company called Bloomberry analyzed about 1,000 FDE job postings and the number one responsibility across these postings was not building an AI system. It was actually quote unquote working directly with customers, 55% of postings named that one. Building AI systems came in at 37% digrations at 32. So on the skills side, the single most required soft skill was customer facing ability at 47% of postings. So already we have a job where by the company's own description, the most common task is talking to customers. So keep that in mind because the hard requirements in those same job postings are years of engineering experience and a big technology stack. So my personal hypothesis already at this point is the thing they screen for and the thing that job consists of and what makes an FDE successful are not necessarily the same thing. When you lay out the tasks, they split into two halves. The first half is engineering, writing production code inside the customer's environment, integrating with their systems, building data pipelines, designing the architecture, debugging infrastructure you have never seen before. So this is half every postings list first and lists as a hard requirement. So fair enough, if you can't do this, you are not an FDE. The second half is customer facing and it breaks down into five tasks that will sound very familiar to anyone working with precells. Task number one, guess what, discovery. So getting from the customer, what they say they want to what is actually blocking them and then to a number that the customer cares about. Postings sometimes name this and topic literally writes, quote unquote again, conduct discovery with customers and nobody defines it. Well, at least not in the job posting. Task number two, stakeholder management, who decides, who blocks, who owns the data, earning trust at the top of the customer organization in the postings that hides behind the phrase customer facing, quote unquote. Task number three, expectation and scope management, explaining a technical failure to a non-technical VP without losing the room, presenting progress to a sponsor. And the job postings call this quote unquote strong communication skills, which tells you not as much as sits behind that. And task number five is commercial awareness, understanding that adoption is what the customer pays for and where expansion is coming from. So this one is almost never stated and as we will see, it is actually very often measured. So the bloomberry author put the customer facing bar in one sentence that I personally really like, quote, if you can't sit in a conference room with a non-technical VP and explain why they're AI agent keeps failing without making them feel stupid, you will not succeed. And that brings me to part number three, where do FTEs and SES generally differ? Let's put the solutions engineers next to the FTEs and be honest about the differences because there are certainly some real differences. In total, I've identified five, I'm sure there's more. The task here is not to be complete, but to give some food for thought. So difference number one, timing in the deal. The SES works before the contract, right, pre-sales is often a term used, qualification, discovery, the demo, the proof of concept, the technical wind, ultimately. The FTE mostly works after the contract, deployment, integration, production rollout. I say mostly because some FTE teams open AI and anthropics among them, by the way, start with discovery before deals exist. In fact, I saw a job posting for a program lead pre-sales forward deployed engineering. That was the title from anthropic just yesterday. So but the center of gravity is quite clear here, SES come in before the signature FTEs come in after the signature. This number two, what they actually produce, the SES produces proof, a demo, a POC on the customer's data, the technical part of the proposal, the business case. The FTE produces working software that runs in the customer's system and ideally patterns that flow back to the product team. So it's half product management, and then some organizations actually FTEs are part of product management. I'll get to that a bit later. There is an investor at Flybridge, his name is Daniel Parras-Rays, and by the way, all the sources are linked in the articles that are also wrote about this topic on our website, which you will find in the show notes. And he says, what separates the FTE from sales engineer precisely is that the FTE ships production grade code directly into the customer's life environment. And I think that's a very fair point, SES typically do not do that. Difference three, the pay structure, does an interesting one, incentives are often heat dissipated among the SES community. Most SES are on a base salary plus variable, sometimes like 7030, potentially tied to a team or territory target. FTEs are on base plus equity and sometimes plus bonuses. So in the thousands of postings, bloomberry analyzed, thank you for that. We are greatly, greatly taking advantage of this research here in this podcast. The number of FTE roles that carried a quarter was literally zero, zero percent. So difference four, reporting line, I just talked about this already a little bit. SES and most companies, they report into sales, right, part of the go-to market organization. FTEs report into a dedicated FTE team in 45% of cases, into engineering in 38% and into sales or go to market in only 14%. And difference five, last one here is the account load, actually wrote about this a couple of weeks back in a LinkedIn post myself where I did a calculation on how an FTE when the person is supposed to sit on site, which is literally in the name, how many accounts can realistically be covered and what that means in terms of how much additional revenue we need to get out of it for it to be attractive. And this is also here in this difference five, a typical SE covers three to five account executives that's in line with my personal experience in 2020. to 30 deals on a quarter is normal, that's on the higher end, but I was mostly working on enterprise. If you look in SMB on mid market, I'm sure that number is pretty accurate. An FDA at Palantir or OpenAI goes deep on one or two customers at a time. At a start-up, it might mean maybe 10 parallel, but the model is typically more depth and not more breadth. So Palantir plans for about a quarter of the time on site. Some companies go up to half which is confirming my LinkedIn post where I talked about that most FDAs are on the road at customer sites very, very often. So it seems like between 25 and 50% of the time there are not in the office or not at home. Do you know that feeling? You are reviewing a deal that should have been yours. You have the better solution. You know it, your champion knows it, and yet somehow you still lose. The customer goes to you, procurement drags everything out, and in the end you get, "Oh, we've decided to go with another vendor." And you're just sitting there thinking, "What the hell just happened?" And then there are those phases where you tell yourself, "Hey, let's get better here. You watch a YouTube video on Discovery, maybe you read a book about pre-sales, you join a webinar." But then real life kicks back in. The next POC, the next demo, the next FireDraw, and nothing really changes because you don't have a real framework, no system that makes you continuously better. And that's exactly where the trusted advisor Academy comes in. The Academy takes this massive topic. How do I become an SE who doesn't just support deals, but actively wins them and breaks it down into the right steps at every level? Not with the ones of workshop you've forgotten three days later, but with a 12-month system that is tailored to you, your level, and your role. People describe the Academy like this. "Hey, I finally understand why some deals work and others don't. I know what to ask in Discovery, I know how to build a champion, I know how to shape the technique you win, so that procurement can't torpedo my account executive anymore." So you learn how to build pain chains that uncover real business pain and not feature bingo that knows the level executive really cares about. You learn how to set up a mutual evaluation plans that keep the deal on your timeline. And it's the same with positioning, everything gets broken down into concrete frameworks. You know how to position yourself as a trusted advisor and not a demo monkey. But let's put all of that aside for a second. The methodology, the frameworks, all super important, but in the end results are what count. Over 250 solution engineers from companies like Salesforce, Adobe, Zscaler, and Lookinette are using the Academy. And the results speak for themselves. Higher win rates, shorter sales cycles, and SEs who finally have the impact they deserve. And here's the best part, the trusted advisor Academy isn't a workshop that leaves you on your own afterwards. Whether you are a junior SE or an SE director with 15 years of experience, the Academy knows exactly where you are and what you should be learning next. Live sessions multiple times a week, a community of the best SEs in the dark region and the leadership track for everyone managing SE teams. You're not getting a program that wraps up after eight weeks, you're getting something that is systematically making you better over a period of 12 months and beyond. So if you're finally ready to be the SE who wins deals, instead of just supporting them, head over to seiroxdust.com right now, check out what the Academy has to offer and book yourself a free discovery call. See for yourself whether it's right fit for you and your team. No excuses. Thanks for listening and now back to the show. So basically the differences. The timing when they get involved, the output they produce, the pay structures, the reporting line and the account load. So those five definitely are a distinct difference. And if you want a quick test for whether a posting is really an FTE role or an SE role with a fashionable title, Blueberry suggests one question, does the manager report to sales? And I would add maybe two more because it's paid tight to sales targets. And does the role start before the contract and two or three yeses from these three questions, you are most likely more reading and is e-posting with a different title that a true FTE posting. We talked about the difference. Let's talk about the overlap. And I would argue the overlap is part of what decides whether the role is actually successful. Both roles spend most of their time with customers and not with code. We covered at 55% of postings listed 55 in Monday's week, which I referred to a bit earlier. So both run discovery and topic posting asks for strong communication skills to conduct a discovery with customers. That was a quote. Open AI's posting has the FTE quote again, own discovery, technical scoping, system design, build and production rollout. And notice that discovery is first in that list, so it always starts there. Demandage names the core skill as seeing what's actually blocking a client, which is really what they say is blocking them. I find that quite telling. Reminds me of the picture where you have like a tree with a with a little toy attached to it. And it's basically saying, yeah, this is what the customer was asking for. And then you see a roller coaster, what was invoiced. And then you see a chair completely different location. And this is what the customer actually needed. So like all different things, and here he talks about the difference between what the customer says they want and what they actually need. And those might not be the same thing. In fact, they very suddenly are the same thing. So basically, this is the discovery, the discovery letter that every is good as e-climes in every deal from symptom to calls to impact to number. In fact, this is a concept we teach in our trusted browser Academy recall. This is the pain chain. We did a dedicated episode on that one, if you are curious to learn more about it. I suggest you tune into that one. It is in German though, if I'm correctly, so let me know whether we should really record it in English as well. So both roles, manage stakeholders and expectations. The best account of this comes from an individual called Nabil Kureshi. I'm really murdering all these names here. And he was an FDE at Palantir, he also wrote about it publicly, and this is where I got this from. And he wrote a long piece called Reflections on Palantir, again, links to that are in the articles on our website. And he says success and the role required an unusual sensitivity social context. So quote unquote again, an unusual sensitivity to social context. And that what you really had to do was partner with your corporate or government counterpart the highest level to gain their trust again, that was a code, sensitivity to social context, gaining trust at the highest level. So and this is obviously not an engineering skill. This is what I would call a trusted advisor's job. So and both are hired from the same pool, FDEs and SES are typically hired from the same pool. 22% of the FDEs in bloomberry's data source came from solution engineer or solution architect roles. Another 10% came from technical consulting, anthropics required background is quote a technical customer facing roles such as forward deployed engineer or a software engineer with consulting experience, data bricks, data scribe, their FTEs as engineers with strong leadership and consulting skills. So the people hiring FTEs are looking for engineers who can do the SES job, whether or not the posting is saying so. And here's where it gets interesting and where I want to spend a bit more time, right? Because if you look at the documented failures, there are typically not engineering failures. Failure path one, you're actually again on how volunteer engagements sometimes went wrong and I quote, you'd have a company buying an 8 to 12 week pilot and we'd spend all 8 to 12 weeks just getting data access and the final weeks scrambling to have something to demo. So, let's walk through that, so the pilot is sold, the FDE arrives, the data owner will not grant access and weeks go by in internal politics, final weeks scrambling demo, nothing in production, that sounds like fun. So every SE who has ever run a proof of concept probably knows that story by heart. And let's look at what is wrong in this instance, the data owner who will not grant access is a stakeholder problem, clearly, the success criteria, nobody agreed at the start I was coping problem, the sponsor who lost interest by week six is an expectation problem. And none of those are solved by being a better engineer. All of them are solved by the work a good SE does before and around a POC. And failure path two is a bit more subtle and in a way more dangerous, we brushed upon this already just so slightly just now the customer hands over requirements, the FDE builds exactly that, clean code, shipped on time and nobody is adopting it because the requirements describe what the customer thought they needed and not the actual problem. So, flybridge warning again, source are linked to that one, the flybridge warning is that when field work does not quote compound to the core product, the economics argument collapses fast. And the piece on latent space about FDE's source, again, linked best practices says it is even more bluntly, they say it even more bluntly, an FDE function that solves customer's problem without sending the signal back to the product is a service consulting team with a better title. And I heard the CEO of 11labs talk about that, I also analyzed this conversation a little bit in a recent newsletter of ours where he was saying that one of the core responsibilities of FDE's must be that they produce production grade code, not only for this one particular customer, but their feedback, their work into the broader product organizations. So the broader set of customers can benefit from individual innovations. And avoiding this type of work where the customer is expressing a requirement, but we actually don't understand why it would be or we have a different perspective on that that requires the FDE to push back to say no to some customizations that helps one customer and nobody else. And saying no to a customer who's paying for your time, well, guess what? That is a skill. And I personally am an engineer by trade. And I could promise you one thing. This one was never taught to me to be part of the job. So in both failure paths, paths that we just looked at, what was missing was the same short list, agreed success criteria as they called a map discovery that reached the real problem and the confidence to say no to it. And guess what? All four are trainable. And none of the four are taught in a typical engineering career. Now, some of you might be thinking fine, but FDE's have to quote us. So this is a delivery quality question, not a commercial one. And I would like to push back a little bit on that. Open AI's posting states, the FDE's success metric, rather directly, quote again, production adoption, measurable workflow impact, and Eval driven feedback. And for Bix, FDE role exists, quote again, to drive transformational AI adoption. So the metric is adoption. And under consumption based pricing, no surprise, which is how AI products are increasingly sold, adoption and revenue are the same number just from two different signs, so to say. So time to first value, user tramp, that's basically the customer's bill. So the Alexander group, which maybe you heard of them, they are revenue consultancy. They recommend measuring FDE's on time to first value and early consumption at notes that quote again, many organizations are placing this role on a sales compensation plan precisely because of its effect on how fast user traps. And some companies go the whole way, if you look at tail scales, FDE role, they are paid on on target earnings with variable comp tied to quarterly sales targets. Runs quarterly business reviews to fund expansions and requires experience working with enterprise customers in a consultative capacity. So that is an expansion role within engineering title. One might wonder where customer success has a place in all of this. I wonder also sometimes a bit of an outline here with tail scales, FDE role. I said earlier that basically zero job descriptions had on target earnings based on variable compensation that is dependent on sales targets. Tail scales seems to be very much an exception to that rule, but I'm sure they had a reason to do so. So the FDE role sits exactly where the customer decides whether they want to spend more money or not. And the flybridge test for whether the role pays for itself is a path from $50,000 pilot to a seven figure contract. Again, that was a quote. So what they basically are talking about, we start small and then we expand, but we expand not like times two times three. This is like times 10 or more, which would then justify having a such a role on site 50% of the time with the high salaries that we see for the role. And whether that path gets walked depends on whether an FDE found the right problem of course, they kept the sponsor engaged and turned a working deployment into a reason to expand. So in our SE language, that's the technical win followed by a commercial one. Let me bring this home for the people I typically talk to every single week, which is mainly as e-leaders. First, on the rebrand question, my honest answer is, yeah, sometimes it's a bit of a rebrand. And Reese Norowitz, they call it, they call the title like title arbitrage for roles previously called solution or integration engineers. Most as e-leaders I work with, they see it as well paid rebrand of work and presales and professional services already do. And the underlying pattern vendor engineers embedded in custom organizations is actually decades old. I did a piece on that already like a year ago. IBM did it first, SAP then picked up on it and perfected it. And where the FDE is generally a different job is where production code becomes product. And where it is not, it's the same as in SE with a different name into higher base. So second, and this is the part I find generally encouraging. The market is now finally paying engineering salaries. Right? Flybridge estimates 222 to $400,000 fully loaded for annual salary. For people who can run discovery, manage stakeholders, hold a customer's trust through a difficult deployment. And those are the skills that decide deals and pre sales too. The FDE trend is the market putting a nice price tag on the SE skill set, which is of course half technical and half commercial as we are starting to discover here. And thirdly, there seems to be still a training gap. Companies hire FDE's for the engineering half because that is what they can screen for. And the engineering is arriving already quite trained. And what arrives untrained is everything else. And they discover this in the field at $400,000, a UPA engineer on accounts with seven figure expansions at stake. So yeah, congratulations to that one. And if I were standing up an FDE team or an SE team for that matter, the program would cover five things. Number one, discovery as a method and not as a personality trade, a repeatable way from stated request to the real problem to quantified impact practiced ideally on life accounts. Number two, success criteria before the build, what the customer will accept as proof, agreed inviting with an owner and a date. The 12 week pilot where references earlier, we referenced earlier that produced nothing didn't have any of that. Number three, stakeholder mapping, who owns the data, who signs it, who loses it, if it works, Karashi's sensitivity social context code again is a skill with a method behind it. And that's not a gift. It's something that you can learn. Form is executive communication, reporting progress, problems to people who will never read the code in their terms. And five, yeah, a hard one saying no, declining the customization that will not compound and doing it without losing the account. And yeah, I guess what one of workshop will not install any of these type of skills, behavior on a customer called changes with practice and coaching and not with an engineering certificate. So to some, the conversation up here, the FDE and the SE differ on five things, timing when they get involved, what they produce, the pay structure, the reporting lie and the account load. Those are definitely real differences. But the work in the middle understanding the problems better than they could have articulated themselves, managing the people who can block or fund the work and holding their trust through setbacks. That's the same job. And it is the half that decides the outcome for both worlds. So engineering is sort of like the entry ticket and the customer work is the actual game. So if you want the written versions of all of these sources, they are on seroxas.com under our guides. The first guide is called what is forward deployed engineer FDE versus a solution engineer and forward deployed engineering skills. Those are three different guides that you can find there. And if you are building an FDE team and want to know what they will need beyond code, you of course know where to find us. This was presets unleashed. Thank you for joining me on this little experiment. And this is your podcast for sales engineering and B2B software sales. And if you enjoyed this episode and picked up some useful ideas, subscribe to the show. And if you have any questions of course feedback or topics you'd like us to cover, get in touch, send us a message. We'd love to hear from you. You'll find links to our profiles in show notes. Thanks for tuning in. And see you next time.