Episode 8 | A Deep Dive Into Engineering Leadership Roles, Part 3

Eiso: Welcome to developing leadership, the podcast where I, Eiso Kant and my co-host Jason Warner, talk about the lessons we've learned about engineering leadership throughout the years.

Today we closed the chapter on our deep dive into different engineering leadership roles and cover some of the most common questions about engineering managers and tech leads. Such as how to pick your first tech lead in, should you promote from within or bring somebody new, and the fallacy of non-engineers managing engineering teams, how the roles of detect lead and EMs change as the organization grows and, much more. As always, if there are specific terms or topics you would like to learn more about check out this episode's show notes, linked in the description.

[00:00:43] Hey everyone, I hope everybody had a good week. Jason and I are back actually for part three of our three part series on engineering leaders at different levels and different stages. And, you know, what do the roles mean, and how does the progression look like as your company changes from an early stage startup to hopefully a large behemoth?

[00:01:05] And so in our last episode, we ended on talking about the role of the director, and so today we're going to kick off on the next level in the organization and where the rubber starts hitting the road even more so, the engineering manager, the Tech Lead and the team construction that sits from there. So, Jason, I'm going to start you off with an easy one, your first engineering manager hire, or your first tech lead hire at a small startup. What does that look like? What do we have to look for? And. What's actually the difference between Tech Lead and EM, and how should people think about it at this stage?

[00:01:41] Jason: Awesome. Yes. So this is probably one of the more common questions and it actually starts out of, "Hey, I think I want to hire a Head of Engineering." Typically, whenever someone asks me, I want to hire my first Head of Engineering, we get into, "talk me through your EM structure with your Tech Leads," even faster. And the reason why is most people are sitting there at a certain size, let's just call it like 10 to 12 to 15 people somewhere in that range. And they're starting to say, "I can't do all this myself anymore." And we start to have that conversation about head of, and which quickly becomes, how have you organized your company at the moment and talk me through managers and Tech Leads.

[00:02:19] So here's roughly how I think about these, is that when you're small enough early enough and kind of growing, to go top down from the organization engineering manager, or sorry, VP, Head of Engineering, Director, and kind of build that way too hierarchal. It's almost like waterfall organizational construct, as opposed to building up organically, just what you need just in time as you do it. And so this is where Tech Leads and Managers come in. And why I say Tech Leads and Managers is because I think the first thing you actually need to do is Tech Leads. Most CTOs who are founding members of the team should say, "I'm going to start putting tech leads in place to handle day-to-day stuff like PRs and code reviews and make sure the right tasks are being worked on and things of that nature.

[00:03:03] Well, you yourself in all likelihood, the CTO or somebody like you is handling more of the one-on-ones or the organizational things, but you're not going to go redo it all at once by hiring top staff. But then you get ready and your tech lead is starting to get stretched too. And you yourself have too many people, maybe around 15 to 18 to 20 mark. And then you start talking about managers. And the managers come in and you say, "all right, I'm going to pair you with a tech lead. You're going to become a pod of people on a very specific focus. And you're going to basically break up the duties of one side technical, one side organizational, and be paired together in that way." At the root of it, at the simplest, that's how I think about it. Tech Lead handle day-to-day Tech, Manager handle day-to-day people.

[00:03:45] Nobody's really thinking about the long, long, long, long long-term outside of the CTO yet. And I mean, long term, in terms of like organizational philosophy, career ladders, HR review processes. No one's doing that just yet, and like likely don't need it just yet either. So you can go that route and still and still continue to build as fast as possible.

[00:04:06] Eiso: So I'm probably going to hit you with your second most common question that you get is around the notion of, "Hey, do I promote from within, do I bring somebody in?" And you know, there's the sad, I actually, I don't like it, I don't even believe it's true. But there is kind of the notion or almost joke in our industry of like, you know, "Who is going to be leading the team? Well I walk in the room and I see who actually speaks up."

[00:04:29] And frankly, I personally really hate that we say this in our industry. I spend a lot of my time with engineers and frankly, I think it's, it's a fallacy. I think we don't give people enough room to develop into leaders and has absolutely nothing to do with who's the first person willing to speak up. But that's kind of the state of a lot of companies, you know, of how they kind of pick their first tech lead. How do you look at this and, and where should that first tech lead and EM come from and how are they different?

[00:04:55] Jason: It's funny that you say that, because I think it's actually less to do with obviously who speaks up and who actually does the work. And who does the work is just, go and look at GitHub, who is actually commenting on the code reviews and who is, who is having those conversations in Slack or wherever you're having them more and GitHub, et cetera, and chiming in on the issues. And you have to kind of use a little bit of stupid human trick here territory too, see who people respect in there, because somebody can speak and everyone stops listening, and another person can say two words and everyone is hanging on those two words because they carry so much weight and you need to be tuned into the organization to do this.

[00:05:33] But where do I look? I try to look for tech leads almost exclusively internally. They need to have some context, Managers can come from outside and likely do in many scenarios. So, it's highly likely you, you have a manager as well, but it's almost guaranteed, you should have had at least one Tech Lead from inside. But this also goes to engineering hiring philosophy.

[00:05:53] So let me take a step back and say this, let's say you have 10 people in your organization. I'm going to break the world into amateurs, pro-ams and rookies. And maybe that might be a divisive way to say that, but like, let's just call it, early in your career, you're basically are amateur status as an engineer. You have a skill set, but you don't know the full totality of the game that's being played yet. So you need to sit there, perform your skillset, but learn the rest of the game and the nuance of it before you can move on to the higher ranking of the Pro-Am status to become a pro. And then when you're a pro you can become a Hall of Famer. There's like a simple progression. But I'm just going to lay it out that way.

[00:06:24] If you're a 10 person startup and you're filled up with pro-ams, you're in trouble, because you have no one to actually teach the nuances or to help people understand that. And if you're 10 person startup and you have all pros, you're likely also in trouble because you're too far outside the bounds of balance where somebody somewhere is going to say "that job is not for me. It might be even below me." by the way, that's a bad culture fit in almost all startups as well, but it happens, it happens more often than we'll want to admit too.

[00:06:52] I suggest a balance. I think that you're going to want to end up with the majority of pros, let's say out of 10, you're going to have five, or four of those. And then at the minimum three. So just I'm giving ranges here, just to give you an idea. Then you could fill two, three, almost, think of it as a bell curve. Whatever that number is, try to do the other side of pro-ams, and then the bulk filled up the middle filled up, I'm sorry, amateurs. And then the other filled up with pro-ams. So again, 10 people, three pros, three amateurs, the rest pro-ams, and they kind of have a good ratio in the middle there.

[00:07:27] Now, obviously that gets to your own ability to understand who is which level then too. But I'm just trying to give you a way to think about that.

[00:07:33] Eiso: I think it was a great way, so I want to even take a step earlier, you say, you know, who has the respect of the team who actually, you know, really as a Tech Lead really understands, you know, what's happening. I found myself in discussions over my career, where the person who has the respect of the team on the technical side, who everybody listens to and says, "Hey, I'm, you know, going to drop everything and respect you, is often great in the architectural discussions and the code review discussions, but is not necessarily the person who makes a great people manager.

And so where do you, you draw the line of a tech lead and kind of the follow on to that is, should you always have a tech lead and an EM as part of one team, or can you have a team where you really only just have an EM who functions as both the people manager and routes, or is the tech leads themselves? And then how do you look at this and what should we be looking for?

[00:08:30] Jason: Well, I think in general, let's take a step back and say that, if you have a CTO who is a highly technical CTO and an organizational people person, and has some product sence, they're unicorns in the industry. Like there's just not that many of them that can, I don't mean technical and like coding or talking at a level even anymore. I just mean just broadly understand the industry and all that stuff too. And they're unicorns these days.

[00:08:55] I think we make that mistake. I think we understand that at the CTO level, people will say, "Hey, I need X, Y, and Z, now." It's becoming more common to petition it. But we still make that mistake at the Tech Lead. First EM level, which is, "Hey, you're the most technical person and you're now the manager." That's the most common pattern. You're the most technical. Everyone respects you, you're the manager. That to me is like, "no, you're the tech lead", that's the person you make the tech lead and then you can balance them, but they might have the skillset to become the manager, but that's a different distinct decision that should be made. As opposed to the other side.

[00:09:30] Let me give you a little story here. This is actually how my career started. I have a friend who, we both joined the same startup company in Scottsdale at same time. Engineer nº2, Engineer nº3 , we signed on the same day, I picked number two because I signed five minutes earlier then.

[00:09:44] So that's why I get the distinction of nº 2. At one point, the team grew to seven or eight. And all of us became frustrated with the way that the company was being run and the team itself. And we said, "Hey, we're going to try to approach the CTO and make a change and suggest something." And so, I drew that stick or that short straw, I guess you would say, because mostly because I was the one who was organizing everybody in the time. And so they looked at me with a certain type of respect and they said, "Hey, would you mind having this conversation with the person." And so I did, when I had that conversation with the person, there was actually a huge moment of relief with the CTO because he said, "Oh my goodness, I'm so glad you said something because I've been feeling that too. And I feel like I'm letting everyone down and I was going to approach you or my friend about becoming the manager of the team. You were the only two that I can think of that could do it. And I was going approach you two."

[00:10:39] Now, this is about 15 years later now at this point, where we are today, and my friend and I went very different ways in our career. And it's exactly, I think in that moment, a good story to tell, because I obviously wanted to become an executive and ran CTO of GitHub for four years, et cetera, et cetera, et cetera. This person is the highest level principal, staff level, distinguished, whatever you want to say, those things, engineer in the most technical types of companies in the world and we couldn't be more different in terms of that side of us. And in the moment though, that person, that CTO looked at us and said, "there is an equivalence between you two in terms of becoming a manager." And it was because he was so technical, but because I was organizational and he didn't really see the difference between the two.

[00:11:26] And I think that is actually what happens in startups really early. And I, I encourage you to understand that there should be two distinct roles. Now, this person, my friend and I, we paired exactly as I'm saying. I was the manager, he was the tech lead. We talked about all those things and I said, "I don't know how to go do this. Can you go handle that portion of this? Like I got that part of the system, you go make sure that we're all getting raises. Ah, got that part of it. Let's go have that discussion." So taking a step back, I think people should be encouraged to think tech lead and manager, which is obviously a lot more common these days and to understand very different skillsets.

[00:11:58] Eiso: I think that's a great way of setting it. Gladly doesn't happen in most companies anymore today, but I think we should just call it out once and for all, non-engineers being managers of engineering teams, can we once and for all say, There really isn't ever a case where that makes sense.

[00:12:17] Jason: I don't know how we got to this point where it was possible, where we kind of said that you don't have to have a base level understanding of a blind function and maybe it's because other industries have done this, maybe other roles. But it still seems weird. I don't think anyone would put me in charge of the sales organization exclusively. Now CEO is different obviously, but no, one's gonna say, "Hey, Jason, go become a CRO of that organization over there." It's just not going to work. So we wouldn't do the same thing, in engineering. Uh, no, you have to have, you have to have been an engineer or, and you have to understand engineers.

[00:12:49] More than anything just to be really, really, really, really, really blunt is you can't lose the respect of the people that you manage. You just can't do it. And the easiest way to lose the respect is to not understand their struggles. And if you don't understand how to be a developer, or what they're going through, you're not gonna understand it. And so this is also why it's dangerous for non-technical CEOs to come in and say, "can't you just." Easiest way for any CEO in the world to lose all of the respect of everyone in engineering is "can't you just," it's the complete inappropriate way to ask a question of a highly technical engineering.

[00:13:23] Eiso: I'm glad that we got that clear for everybody Jason, it never makes sense. And it always ends up in the terrible miscommunications when we have engineering leaders that don't come from an engineering background. And it's a shame that we had that small blip in time where we're industry looked like that. Gladly, I don't see it a lot anymore today, and I don't think we will see it much moving forward, but if anyone's listening to this, finds themselves in that situation, and I think they can hear the very opinionated, the answer that we both have on this.

[00:13:51] So let's get back to what we were talking about, right? So you have the tech lead and you have the engineering manager at this early stage. You started off by, you know, people at this moment often start thinking about a Head of Engineering, but should actually be first getting their Engineering Manager. And Tech Lead in place. At what point do you go from having a couple of engineering managers to the next level and how does the role of the EM and Tech Lead change as the organization itself grows, but the team size often stays the same?

[00:14:26] Jason: There's an art to organization building, and it's not one variable that you can really pull apart. So think about it this way. Imagine that you, your team size is going to stay the same for the next 18 months, but it's complete chaos inside your team in terms of organization or execution. So you're not growing, but you're also not executing well. So maybe it's time to do that. Well, let's say you're executing well, but you're about to triple in size. Well, that's going to change the answer entirely. Just, just the two variables, one being static and one changing. Now, imagine you're adding all these other variables, in terms of maybe the product is expanding, or you need to do X, Y, and Z feature, or you need to go deeper, which means you need to change the expertise. So maybe you're no longer all front-end and you need to go to back-end systems, which is a classic case for most startups. You're going to build a lot of front end stuff with no infrastructure, but all of a sudden you're having success. You got to build out an infrastructure or a data team or something like that.

[00:15:24] Again, changes the expertise. So there's a lot of variables, but I would say this, generally, for the most part, you try to keep the organization flat-ish as possible. I say that "how many levels do you have from CTO to line engineer?" You get past a certain level, and there's no ability to actually understand what's happening inside the organization. And most startups pre-product market fit, should that number should be tiny, like two max, like, you know, between CTO and Engineer. Hey, you know, obviously at Salesforce size of post-product market fit you can add more layers inside there. But you get my, my general feeling on this topic.

[00:16:04] And then I also think you should actually understand what you're optimizing for. So again, answer the question. "What are you optimizing for?" Hey, we need to speed, speed up. We need to execute better. We need to have better context and allow people to be more autonomous. We need to scale really quickly because of what we're going to go do and all that sort of stuff. Again, understand what you're optimizing for is going to change it. But the general feeling here is that what you need to do is orient everyone around a mission.

[00:16:29]  Mission could be for the entire company or for the local team. That team should grow past it's max-, whatever you perceive to be your maximum sustainable point for it. And then you can have a conversation about changing the structure in terms of, you know, splitting it or adding another manager, or adding two teams, to one manager. But the point being don't prematurely optimize your organization from the splitting it and building the perfect hierarchy, well past comfort to the point of extreme, almost extreme discomfort, and then make that move.

[00:16:59] By the way, the reason why I say that is because too many people take the step prematurely, which, we all know how many lines of communication happen. You have two people, what's the line of communication. You have three people, at five people, if you have never looked at that chart, just understand that the moment you get to that to adding more teams, your organizational communication flexity is through the roof.

[00:17:21] Eiso: Yeah, I think this is by the way a chart, that's definitely going to be in the show notes, because if you haven't seen it, I think it's, it's, it's very shocking. The first time you actually look at that.

[00:17:29] You mentioned something around, you know, there there's this point where you start scaling and things start breaking in the early days, right it could be either a data team and infrastructure have stronger focus on the backend. Well, the tech leads for those teams have of course obvious differences between them of what their expertise are, domain expertise. Do you think that an engineering manager between a back-end team or a front-end team or building a data team is the same person that will be great in that role for every single one of them? Or do you think the technical expertise or domain expertise of the team also impacts the EM, not just the tech lead?

[00:18:05] Jason: I think that this, I still have, I still have a position where I think that the domain expertise matters here. I think it is less hard of a line for me than non-engineers managing engineers obviously. But what I really talk about here is understanding again, what you're optimizing for and then what, whether that person has the right personality for it. I think this is the personality traits that I really like in leaders in general, which we talked about in the past, that to summarize is these are people who are driven on their own. They, they don't wait to be told what to go do, they go and figure out what to go do they're, they're not afraid to have tough conversations, and they're really proactive. I call them self actuated individuals. And then of course, it's the distinctions, maybe someone is more cautious or someone is more experimental or, and then you can understand what your organization needs too.

[00:18:55] Well let's let me use application engineering, infrastructure engineering, and data engineering as three distinct entities. Right now, and I'll say what I'm actually trying to do is create an organization that understands what each one of those Meta organization's role is. So here's how I would construct it. The most interesting one right away for most organizations is application engineering and infrastructure engineer, because that's where you end up starting. And how I test. I tend to tell people this "alright, you don't have the same goals. You really don't. Application engineering. I want you to be as fast as possible with the highest quality possible, but you need to be more experimental in your mindset. Infrastructure engineering, I want you to make it so that things are as safe and resilient and reliable as possible." Now, if you think about that, that those are in tension with each other. Application engineering. I just told you to go incredibly fast and you're going to want to go do X, Y, and Z, but you're going to have to use things from infrastructure who I just told to be resilient and reliable and safe.

[00:19:53] Well, there's a reason obviously for the tension, for the distinction, and the tension is a natural byproduct, which actually has to manifest itself at some point in your organization. And the overlap is interesting and that is where you'll start to have a lot of the conversations. And why I'm saying this now is that, to not give them the same goals, because you, you will not understand why something is broken because they're all oriented towards the same thing. And then you'll say, well, now all of engineering has to be incredibly safe, stop feature development, because we've got to restart the databases and we got to blah, blah, blah, X, Y, and Z. That's not how you need to run these things that need to run independent to a degree. And so that's where the tension comes in and the internal systems have to allow for that.

[00:20:37] Eiso: And so the person who's running, who's the EM, let's say we're an EM on infrastructure engineering, EM application engineering. When you're looking to how to promote internally or hire for that role specifically the EM not the tech lead. Are you looking for a different person? Are you looking for the more cautious, you know, calm person on the infrastructure engineering while you're looking for the, you know, high energy, let's move really fast person on application engineering?

[00:21:05] Jason: I think classically yes, and you don't go, I don't think in this world, you go wrong with those, those classic patterns. I think it just makes sense. And there's a reason why it makes sense. So what I really am looking for on the backend side of the world, I'm looking for someone who's almost unflappable. Because, let's just be really, really honest, at scale, let's just take GitHub size as the scale there. If you ever received that sort of success, congratulations. But every day is, something's broken, every single day, something is breaking, whether you're getting Paged, whether you're getting DDoSs, whether you're getting attacked, whether you're getting something is broken. So this person cannot have that sort of same sort of frenetic energy, but only flip it to what they should have. They should just be unflappable, they should just say "we're going to methodically, going to work, keep working through this. I'll understand when something is a minor fire versus a major fire, but I'm not going to be the one that's going to say, take everything to the highest defcon level everytime.

[00:21:55] On the other side of the world, the application engineering, why the pattern works is because higher frenetic energy leads to faster turnaround results. What's interesting though, is look at the failure modes of each one of those, and then understand the question about what type of person you want and what the failure mode you're able to handle is. High frenetic energy people can lead to a little bit more chaos, like free radical chaos type stuff, but that produces energy too. That's like the whole point of physics is things move around really fast, produces heat, produces energy.

[00:22:23] On the other side someone might be a little bit too passive. They might be a flappable, but it's because they're going to be methodical and you have to understand what kind of risk profile they're going to take. So a good example of this would be whenever I'm looking at something, I'm going to tell people ahead of time, what kind of risk profile I'm looking for, and I say, "Hey, I am not, I'm going to be about 20% cautious. I need to know 20% of this, and I need to move a little bit faster than cautious here, so give me all that meat and potato part of this don't give me any of this, the side dressing, and I'll make a decision. If it's something super critical and like, I'm going to be a little bit slower and I'm going to need 60% of all of this information here.

[00:22:59] And what I'm really trying to do is show them that there's different modes you need to work in for different things. So I think that's the more interesting side to understand what you're getting, but also what the failure mode of the person individual would be. And also what you want out of the profile.

[00:23:10] Eiso: Yeah. And what you're almost describing right now is right, the pros at the EM level. And taking the analogy that you took for, for ICs, the amateur pro-ams and pros, and, and then kind of the Hall of Famers. When you're that small, early stage startup, and you're, you know, you're getting your first engineering manager to lead your application team. Maybe you don't even have an infrastructure team yet, or just about to. You know, in a lot of early stage startups, the person who is that EM, is a first time EM. How do you look at that first hires on engineering managers? Does that have to be a pro am or pro can it be in, an amateur? And, and what point can you say? No, we can no longer have amateur engineering managers in our organization?

[00:23:52] Jason: This is a little dangerous territory because I think what you're actually looking for someone who could be a pro, you know, I don't think everyone actually becomesa pro, for what it's worth. I think a lot of people kind of stall out on pro-am territory. This is not a derisive comment. It's more of like, just be honest with like what happens in the market. I think that from a manager perspective, let's go to sports one more time. It's very often that there is a high caliber, high potential person who people in the locker rooms respect. What is on the younger side or earlier side of their career, they still get the captain label many times. And engineering manager is very similar in that way. It's, it's about respect and their ability to can draw attention and keep people tuned into it. So in that regard, I don't shy away from pro-ams in that category at all. And many startups out of necessity, because of maybe hiring might put an amateur in there.

[00:24:40] I think amateur is a dangerous one because the amateurs are going to make mistakes that they don't know about for some time, because of the feedback loops on engineering management decisions. And they just don't have the intuition that even pro-ams might have because of natural ability or talent, or at least some experience. So I don't think pro-ams are dangerous. I think you have to understand, again, failure modes of what to look for and maybe to give them a coach, but a pro-am on their own without a pro around to some degree or a mentor somewhere else, or somebody to bounce ideas off of can obviously get dangerous because they've never been in a playoff scenario.

[00:25:13] We talked about, again, I I'm a big sports person. Everyone knows this. They've watched me on Twitter, or read my Twitter, but there is a difference between spring training, regular season, and post-season in terms of, you know, just gain pressure. And if you think about having your captain be on the younger side of their career, there's a lot of upside to. But what happens in the playoffs is that person might still make some decisions or two, but there's always got to be somebody who has more experience because there's always somebody, even if it's a veteran who doesn't play anymore coming in and calming the situation because that's the most common thing is people get way out over their skis and they're just super hyped up, and the moment is too big for them, as we say, that's when the pro comes in, says "calm down, breathe, our training will kick in, the game plan is here. Let it come to you. Don't pressure the situation itself because that's how it falls apart. That is that classic meltdown scenario that we always talk about in sports.

[00:26:11] And that's why pros are so important. This is also why you, Eiso, you particularly see me harp on this. This is also why I harp on for early stage companies where people are taking money from VCs. It is so dangerous to take it from just lifelong investors, exclusively in your captive. I'm not saying don't work with lifelong investors, but if you don't have any operators on your cap table or as investors is very, very, very, very dangerous.

[00:26:38] Eiso: So I, I really, I mean, we've had this discussion before, so, you know,I really like what you're saying and it resonates a lot with me, but I'm going to bring us even a step more tactical or to the day to day. When, when I see early stage startups getting their first EM in place, it often is someone who has been part of the team as an IC. Right. It's it's still not often that they bring in from outside. And, and frankly, for partially what you're mentioning, the respect or someone in the organization who has that touch for people and is willing to have the conversation with the CTO like you were at that company.

[00:27:12] But in the early days, one of the main things that I see is that to go from, "I have an inkling or an aptitude towards becoming an engineering manager" to "I'm going to be a great people manager." I often feel that 80 or 90% of it is about teaching people how to have conversations that they're not comfortable having naturally. And this is a very basic thing. I, and I, and I've had great discussions, people over the years, with people who have I've mentored or coached. And even myself, if I go back to myself as a first time leader or manager, I stressed over conversations that I probably didn't handle great, that today, you know, feel like a run of the mill. When you go back to your early days and the engineering managers that you've seen be kind of first-time EMs, you know, how big of a part of learning, how to have good conversations and communicate well, do you believe as part of that role and, and what should we be teaching and telling first time EMs?

[00:28:08] Jason: In general, the positive conversations are always really easy and we kind of orient it too often to those, and we don't help people get through the tough ones. And I think its because also a lot the first time founders don't have the ability to have that conversation too. I do think it's critically important that you've come up with some sort of a, I don't want to say script, but there should be a certain scenario set, like, "Hey, there'll be someone who's underperforming for a variety of reasons. And how you approach an under performance aspect with somebody is one". That's gonna actually define a lot of your culture too. It has to arm them. You can't throw a new engineering manager to the wolves by saying, "Hey X, Y, Z is underperforming. You'll have the conversation with them." You're like, "What am I supposed to say? Do I go in soft? Do I have a cup? Should I be pushing back on you for even suggesting to me that they're underperforming? What's your perception of the performance?"

[00:28:58] Like there's a whole host of things. Most going, wow, I'm going to reference sports a lot here. Sports have the notion of this, by the way. You're young, you're talented. You're in the minor leagues for a little while. Then you can graduate and go to the pros for a couple of weeks a month. Maybe you don't do that well, so you go back down and you spend more time there. Then you come back up and you stay and all that sort of stuff. We got no notion of that here in startups. Like you're in the fight, you're in the pros, you're in the big leagues already just by being in a startup and managing people. And we don't even give them the skillset. We just throw them at back or send them right out on the floor or the pitch, we just say, "go nuts". You know, that's, I think a failure on the industry's part, but it's just the way the industry is.

[00:29:42] But if you're in a startup right now, and you're about to do this, I think that you should put together some sort of a small little doc that says, like, "here's how we would like to approach under performance, slow execution at a team level, that sort of thing." And model the conversations with folks, if you're one of the founders or the executives say, "here's how I might approach that situation." And you're gonna have to use multiple times as people get going.

[00:30:06] Eiso: No, absolutely, and I'm glad that you mentioned this actually, this has been our modus operandi for us a long time as well. You build a doc and you do a dry run, or you do a coaching with someone like, "Hey, let's have this meeting, let's mock it and let's see how it goes." And I think for me often the difference between a very young manager or very new at their role versus, "Hey, they're starting to get into, you know, pro-am territory" is the fact that they have learned and really how to do those conversations well, particularly the hard ones, like you said, the positive ones are very easy. And, and how to then actually mentor the rest of the team to do so as they grow up.

[00:30:44] So we we've kind of talked about the engineering manager really in the ideal situation, the people side of things, the tech lead on the technical side. And I think on the tech lead its domain expertise, the ability to gather respect from the team and the ability to communicate the final decisions in a way where the team feels comfortable with the outcome and that someone has made the decision and that they have been listened to in that decision-making the EM role seems to be the one that is, is often the more harder one.

[00:31:13] Once we go from startup, you know, you, you mentioned it earlier, you know, crazy high growth mode versus staying team size, you know, small, let's go into that crazy, you know, high growth mode and all of a sudden we're going from 10 engineers to 50 within, you know, 12 to 18 months. We can no longer promote just EMs from internally, we have to bring them in from outside. What are some of the differences that we want to look for in the people that we hire now for the first time externally and not just from internal promotions.

[00:31:42] Jason: So when you're hiring externally for any management position, one, I think is important that you involve some of the team in that. And two, I think it's important to understand that by bringing somebody in, automatically, one, you're distancing yourself from some of the day-to-day work, so you have to understand how you are going to interact with that person, but then also how that person is going to change aspects of the organization, whether it be culture, style execution, and obviously you're, you're hiring someone for that reason, but understand that it will happen, and too often, I see someone coming in and say, "Hey, we hired this person, but they're changing the way that we execute," well that was part of their job. Have you had the conversation about whether that was part of your expectation or not? Like, this is again about expectations.

[00:32:25] What I do look for coming in from the outside though, is I've said before, I don't like the word "culture-fit" and people ask me about this all the time. I say, "no, no, no. The person has to fit inside your organization and they have to, they can't be like square, peg round hole, but you shouldn't be looking for like, exactly how they slot in." I hate that whole beer test thing. I want to have a beer with that first type of thing. What you are actually looking for is if they are bringing something to the organization that it lacks. Like what are their skills and strengths and is that useful to you? And then do they match in some other ways that make sense? It's a very different way of thinking about the person that candidates. And more, more bluntly to what you need to understand is again, what you're looking for, what you want them to do, and what you think the organization could look like in a couple of years and whether or not they can achieve it.

[00:33:16] I've talked about this before on this podcast, and I've become a huge fan of this approach, but writing the two years from now exceeds expectation for any review we'll reveal a lot about what you want out of that role and that person. So if you're hiring a head of engineering and you said, and we grew to 50 people and we shored up the system and we got super fast here and we were able to, you know, hire blah, blah, blah, and X, Y, and Z systems and all that sort of stuff. You understand what type of role and person you're looking for. But if you, you know, that exceeds expectation review, as you grew to 10,000 people in a three-year time horizon, like that changes entirely the type of person you're looking for.

[00:33:52] Eiso: Yeah, I think that's a great way of talking about it. So just, I feel that we've, we've gone quite extensive now on the tech lead, the EM, how it changes hiring from outside. And you touched upon culture-fit, which I think we should just do an entirely, an entire episode on it in itself because I think culture-fit has been misused in our industry, in a lot of places. Is there anything that we, that we have that I haven't asked you today or that we haven't covered? When we thinking about EMs and tech leads?

[00:34:21] Jason: A couple of things that I saw, this is more of a general comment. A couple of things that I saw a lot in the last couple of years is that people want to prematurely optimize. And I think engineers to have a mismatched expectation about what it might mean to be in a startup, an early stage startup too. So one of the things I got questioned about was, "Hey, we're a seven-person startup and we're hiring our first Head of Engineering, we want them to focus on career ladders, HR processes, review processes, and I'll say, "do you have product market fit? Are you making money?" "Like, no, no, no. We're not doing that." "Like then none of those other things will matter. None of those things matter for you at the moment, because you have not earned the right, as a company to have those conversations, because you might not exist in a year. And this is all about priorities and focus.

[00:35:08] What I said is maybe too strong of a way to say that, but what I'm really trying to hammer home is you're not inevitable. As a company, you are not inevitable yet, and you're acting like you are. So I think you're not quite aligned to the existential nature of where you are in your curve just yet. I kind of come back to this quite often because I think that's what happens sometimes when engineers have this conversation too, they might come in and they say, I'd like to talk about diversity inclusion too early. And I won't say you're not, you shouldn't hire a diverse team, but what they're focusing on is like, who leads DNI at a five person company or a 10 person company? Well, we don't have HR yet as an example. Well then who leads HR like?

[00:35:46] We don't have HR because we don't have a Head of Engineering, it's just the founder, no one leads marketing it's the CEO still, no one leads sales, it's a CEO still. We haven't, we're not inevitable. I think that real sense of where you actually are in your curve is critically, critically important. You can't lose focus on building something of value that someone's willing to exchange money for. And if you have not done that to the degree where it's like basically automatic at this point, all the other stuff is, is, is one rung or two rungs down on the priority still.

[00:36:19]Eiso: I think that's an excellent analysis of what's happening at a lot of companies right now. And frankly, the money being thrown around doesn't help there. I think that's a great way to, to end on today. I'm very glad that we've managed. It took us about three episodes but we've managed to get through these different roles. And I also just want to say to all of the listeners, if there's a case or a specific question that you still have related to Engineering Leadership roles at different stages, what should we be looking at? How should we be thinking about it? That we haven't covered, because it's a broad spectrum. Please reach out to us on Twitter, speak to Jason or I, or at devleadership_ on Twitter. And we'll definitely come back to it because we know that this is a big topic and we've tried to cover it as well as we can.

‍