What is a Forward Deployed Engineer? (with Founding Rippling FDE)

0:00 what key skills should I really brush up on that would really help me shine in the interview process. Hey everyone, I'm super excited to be here with Kevin B. we're going to be talking about forward deployed engineering and the forward deployed engineering interview. but first before we get into the conversation and talk more about FTE, Kevin, can you just introduce yourself really quickly for the audience? >> Yeah, happy to. Hi there, Stephen and hi there audience listening at home. My name is Kevin. I am an FTE at Ripling. I was the first person to join just over a year ago to help them build the function. that's gone pretty well.

0:34 before that I was at Palunteer for a number of years. I joined in 21. which is is is a pretty long a long while ago given the the history of things and how the stock has progressed. but yeah, I am pretty interested in the FTE space as a whole. I actually think this is the single best way to win in enterprise. and so in addition to my day job, I also go around to conferences to speak about FTE and then I also work with founders and different kinds of companies to help them set up FTE functions.

1:08 >> Cool. And we'll hear a lot more about you and your background in in just a moment. I just maybe wanted to start maybe we can just kind of share a little bit more about like what's happening in the market, how it's affecting you and how you're seeing the FD role grow and happy to share a little bit more about kind of where we're seeing things and how things started there too. So high level, right? One of the things that I always try and like establish when I'm working with founders or companies is do you need an FTE function? because it's very easy to get into like the the hype of it and think that this is what you need to do to raise money or this is what you need to do because this is the common wisdom.

1:43 I think that's really dumb. so broadly speaking, right, who are you selling to and then what are you selling? These are the questions that I try and ask as a framing mechanism. So if you're selling something very technical, right, very complex, think the anthropic API or think GitHub as a product, right? Yes, they're technical, but the buyer is a software engineer or, you know, the profile would be CIO CTO and they're very technically capable and they can understand it and make use of it on their own. So that's okay. If on the other hand you're selling a slack right or a Jira your tool is not that technical but your end user mostly is not that technical as well and so there's great alignment where you need FTE or where FD starts to make sense is if you have a very technical product and a ICP ideal customer profile right who is not technical and so for the case of Palunteer that's what it was for Foundry our our big data platform and our app building platform where we were selling to Fortune 500s but not technology companies, right? CPG, manufacturing, aviation, all of these places where there were huge massive problems that deserved really great solutions, but there was no one there on the other side to really make sense of our software and their problem in a way that, you know, like is really going to solve things and create a good outcome for them. And so that's kind of like where I would think about FTEE to begin with. obviously in this day and age, right, Agent AI has made it easier than ever to build a really powerful solution, but also really powerful in the age of AI means really complicated. most of your customers, if you're selling into a traditional industry, right, probably have no idea what agents are or probably only have a cursory idea of what it means to use LLMs. And so it's a pretty good idea, right, to not have their lack of technical talent on payroll be the barrier to the success of your startup.

3:41 and so that's broadly how I think about FTEE and why I think it's on the rise now. >> It's cool. It's it's I think you explained it very clearly. It's sort of like technical solution to a non-technical customer and FD sort of bridges that gap. I'm curious like with the rise of this role and you know a lot of our audience are people who are interested in FTE as a role there's a lot of hype and so any other recommendations like how to distinguish what's overhyped versus what's like hey this is really real and you know you worked at Palunteer which I think is basically the first company that I know of at least that ever talked about this role or I think invented this role so I I'd be curious your thoughts on that.

4:21 So, there's a lot of people that are like trying to be funny and be like, "Oh, this is just a rebranding of sales engineering." Well, that's not true. And first of all, you know, put some respect on sales engineers. They do really great work. but let me take a step right and explain what FTE is relative to the things it's commonly confused for. And maybe that can help dispel some of the hype. So, first and foremost, FTE is not sales engineering. Sales engineering is a pre-sales function where you're primarily building demos for the purposes of winning a deal. The engagement ends after that. FTE is not that. FTE is owning everything from discovery to delivery end to end.

5:00 something else that FTE tends to be confused for is software engineering. Right? This is just a case of putting devs on the front line. That's absolutely not true. You should have a separate FTE and dev team. The purpose of your software team from like a spiritual perspective is to build one to many right you build something really really cool that scales to a hundred users or a thousand users or 10,000 users the purpose of FTE is just the opposite right it's one to one you are building a thing that solves a problem for a specific customer and if you're thinking any more beyond that then you've kind of lost the script a third thing that FTE tends to be confused for is I would say professional services or in some cases even consulting. There's elements of the FTE role that draws from those practices.

5:47 but this is very much a engineering capacity and engineering role. The end output of an FD engagement should be software. if it helps right you should think of it as the invention of SKUs. And if you don't have an organization that's kind of toolled in that way that's totally fine. And I don't want to gatekeep the name. You can call it FTE, but in the shape that I know it and in the shape that's brought Palanteer so much commercial success, right? This is kind of, you know, the things that FD are not. And so that kind of segus to like what is FDE? put simply, right, FTE means a customer-f facing software engineer. Now, why would you want such a thing? And you know, why does that exist? And we can get into all that history, but let me let me break it down, right? So in my experience the role is about wearing three hats.

6:38 Consultant, product manager, software engineer. Now you have companies where there's roles are split up into two people or some companies where they're split up into three, but let's not get into that. FTE as a function is these three capabilities. So the first part of any given engagement that I've ever worked on, right, is not talking but listening. Your job is to gain the trust of the customer, of the executive sponsor, of the VP, of the CEO, whoever you're engaging with, so that they see you as a trusted partner to solving their problem. And you want them to tell you not just the problem that got you the deal or the pilot, but the real problems that keep them up at night that maybe would tank their stock if those got out, right? If this was a public customer, because those are the problems worth solving. Now, we do index very heavily on communication skill, but I like reemphasize this to anyone I've ever mentored. The main communication skill of an FD is listening. You have to practice active listening and you have to get someone else to tell you the things that they don't want to tell anybody. Once you can do that very well, you're going to need the product management skill set to survive. Because it's in my experience that once customers start telling you their problems, they don't stop, right? And so how do you celebrate or separate signal from noise? So in my experience, what you're looking for is the highest impact for the customer and relative to the easiest problem for you and your team to solve with your current platform. Does no good trying to boil the ocean and then also does no good solving something with no impact. assuming you're able to find that and align the customer to it, right? Then you have to actually go and deliver it because if you can only do those first two pieces, you're just a very good consultant. But again it's forward deployed engineer and so then right you build this solution for the customer you deliver it and it solves their problem end to end that to me is forward deployed engineering.

8:34 >> Let's say that in this scenario you are wanting to do that first part this kind of discovery component. and so let's say we we've already played around with the demo or the tool or something like that and what what you're finding is that we keep we keep running into latency issues and we keep getting frustrated about latency issues. so for the the dashboard isn't loading and I have trouble loading the dashboard and things like that. I would just if if possible and if this feels like a good example, I would love for you to explain like what would that listening look like? Like what would what kinds of questions would you ask? How would that conversation go?

9:06 >> Yeah. How does discovery go? Right. So, the problem is rarely ever the problem. generally speaking, what customers tell you is the symptom. And so, it's it's cool that like there's latency, but then why is that affecting your business, right? I'm I'm certain you did not choose to work with my hypothetical company because we have the fastest dashboards. And so, like, what business problem are we trying to solve here? >> Yes, exactly. So let's say that in this scenario, we want the dashboard for our company to load because it shows all the courses and then users can go and purchase those courses. And so our concern is that if it takes a while to load, maybe purchase activity will go down or maybe conversion rate will be lower because >> this is a dashboard to observe sales over time.

9:49 >> this is like a userfacing dashboard that consu like our our users get to see to view the different like portfolio of SKUs and options that they get to purchase for instance. >> Oh, I see. I see. So then what you're what you're saying is you're trying to set this up in a way that optimizes the next sale, right? So it's not necessarily how fast the dashboard loads really. We're trying to figure out how well it can convert. And we think that perhaps by increasing latency that will increase conversion, but it sounds like at the end of the day, we're trying to drive more sales.

10:24 >> That's exactly right. Yeah. So the actual goal there is sales and conversion to sales rather than latency. Although you know me as customer I think that the latency is the main driver or issue and maybe maybe that in of itself as an example I don't know if you want to drill in more or Yeah. So, so, so you know, off the bat, right, I would never tell you you're wrong because latency is an issue, right? That would be facitious and that would be dishonest. However, I would try and work with you to understand what is the underlying problem because latency is also a bit of a swamp, right? I solve it and then next week you want it to be faster still and then next week you want it to be faster still. like I could make it 10 times faster, but you know, we could achieve no results and you could be just as upset if not more because now we've spent all this time and money. And so my goal here is not only to understand what it is that you need, but to also as best as I can like convey that to you and convince you of it. that's a little bit difficult to do in an interview setting without any context.

11:24 but that's what I would be trying to do if I was actually working with you. >> Cool. I think we can pause that example there, but that's just very helpful and demonstrative for me and hopefully for the the listeners too of like okay, how do you take listening as a FT? What what does listening mean? And it means like understanding, hey, what are the goals of the consumer or the customer and what are their actual goals versus their stated goals? What are they actually looking for? and how can you align your product and what you're building to the thing that they're listening for, which I I think is actually a very important skill and very under celebrated skill in this role and in a lot of these roles in tech. So, this is this is like this is like really fun, right? Like we want to increase conversion rate. I I love situations where I'm helping someone make more money. Everyone's excited. But then, right, so many ideas. What do we do? Do we do we you know, like let's throw latency aside. We could make the dashboard faster. That's one way, right?

12:16 We could also perhaps query this person's search history and then show them courses that are most relevant. That's another way. we could perhaps increase the sizes of this call to action. We could make it super annoying to leave this page until they buy something, right? We could trap them. you can't build everything. Even if the customer has infinite money, they don't have infinite time. And so your role here is to pick out what is the strategy that is most likely to achieve that stated goal of higher conversion rates and then what is most reasonable to do within the given time frame of the project. and so this is an interview setting. I have no heristics, right? But like let's say we have four weeks for our pilot. I'm not looking for the best conversion increase like solution.

13:01 I'm looking for the best thing I can do in two and a half weeks because I know for a fact that you're going to hate the first version and then we're going to have to iterate. And so it's kind of like counterintuitive, right? Some people would think that they want to choose the best thing possible and just barely fit it in four weeks, that's how you're going to lose a deal. because like unless you can ship perfect code the first time, right? It's not going to happen. And so I'm looking for essentially the smallest piece of scope that would lead to a net increase in conversion that I can get you to accept so that I can build a shitty first version and then iterate from there.

13:35 >> Got it. So key principles there being iterative development and then also making sure that you're actually or oriented toward the high priority wins here like not just kind of boiling everything under the ocean as you mentioned. You have to kind of pick what your wins are and what you actually do. >> Exactly. Yeah. And so anybody who has like a product background should already know how to do this by default because product is the art of working with a lot of constraints, right? You don't have an infinite engineering team. You don't have an infinite road map. the only thing that's a little bit different here is that either you are the engineering resource or you know you have maybe like a tiny team. and so it's the stakes are a little more real. but I would say right it's not necessarily someone's product management experience that makes them good at this. It's their ability to really take ownership of the problem as opposed to take ownership of the project. And I view those as very different. So like someone who has high ownership of a project is really excited to make the project successful. They're willing to do really hard work. They're willing to like stay long hours. And that's all well and good, right? But at the end of the day, you are customerf facing. And the customer doesn't care how happy or miserable you are. They don't care how fast or slow you work.

14:48 They care that their problem is solved. And so if your, you know, method of operation, if your organizing principle is anything other than the success of your customer for this specific problem that they've aligned to with you, right, then you're probably optimizing in the wrong way. And so a really good candidate is just someone that can speak to that framework and speak to their thoughts in their head, right, of why they've made a certain decision and how they're able to back it up with respect to the problem that's being solved.

15:20 There is no right answer, right? But there is a right way to answer. The the the thing that's really cool, but also really not cool is that you are responsible for delivering this thing end to end. And so unlike an engineer, right, you can't just merge the PR and then go about your day and then move to the next ticket. you need to figure out how to build it, how to demo it to the customer, how to elicit feedback from them such that you can improve it, and then how to get them to ultimately accept the solution. these are not things that software engineers are, you know, like strangers to, but I would say most people coming from a dev background have been a little insulated where some of these functions are taken on either by other team members or, you know, by a larger org or even a separate org.

16:07 in my mind, right, this has always been the job of software engineering is to build something that works end to end. And for folks who are founders, right, you'll be very familiar with this. There is no DevOps team to hand it off to. There is no QA team. You are everything end to end. And so that's the part I would say that's different from a software engineering perspective. it's not necessarily someone who like has a super high quality bar. I want to make sure that like we also differentiate between quality and completeness because quality just means the code itself is very very good and that it's optimized and that you know there's no reasonable bugs that can be found but that doesn't mean complete because at the end of the day right most likely your customer will never even read the code. And so does it work? Do they understand that it works? And then is it able to generate the actual business outcome that they're paying you for? Cool. That makes a lot of sense.

17:03 And like thanks for walking us through kind of like in detail each of those steps. is there anything else that we missed on that like kind of what is an FTE part before we sort of transition to the interviewing and recruiting aspect of things? >> The role itself I think is most effective when all three of these functionalities are in a single person. but there's definitely different schools of thought. There are organizations that prefer to break this up into one person who's more consultant and PM and then one person who's more PM engineer. there is not exactly one right or wrong way to do this but within your FTE function right all of these pieces must exist. And so for candidates seeking to get into companies with FDE roles, I would really encourage them to understand right here's the three hats, consultant, PM, engineer, which are the hats that they need me to do and then who are the personalities and the personas that I would be working with.

18:02 like I I feel like that gets like lost in the sauce very easily. >> Yeah, I think that's fair. And honestly like the role does vary as you kind of mentioned earlier so much between the different companies and the stages of the company. So I I like that framework as a way to disambiguate what type of role this role is going to be. Is it going to be more consulting, more engineering, etc. Okay, cool. I I want to transition to talking about the interviews and recruiting. So a lot of people are interested in this role. It's becoming really hot. a lot of people are wondering first of all who is the right fit for this role. So you know not everyone like you went to Palunteer were already was an for deployed engineer beforehand. is this role right for software engineers? Is this role right for consultants and PMs. Who is this role right for? And even from the perspective of a new grad too like what majors might you look for when you think about hiring an FTE and things like that. So would just be curious like who is the right fit and then we can talk about how they can get there or what that might look like to get there.

18:57 >> Yeah for sure. So this is a really really good role for people who are either former or future founders. the shape of FTE work is very very similar to design partnership work which anyone who's founded a company will be very familiar right you don't know what you're building your customers don't know what they're buying. You show up you talk to them and then you build stuff. you know you don't need FTE like resources to prep for that. Go to YC go to A16Z. any of these companies will tell you talk to customers and build, right? Easy enough. but not everyone's a founder. So, what are the other profiles that would be good for this? this is not a role where you are a software engineer but X or a consultant but X or a PM but X, right?

19:45 This is truly a role that sits at the intersection of the consulting product and engineering disciplines. And so what this means is if you're a software engineer but you've always had a product vent or right if you're a PM but you've always been very technical like that would be a really good profile and background because then you're already kind of doing the work just maybe not in the exact role of an FTE. this is a job at the end of the day for someone who is really excited to do three jobs in one and there are some you know cool things that come with that. you get a lot of really cool experience. it's a hot title right now, but I would say those are all like terrible reasons to want to do this because you are potentially right setting yourself up to fail and you have 3x the failure surface as if you just did one of those jobs really well. and so this is really just for people who would be excited at the prospect of balancing these three professions at the same time. and that doesn't have to be for everyone.

20:48 And again, I want to emphasize, right, like this is not a panacea either. It's not like you put FD into a company and it solves every problem. >> That makes a lot of sense and kind of exciting to see it's a convergence of those many different roles. so I'd be curious like on a recruiting basis. So let's say someone is sitting here watching this being like, okay, I I learn about what the role is. I'm excited about the role. I feel like I have the right skill set. what would you recommend in terms of, you know, making sure that they're ready for the interviews, making sure that they're ready to actually pass the the test to get into these companies?

21:21 >> There's so many different flavors of FD hiring. This is why I recommend candidates really familiarize themselves with the JD, with the company, and also with the specific hats that they're going to be expected to wear. because if you're at a company where FTE just straight up means hands-on keyboard builder, it's not going to look all that different from prepping for a a product engineer type interview, right? but if you're going to be looking for FTE in the shape that I hire for and in the shape that I've done it at Palunteer, here are kind of the things to keep in mind. Obviously, it's really hard to show in an interview that you listen well. but what's not hard is showing how you show up and how you work with customers, right? Because your interviewer could be your customer and you're you are selling them something.

22:09 You're selling them yourself. a word that we borrow from consulting is executive presence. and what that means is how well can you carry yourself in front of senior leadership either internally or externally. And maybe you've never worked as an FDE, but have you presented something to the VP of engineering or have you presented something to your CEO before at a startup? How did you do that? How did you do that relative to your peers? Right? That's what I would encourage candidates to think about from a communications perspective. And that is also the kind of practice I would encourage that they get before they get into the loop. Because you know the same way that you can't just grind like lead code for two hours and then know every problem, you also can't be an effective presenter by just watching videos on YouTube or reading a book on how to talk. You have to actually go and do it.

22:59 and so so that is like one part of it. another part of it right is the product part. that's actually pretty straightforward. there's a lot of trade-offs and prioritization that has to happen in your day-to-day life. if you want to practice that skill, just get used to writing down your decisions and why you're choosing to do one thing versus another. And maybe you don't work in an engineering job at all. Fine. Right? right now I could go to the gym or I could buy groceries. I'm going to choose one of those two. Why? And get used to explaining your decisions in a way that is clear, that is defensible, and that other people would understand.

23:34 and I think that would really help both for FTE and for product type roles. The engineering piece again, I'm looking for I'm looking for ownership and I'm looking for completeness, right? It's not enough that you write the code. What about test cases? Where are the things that you know that could go wrong? What are the edge cases where things could fail and how have you designed this in a way that protects against that? or what are the pieces of instruction that you're going to pass along to the customer of how to use this code so that they don't run into those problems.

24:05 Right? Say I'm asking you to do something really really simple. I'm asking you to write me a function which adds two numbers together. But like if you just write that and you don't tell me, oh by the way, you can't pass in strings, right? This only takes integers. What if the customer passes in strings and now they think your app is broken, right? Or they think your platform is no good. so that's what I mean by completeness is really understanding the totality of the problem, the ways it can be used and the ways that it can be misused. And the good news I have for candidates is that these fundamentals don't only help you for FTE, they should help you for software engineering interviews as well.

24:43 because honestly too many people write code without thinking about test cases. >> Totally. Yeah. I I mean it makes so much sense that those would be emphasized components of an FTE interview because it really is about tying it into the end user customer case but honestly those are valuable skills for software engineers too. So it's actually nice to hear you say that as well. I I would be curious you know on on each of these three dimensions you're mentioning behavioral sort of the product sense and then like this sort of engineering component. Any recommendations on how to get better? So for instance like you know you're very well spoken like how how do you build your executive presence? How do you build the ability to be on a show and talk about things or to do interviews effectively, things like that? And even from a personal perspective, if if helpful. Yeah, >> that's a great question. So, I want to be very clear, right, that to to get a job as an FTE and to have a great career as an FTE does not mean you have to be me. Like you you don't have to enjoy public speaking. You don't have to be comfortable with public speaking. I know a lot of excellent FTEEs that are total introverts. what you do need is clear communication and that has nothing to do with how often you get on a stage or how much you like to talk or how you know, well you sound when you're making a speech, right?

25:59 The difference between clarity and maybe muddled communication really is the amount of preparation that someone has put into the words that they're going to say. Like maybe you can't think on your feet that fast. Maybe you can't enunciate that. Well, that's fine, right? But when you're going to work with a customer, you already know the context of that conversation. You're going to ask them for something. You're going to show them something. How do you prepare for that? Do you prepare at all?

26:28 And what does that preparation look like? It's going to be different for each person, but I want to emphasize that the way to get better with clarity of communication really is with intent and with preparation. something that a mentor of mine once told me right was fail to prepare, prepare to fail. And I think that really applies here. You you can't just generically get better at talking. You have to think about the words that you're saying and then think about the way that those words will be received and then think about the way that you are preparing to deliver that message so you remember your words, so you hit all the main points, so you don't mess it up. And if you do that and you spend meaningful time on it, I'm sure you'll get better.

27:14 >> Totally. And I I I like what you said earlier too about the skill of listening. And a lot of communication is about listening as well as speaking. And yeah, I think I think that attunement to like getting feedback on how how you're performing, how you're delivering, and kind of what that says about how you're delivering and how you can improve that too. >> Yeah. And something else I want to add, right, is that I'm pretty sure, you know, not everyone works as an FTE who's listening to this, but everyone who's listening to this does work with people.

27:44 ask your peers about your communication. I'm sure you present something over the course of your workday, right? What are their thoughts on how you present? Do they say that you are clear? Do they say that you're understandable? Do they say that you've, you know, made something complicated simple? And if they don't say those things, ask them how you can get better. >> I would be curious on the other two, product and engineering. How do you recommend getting better or preparing for those? Like anything that you would, you know, let's say someone is sitting watching this and has maybe a week or two weeks to prepare for their interview and is kind of thinking, okay, like any help, Kevin, like how would I orient myself or what what key skills should I really brush up on that would really help me shine in the interview process?

28:26 Yeah. So, product and clear writing have a lot in common with one another and certainly working with an FTE, you will be presenting plans, presenting S. So, so presenting LOIS and all sorts of complex language to a customer explaining this is what we're going to do, this is why, this is the order. from a product perspective, I would really encourage you to make some decisions and then write about them. and then see if someone who has no context on your situation, no context on your decisions at all would be able to just read your thinking around these decisions and then be able to understand them. That's one piece that like I I look for especially I think with FD candidates of course right you need to have great judgment. there's no way to get that in a week. but you know you could take time to study really good products and understand the way that they're made. I think some of the best people right in both tech and any other space be it arts be it sales be it you know human resources they take the time to see what other people do really well and they learn from them and that's especially relevant in a role like product whether it's in an FTE context or outside of FDE right where you need to know what great looks like so that you can apply it to your own context and your own problem solving. yeah, but but but if it's a week, I I don't have great advice there.

29:56 do the best that you can and good luck. >> totally. >> Yeah. >> cool. Any other thoughts or tips or anything about the interview process before I kind of want to just stop for the last part just talk about the role itself and how it might evolve over time. But anything else on the interview process or recruiting that you'd recommend to folks? Look, at the end of the day, right, and I would give this advice for someone who's trying to be an FDE, be an engineer, be be really anything. At the end of the day, you should figure out what it is you want to do because you only have one life and you only have one career. do you want to be an FTE because this is what you want to do and you've always been waiting for a role like this or do you want to do FTE because that's what other people are telling you you should do? or because this is what's hot and this is, you know, what's what's in the news?

30:43 I think the people who will do the best in the interviews are the ones who have genuine reasons for wanting this role and genuine reasons for wanting to succeed in this role. And if you don't have those, that's not a problem at all. You should take the time, figure out what it is you really want to do, and then go crush it at that. Cool. I like that. Yeah. okay, cool. Let's let's transition some gears and just talk a little bit about the rule itself. So I I think I would love your opinion or your thoughts. There's a lot of buzz about this role. What does FD look like in 5 years? Like how do you think this all plays out? And some people are saying that FD role will be around for a while. Some people will say actually this FD role will kind of eat itself within two to three years. What's your take on it? What are you seeing? Like what trends should FD FTEES be aware of as they think about this role evolving?

31:32 >> You honor me, Stephen. I don't think I'm nearly qualified to comment on that. but if I was just to to spitball the FTE role, Palanteer as a company is over 20 years old, right? It's existed since the beginning because we realized this was the best way to deliver really effective software in very complicated environments where the end buyer and the end users aren't technical. and I believe that so long as that shape of problem is here to stay, so too will the FDE role. now will certain FTE roles get absorbed? will FTE go out of fashion? Will, companies, you know, that use FTE fail? I'm certain, right?

32:13 But that's also because, to your point earlier in our conversation, there's a lot of different types of FTE. There's a lot of different companies that are doing, you know, any which thing and then calling it FTE. And so I I can't possibly comment on the success of FTE as a whole just purely off of the name, but I can say that if you have a function where you work directly with customers, you listen for what it is that they want, you come up with a plan that they agree to and then you build the thing and you give it to them.

32:48 I don't see how that fails because that is the way every great product has been built and it's the way that I think every great product will be built going forward. >> Cool. That's inspiring and I yeah I tend to agree with you. I think that the FD is an inherently humanoriented role and I think there's something more sustainable about that probably long term. one other question about the role that I think folks have is what does the career ladder look like? Like how like I start out as an FTE then I become a senior. This is great. I love it.

33:18 >> This is my favorite question. >> So, something like very awkward happens when you leave Palunteer and go somewhere else >> because at Palunteer, FDE is a terminal title. You are hired as an FDE on day one and by year 10, you will still be FDE. Our head of commercial, which runs our entire commercial business, that is I can't say exactly how much, but that is like more than nine zeros of money. His title is FDE. So this is in the palunteer spirit like there is not supposed to be anything beyond this.

33:52 but you know there's companies now that have senior FD and staff FTE and and like that that's fine right like people can take the title and do whatever they want with it. But I would say the way that growth works in a role like this where you are customerf facing and at the end of the day you are outcomes focused and delivery focused is that gradually you start taking over larger pieces of scope. So perhaps at first you would not be expected to own a customer account at all. You would work with, you know, someone more senior who runs that account and you'd work on one slice of that customer's problem. Perhaps in time you own a customer all on your own.

34:27 Perhaps in time from there you own all customers in a industry, then in a sector, right? Then in a geography. the way to think about it really is that and and this is the model that they teach us at Palunteer, right? you are given a company. You are now CEO, CTO, call yourself whatever you want of a company. You have one single customer. You are not allowed to get more. Your only way to make revenue is by making your customer as successful as possible. If you do that well, maybe we will give you more customers. That's the way I would think about growth.

35:02 >> Got it. That makes sense. So you evaluate a FTE seniority or sort of skill level based on the scope of work that is involved and and usually via size of company in terms of revenue or or impact that way basically. >> Exactly. Yeah. So like how much business are you supporting and then how much business are you supporting both individually and through perhaps the people that you manage or lead. >> Got it. Okay, cool. that makes a lot of sense. Is there anything else that you think would be helpful to share about the role, about the recruiting process, or anything else in general before we start to close out?

35:38 >> I really want to emphasize that at the end of the day, I think it's a really, really special job, but it is just another job. Like this is, you know, not to like pour cold water, right? Like this is not going to be the job that fixes all of your problems. I assure you there's a lot of FTEEs at really good companies, Palunteer included, that are absolutely miserable. Like don't think of this as the one thing I've been waiting for and like this is going to be so great. this is a profession the same way that software is a profession, the same way that product is a profession. The same way that talent is a profession at at the end of the day, right? If you want to be a successful professional, you just have to choose what it is that you think you're good at. Choose what it is that you think you could do and then find a role that kind of blends all of that together. And for those of you who, you know, see FTE as your path, I wish nothing but the best for you.

36:31 >> Yeah, I love that. And yeah, fundamentally the skills themselves are not changing. It's just kind of the shape and the titles and the roles. And this is a new exciting opportunity for people who align to that. Thank you so much, Kevin. This is like super helpful, valuable information. You've been really awesome at kind of guiding people through this. Is there anything else about finding you? Like folks watching who want to maybe learn more about you or or read anything that you've writing or anything like that?

36:55 where can they find you? Thank you so much. I really appreciate that. So you can find me on Twitter or on LinkedIn, ZKBY. and then I'm also coming out with an FTE podcast. I I'm very lucky to own fdpod.com. and also FD pod on Twitter, on Substack, on YouTube. come in all platforms. So, if you want to hear me yap about FTE, give that a look. >> Cool. we'll include the link below as well for folks watching. And, yeah, thank you again so much, Kevin.

37:28 It's been really great to have you on and, talk all about FD roles. >> Thank you so much, Stephen. I really appreciate the opportunity.