Episode 7 | A Deep Dive Into Engineering Leadership Roles, Part 2

[00:00:00] Eiso: Today, we continued our conversation on the roles of CTOs, VPs of Engineering and Directors of Engineering. We touched on the differences between technical versus non-technical, and founding versus non founding CTOs. When is it the right time to start hiring for VP of Engineering, our opinions on reporting line configuration as your company scales, and how directors can engage their organizations to ultimately build better products. As always, if there are any technical terms or topics you would like to learn more about, check out this episode show notes, which are linked in the inscription.

[00:00:45] Hi, everyone we're back. And today we're going to continue on our last episode where we're looking at the different levels of engineering leadership, and how the roles change over time at different size of organizations. And so, Jason, last time you and I left off talking extensively about the CTO and how the role of founding CTO changes. And we kind of left it at the point of, you know, what a CTO looks like at a series B company, and you made some very interesting comments at the end that even some very larger organizations like a Salesforce that has acquired Slack and has great, you know, CTOs and technical talent there, hasn't really made the CTO their key figure.

[00:01:29] So before we jump all the way to the Salesforces of the world again, why don't we kind of start from, how does the CTO look like post series B? And at what point does it all start looking the same? The floor is yours.

[00:01:41] Jason: Great. Well, I should say, I hope we can keep this to a two part series who knows maybe this goes to a three.

[00:01:48] Eiso: I think it might happen.

[00:01:50] Jason: I would say that this, let's say post series B CTOs, bunch of different considerations of factors go into this too. Is this a founding CTO, that's still with the business? Is it a CTO brought in from the outside? How big is this company at this point from a headcount perspective or how sprawling is the infrastructure or technology? Bunch of considerations. To distill it down in a couple of different ways, I think the simplest way to say is "founding versus non founding CTOs" at those stages. And then, technical versus, or how deeply technical they are.

[00:02:24] So finally, cTOs I think are different, and if you're a post series B founding CTO, your role likely is a lot of the heart and soul and spiritual aspects of the technology in the business as its grown. You probably have worn a lot of hats in the business, and you probably wrote some of the original code. So you're those considerations come into play. Your day to day and week to week and month ago, are probably uncomfortable for you to a degree. And it involves a lot of people conversations, a lot of performance conversations, and then a lot of aligning conversations with the rest of the exec staff or the product team about what we're building, and then really taking into consideration some of the data aspects.

[00:03:06] I would say somewhere between B,C or D going public, you're also talking about product bond expansion at some point, too, in all likelyhood a new product coming on board or, you know, expanding what you're currently doing and how you would configure the current architectures or infrastructure to go into those new domains.

[00:03:23] I think if you're a post series B in you're non founding CTO and someone brought you into the business, whether it be at the A B or at the C or something like that, it's very likely that it's because the organization was not run well. And I'm not, and I mean, just like it wasn't efficient, the technology might've been calcified, there were some poor decisions made somewhere else along the way, or they didn't have a founding CTO for quite some time or ever, and now they're trying to pay down some of that debt. And that job, it looks similar to the founding CTO, but you're probably much more oriented on execution, and really rigorous architectural integrity, making sure that the systems themselves can be scaled up and out and focused on that, that sort of side of the business. You're probably also less product oriented, to a degree. There's product oriented CTOs, and they could be unicorns in the space, but you're probably more technically oriented.

[00:04:19] Eiso: So you mentioned something here right, around this rigorous architecture, who are you meeting with as technical CTO at that stage? You know, what should your week or month look like? Because it's not just the exec team, it's not just the, maybe the VP of engineering that reports to you. And I know at a certain stage, some people will even go as far as having an office of the CTO. And so I'm kind of curious to see, you know, what does that look like in your mind?

[00:04:47] Jason: So I think at various stages, if you're going to have obviously very different people reporting to you, so it might be my example at GitHub I had several VPs reporting to me, the VP of security Infra, Data, Application Engineering, and Platform. They're all obviously responsible for very different things, but I would meet with them on a regular basis and members of their team or subsections of that team. So, when I first joined GitHub, we were having issues scaling some of the backend systems, not because the backend systems themselves couldn't scale, but because the way that the application was constructed as a monolith, there's only so many things that we could do from the database perspective. So we had to get creative on how we would do some of the backend scaling systems on the database side than on the orchestration side, and then work our way back up the stack to the application itself.

[00:05:34] So I started meeting with the infrastructure and specifically the data teams there. And then I started working my way back up that stack as the plans became more solid along those ways. But you can imagine that you're spending your time on any number of those things. I was meeting with the security team on a regular basis about abuse and fraud and bot detection and things like that. Like platform, health level type of things.

[00:06:02] So I think it kind of depends on your situation, but obviously people who are fundamentally responsible for the overall health of the company systems. And if you don't have those people, then you're thinking about how you build those people and build an organization that has those people. And then you're also looking at how, how you do this seamlessly into the future. And that is actually where I spent most of my time, was "this is how we look, operate and act today. I think we want to look, operate and act in a much different way, two, three years from now. And how do we back up to where we are, and then work forward again, to figure out what a plan would be to migrate to that point?" and then you have to ask the question, do I do it all at once? Do I do a piecemeal? Do I do a slowly over time? And you can see how these conversations would evolve.

[00:06:57] Eiso: And so you mentioned something related to reporting lines, right? You have the VP of infrastructure, VP of Data, VP of Security reporting to you at GitHub. But I've known quite a few organizations, those could be director or VP roles reporting to an SVP of engineering. How do you look at, you know, this kind of org line structure. As we kind of transitioned into talking about the, the VP of engineering role. Where should that line sit and is that boundary to same for every company, or do you think it's very specific based on the type of CTO and the type of VP of Eng that you have?

[00:07:29] Jason: I think everything should be considered around the type of people you have at the moment, also with a long-term idealistic view of what you want as well. So we've had this conversation in different contexts, a while back, but I'll go into it for this one too, which is, I believe as an executive in the organization, you need to act in two modes simultaneously, but the percentage of time in each mode is different. Those two modes are psychologist mode or sociologist mode.

[00:07:56] Psychologist mode is when you're talking to an individual and working with that person on an individual level, you know, career coaching or their hopes and ambitions and dreams, but also performance management or things of that nature.

[00:08:08] Then sociologist mode is when you take nobody, specifically, into consideration, and you're only thinking about the overall health and wellbeing of the company, at the meta level. The company exists, and you've got a thousand people, so that's a thousand mortgages or rent or hopes and dreams. And you're considering that the company needs to exist for those to be even possible. So that's what you get into.

[00:08:30] And I believe most executives spend too much time in a psychologist mode and not enough time in sociologist mode, for what it's worth, that's a different consideration, but. So taking a step back, you should being sociologist mode, you should think, ideally, "what would our organization look like? What would it operate like and how would it act?" But then you have to slip into psychologist mode too and say, "who do we have on staff? Who do we have that's available? Who could we get, or who do we have as stars?" And you have to kind of figure that out. It's the same way in sports, you can't just completely change up your team dynamic to go from an offensive oriented team, to a defensive oriented team game game. You just don't have the, you've not built that up over time, so you can't do it on the fly. You have to consider who you have as well.

[00:09:14] You know, ideally you would have done this work about thinking what the organization would look like three years ago, and you would have built to this point, but if you've not done that, you're at a point. So then you figure out how to operate that way. So, I would say that going to the direct question that you asked. You think about who you have on staff, you think about what they, their skills and their superpowers are. And then you kind of figure out what that looks like. So that's a very non-answer to your question.

[00:09:38] Here's the actual answer, or the specific version of it. I think that everyone is looking for a unicorn at the CTO role, and that unicorn is someone who can think about product, can think about tech, can think about the organization and can think about execution. And, truthfully there's so few people like that in the industry, that what you actually will end up doing is augmenting that CTO's strengths with somebody else in the VP of Engineering role's strengths. And usually if the CTO is hyper-technical or, or product oriented or a founder, you're going to act, you're going to add the VP of Engineering who is execution oriented and career ladder oriented and organizationally need oriented.

[00:10:17] And if you think about this from, I think we said this last podcast too, if the CTO is the technical side of the fence, the VP of Engineering is the people side of that fence and the people who build the technology and the technology that is built by the people, and they're kind of organized together in that way.

[00:10:36] Now, I don't believe that it's a good match when you hire a nontechnical VP of Engineering, because I just don't think that they have the right mindset to go in. This is a trend that we saw briefly, I don't think it ever fully took, but briefly in Silicon Valley where they said, "you just need people skills to be a VP of Engineering or an Engineering Leader." And that does not work. You need to have some domain expertise to be able to do that. But I don't think that you need to over orient to that as well. So I'll pause there for a second and see if there's something deeper. We should go into.

[00:11:10] Eiso: So, the classic situation that we end up seeing at most companies is actually what you described. We have the more product tech oriented CTO, and we have the more people organization oriented, VP of Engineering, and, while there are unicorns and different configurations out there, the vast majority of organizations that I also see fit kind of within, in that mold of having those two profiles. But then comes the very age-old question that we've talked a little bit in the past already, but I think it's good to bring it back in the context of this episode, when you have that classic product tech oriented CTO and people oriented, VP of Engineering, how do you want that to look like from a reporting perspective?

[00:11:53] Jason: Yeah, this gets tough because it's no longer about what you want to build for the company, its all about egos most of the time. And I think the best configuration is to have the VP's report to the CTO, but to get some of the VPs you want, they're going to want a seat at the executive table. And you could obviously say, "Hey, you report to the CTO, but you come to the exec meetings and you're on the exact slacks and mailing list and all that sort of stuff. But there's a different feel in that, when you don't report to the CEO, I also think that it's better in that configuration overall if-.

[00:12:29] I think the real question is asking "where product, design and engineering sit." So if product reports to CEO and engineering reports to the CTO and design could report to the CPO in that scenario or the CEO as well, I think you have an equal footing now. And the reason why is that there's at least one group who has direct access to a CEO, and the CEO is actually responsible for a thing. And the CTO is responsible for another. And there's very few organizations where the CTO and CEO are basically identical across the organization. And I don't mean identical in terms of personality, but I mean, identical in terms of even political power or influence or authority. And because of that, I think you can end up on equal footing.

[00:13:15] And we know that people love the "tension" that's created by a product and engineering organizations, like VCs are famous for saying, "I love that creative tension that's between product engineering organizations." Well, sometimes organizations are created to create that tension, and I think the easiest way to do that is to have the product organization report to the CEO and the engineering organization report to the CTO. And this is because that's classic human nature type of stuff. I ideally would have everyone report to one person. The engineering, the product, and the design folks report to the same person. We call it EPD in the world these days, and I like that more, personally, and that's why I think most organizations actually are looking for, and this unicorn CTO is the ability to handle all three of those. But because that CTO probably is not capable of doing that, they're going to have the product people report to the CEO.

[00:14:05] Eiso: Yeah, and I think there's another aspect here is that there's quite a few, particularly founding CEOs who do not want to hand off that product report. Right, they are more willing, if they have engineering CTO report, they still want to have that feeling and touch upon actually being closer to the product. And so, it's like you said, there's a lot of human dynamics at work. I think the EPD model is an interesting one for, for almost an entire episode, because it's still uncommon, it's still not the baseline. And it's a very interesting topic to dig into. But that's a, that's going to take us a lot of time kind of divert shows off of a goal for today. So, can we take it to the next step? We've we've really looked at what CTO looks like. And we've kind of started touching upon what the, the most common VP of Engineering looks like. Right? The strong people leader who is able, and excited about scaling an organization and doing the reorgs that are needed.

[00:15:01] And so, within that model, you know, what, what does the VP of Engineering's role look like, kind of throughout the different stages of a company? First of all, let's maybe start with, at what point should you be looking to hire a VP of engineering? What size are you when that really starts mattering? And I think there's, you know, funding stage, but also just size of engineering work that's relevant here. And how does that role change over time?

[00:15:25] Jason:  I'm not sure how common my views are here in the industry, so I might be going off religious tracks here too. Though I typically like to organize my teams around larger teams. I have a couple of principles I live by. One is, I like less communication overhead. So less times that one team has talked to another team to get something done. I like more autonomy for teams, so they have wider areas of controls so they can control more of the product surface area or their own destiny and ability to get things done. And I want to optimize for execution speed, velocity, and learning.

[00:16:08] So that said, it tends to be that where people might say, "Hey, a manager comes in and manages anything over five, six people." Like this is a classic pizza team approach, where I think eight is the theoretical cap of a pizza team or something like that. I tend to go higher and say, I would like a manager who might have two leads who are managing up to 12 to 16 people. And they're doing that because Leads will do the day-to-day PR work like a PR management or task management. The manager still does some of the, one-on-ones or the career management coaching, and also the meta alignment of like, "are we executing? Are we doing this?" sort of thing.

[00:16:44] And I find that in that model, while it's definitely harder to do that, from the Lead and the manager perspective, it's easier from the employee perspective. There's less communication overhead, and there's less like, "who is doing what?" and trying to figure out where the work gets parceled out.

[00:17:01] And so the organization itself is overall more efficient. So with that said, when do I think you start bringing in VPs of Engineering? Well I think you basically start with a Lead, then you bring in Managers, then you bring in "Head of", somewhere along the line. And I typically don't recommend getting out the VP title, because titles unfortunately are an actual non-fungible thing. It's very difficult to take, you know, VP of Engineering away from somebody at some point, if it's not working out well, but it's easy to give it to them, if "Head of" is an undersell of their capabilities.

[00:17:34] And so I think that you've probably start to look at head count somewhere along the way of like 20, 25, 30 is you start considering things like that because a CTO could have a couple of managers report to them to get away with 20 to 25 to 30 people. But somewhere along that, that threshold, the CTO, if they've never done VP work before starts to tap out in all likelihood and, or maybe just get completely disinterested in that work, too. I would say if you've reached 50 people without a Head of Engineering, 50 engineers, well then you've done something incredibly right, but also like maybe something's about to go completely wrong too. So really start to consider it.

[00:18:15] And, you know, GitHub was famous for a long time of having no managers, they famously said, "Hey, we want to have no managers," and I think that they went up to about 350 people with no "managers". And if you get to that point, just assume that you have a toxic organization and that's, you know, you basically have Lord of the Flies, hidden power structures. You have all of the things that you don't have in an org chart already, already implicitly in there, and it's not visible on paper anymore. So you often end up undoing it.

[00:18:46] Eiso: Yeah, I think this is the Zappos experiment, right? I think to a lot of us have realized that if you don't formalize the hierarchy, you're going to have an informal one. And having that informal one is often, far more brutal because winning informal power requires a lot more of the personality traits and tactics that are, are often in many cases, the bad drives out the good, so to say.

[00:19:12] Jason: And it's just a different skillset too, if you're able to survive and, I will go back to the Lord of The Flies, if you're able to survive and thrive in a Lord of The Flies situation, that's not typically the one that you would need in a well-run organization who is customer focused, execution oriented. There's just different, different skills.

[00:19:31] Eiso: As we go kind of from that, you know, 50 engineer, and I think a lot of people will find themselves with VPs of Engineering at 10, 15, 20 engineers, for exactly the reason that you mentioned, it's titles are often needed to recruit and can get us in trouble later on. And the fact of, "Hey, my VP of Engineering, should have really been a Head of Engineering and I need to hire a VP above them," which is why I think the famous SVP title, we start seeing it early stage companies more often than not. How does the VP of engineering role in your opinion change? When does it go from being a manager of managers to actually being more of a strategic role?

[00:20:09] Jason: So I typically think that when you, yourself, alright, so let me, let me take one step back. My view on directors, and this is going to be important for the rest of the conversation. My view on directors is they can fall in two camps. Directors can be Manager plus plus, or VP minus minus. And I would like to push organizations, particularly if you're at the B stage and you're hiring directors or a set of directors to kind of scale the organization, and you think of them as Manager plus, plus, you're going to end up with a set of people and organizational structures and inefficiencies that look a certain way.

[00:20:40] But if you think of them as, and hire for VP minus minus, you have a much different resiliency built into the organization right away. And I want them to be Directors versus VP minus minus. With that said, if you have a layer that looks like that at the director level, that's when VPs go to strategic, that's when they have room to think about business lines or think about PNLs, or think about product line expansion, or tech debt pay down, or just recruiting, so they can actually be more proactive on recruiting or looking at recruiting funnels or efficiencies or career ladders or compensation strategies and things of that nature too.

[00:21:19] So the director level is critical, I think, to unlocking the VP level to be more strategic, which is critical to getting the CTO, if you still have one at those levels, to be able to have the office of the CTO, to do incubations and explore things.

[00:21:35] Eiso: So you mentioned the minus minus, let's dig a little bit deeper into that. What really, at the director level is a VP minus minus? What does the minus minus entail? What do you see that is maybe missing in the role that makes it minus minus?

[00:21:50] Jason: This is squishy. And so people listening to this, they're going to hate this answer. But at the end of the day, what you want to almost be able to do is say, "Hey, would I trust you with a hundred million dollar year budget?" If the answer to that is no, then you kind of know, now that obviously that's an incredibly high bar and you're thinking about that very differently, but it's also a pretty simple thought exercise too.

[00:22:11] But what it actually to me means is "I trust you with a budget that big, but I trust you to make other decisions and you've got good judgment." And now here's one of the more frustrating things I see in the industry, is that people who have been in seat for a role for 3, 4, 5, 6 months, think are ready for the next role. And one of the more interesting things about erectors is people, you know, managers with breakfast saying, "Hey, I've been a manager for six months or a year. I'm ready for director. I've been director for six months or a year. I'm ready for VP." The problem is you don't know if your decisions you're making at the VP level are good or bad, sometimes for years. And so you need time and see to see how some of these decisions play out.

[00:22:53] And so for me, Director minus minus is "we know enough about your decision-making or judgment or your thought processing that you for the most part are right. More often than wrong, or at least you can figure out how to navigate inside there. And we've got enough feedback loops to understand that too." and I think that the way the industry is going, we're going to see more manager plus pluses than we are going to see VP minus minuses, because all roles are losing that sort of time and seat aspect to them.

[00:23:23] Eiso: So I think you touched upon something that's really powerful, the notion of time and seat. And this is not just eroding in tech, this is eroding across every single role these days. And I think the more funding that's in our environment and the more short that we're on talent and the fact that, you know, tech went from being a niche thing for geeks to every single high flyer in the world who is ambitious, is now drawn to tech and is no longer drawn to be at a hedge fund, that they might've gone to other places. And so the kind of managerial cultures that we saw, of like, Hey, you know, frequent and fast promotions to keep people on the hook, which is actually what I think famously consulting and finance really refined over the years. We're now seeing in tech. Except that there's one big difference with the finance and consulting world, there, it was, you ought to get promoted or you're out. Right. And we don't do that in tech, partially because people jumped ship before we could even let them be out. And partially just because it's not part of our culture. When we think about that in today's organizations, what are your thoughts on it? Let's dive a little bit deeper into this. And is there something we can do to remedy it?

[00:24:35] Jason: In general, Texas, obviously like you just said, become an incredibly attractive place to work. I think that the funding environment means that we're gonna have more and more companies, more and more opportunity. You've heard me say this before on this podcast, but I'll reiterate it, there's basically four different kind of things that are just in limited supply in general in the world, but it's money, time, ideas and people. But in reality, in our industry, money is all over the place. It's super prevalent. There's enough ideas, inside your own company, you're saying "no" more than you're saying "yes", so there's plenty of ideas. Time is constant. So really the entire game at this point is people. And its people to use the money efficiently to implement the ideas in a timely manner. Literally the game. That's the entire tech industry wrapped up into one big old sentence.

[00:25:27] So what that means is that you're going to have people that you're taking flyers on too, because they may not have had time and seat, because you need that role, and it's a pretty critical role, VP of engineering or Director of Engineering. And they're sought after, by every company in the world at this point. So what I really think is going to come down to is its gonna become a talent game, and industries are going to have to pay, or companies are gonna have to pay for the top talent. But what's going to happen then too is just like, what happens in sports, is that, mid tier people make more money too. And mid-career, but also mid talent people.

[00:26:03] So the average salary in the NBA goes from a hundred thousand dollars in the eighties and yes, there's inflation, but it has outpaced inflation to the point where the average salary is a multimillion dollar salary now, or something along those lines. And that's way past inflation, even past where probably the NBA is in terms of its overall monetary value. We'll see that in tech, but what I also think we'll see too, is that the outliers, just like in sports, the outliers at the VP or the CTO or the CPO roles, they have inordinate bottom line impact on their companies. And so we're going to see people overpay for mediocre talent. We'll see people overpay for borderline great talent, borderline good to great talent. And then we'll see under payment for the industry changers. And that's just classic industry dynamics about what we're going through at the moment.

[00:26:53] Eiso: I couldn't agree more, and if we, if we take this back to the VP of engineering, you know, like you said, the, one of the main roles for VP of Engineering is that recruiting. At what stage is it, does recruiting change for different VPs of Engineering at different stages? What I mean is when you're know VP of Engineering and a 50 person engineering team, it's still very much about recruiting those managers and then even the individual engineers. How does that look like in your opinion, once organizations start growing up to 50, 50 to a hundred to 500 to a thousand engineers, and maybe even at GitHub, you know, what was the VP of Engineering at GitHub still doing, you know, recruiting anything beyond the level of directly below them?

[00:27:35] Jason: So I think VP of engineering has it tough in this one, for what it's worth. I think CTO has a lot more luxuries that they can be afforded here. But VP of engineering typically is thinking exclusively about projects, their pipeline and the roadmap. And so they're recruiting to fill team slots. Whereas I think if you had freedom, you would be on the lookout for just talent. And then you would ask the question, "how can this talent help us? And what way would it be constructed?" But VPs, I don't think have that same luxury. And I think it's very rare actually for a VP to think that way, one, and two, to have the freedom to use somebody in that way too, because a lot of times they'll come back and talent will say, "well, you have one req open and it's on this team. You found this person and you want to use them over here. We can't do that. Yes, you can move it around. But that team loses it."

[00:28:29] This is, in my opinion, also where bigger companies start to become exceedingly aggressively mediocre is that they don't allow talent to come in and be found by somebody and be placed in a way that's creative to the business overall, because they have to slot into the current roadmap. CTOs though, I think can add a lot more leeway in this as they can find this person out in the market that they really like, and they say like, "I want to incubate a project around you. I want you to come in, report directly to me and help me understand this new thing that we're looking at or this existing thing that we have, how we might rearchitect this." There's a lot more, you can do there.

[00:29:02] I think if I were to project forward, what I hope to see out of more VPs is that they run their divisions like units. And what I mean by that is they think about talent that way coming in. So like "how could I use this talent in my group this way?"

[00:29:17] Eiso: So, dive a little bit deeper into this notion of VPs of engineering, starting to think about their organization as units.

[00:29:25] Jason: In my experience, this goes to the Manager to Director to VP, is how you think about the job and the role. So think about your, your job as Manager, it's "okay, I need to execute on our tasks in the week or the sprint or whatever you call it. And we burn it down, we get it done and we achieve a goal." And you know, you've got the time box. And the thinking scales as you go to Director, as you go to VP and yes, you got more responsibility, you probably have a budget and you've got to work with HR and things of that nature. But they don't think about their division as a unit, what I mean by that is, they don't think about it as "if I were to completely reconstruct construct this or, or organically just blow it off. And I don't mean reorg. I mean," how would I, how would this look differently to be 10 times more efficient?" It's more incremental along the way.

[00:30:13] And that's where hiring tends to be in a lot of people's minds, its incremental. You add a person to this team or this team, or this team. Maybe you create a new team along the way because you need to, because products had to go build a new thing, but it's not about like rethinking it. But if you're thinking about it as a unit, you're always constantly thinking about efficiencies or execution and wholesale changes. And again, like, I'm not just, I'm not talking about reorgs because reorgs are about shuffling a card from your deck to somebody else's deck, typically, it's like, "Hey, we moved it from the application engineering team to the infrastructure team and vice versa." I mean, in your world, you're thinking independent of everybody else, like, "all right, maybe we're gonna align exclusively around the API access to the infrastructure team on the application engineering team, but we're gonna reorient it completely differently, and we're gonna orient around these sets of peoples with these of KPIs and these sets of things."

[00:31:04] No one's telling you to go do that, that's you thinking about your group as a business. And so thinking like an owner, thinking like you're the one stop. I think again, most VPs of Engineering that I run into are incrementalists in this way, they think about product tools to go build this we're gonna go build this, we're gonna add five head count, and I'm gonna give three to this team and two to this team.

[00:31:24] Eiso: So I think we, we should probably spend an entire episode, digging further into this, because this notion of, and I see it as well, most VPs of Engineering, are thinking like incrementalists, but would love to be looking at their organization in the strategic way that you're currently describing. And if there's one thing that I see on a day to day, it's just the amount of load workload and time, lack of time that's being put on VPs of Engineering, make it almost entirely impossible for them to step away and look at anything but that incremental, "let's make sure that we hit the roadmap."

[00:31:58] Jason: And so I think this also goes to the lack of real true understanding at the executive level about what it means to run engineering organizations, because they will expect them to operate like incrementalist and every once in a while, they'll be disappointed that they're not thinking like owners. But they never give them the leeway, the space, or even tell them to think like owners it's, it's this lack of understanding. And many people need some sort of kick to say, "Hey, I need you, I really need you to operate in a different mode." And once they get the kicks, they're there, they can go do it. They need some coaching, maybe along the way, but in some ways they're not given the space to go explore.

[00:32:39] Eiso: And it's funny, you mentioned this because I've in the last weeks, had a couple of thoughts around that, while our podcast is for engineering leaders, it would probably serve engineering leaders best if their CEOs listened to it instead of them. Because it's exactly that notion of like, you know, there is a lack of understanding on, unless the, you know, a CEO comes from that background of, "Hey, what room do we need to give our VP of Engineering and our CTO?" because in most, most it really is just, you know, "just go execute and make sure the product happens". And it's, it's far more than that.

[00:33:15] Jason: We've gone through this a couple of times, but I had that talk, I give about building organizations that scale, you know, from two people in a garage to 5,000 people or so. And almost, almost to an example I can give, CEOs that I talk to say, "I would love for you to talk to my CTO about this very topic." and I say, "well, it's actually geared to you. It's geared at you because you're the one who will impact whether they are able to execute anything in here whatsoever." And they don't fully understand it until they get to a scale. Usually at scale they'll understand like, "oh, I actually have to think about priorities, and our goal setting structures and our time horizons for those, that's not exclusively a CTO job." Like, no, of course not. In fact, like you're putting the CTO at a major disadvantage if you think that that's what they're supposed to do.

[00:34:08] Prioritization is the simplest one. I've seen it too many times where CEOs say, "CTO, you need to prioritize all this work." And the CTO says," I need input from product or product to help me understand this". And it's this weird triangle of confusion about who is responsible for what. And that's when I've always went into the CEO and said, "you're talking about your job right here right now is to prioritize these things. You can't hand this off to either one of those. And if you do, you're basically asking them to immediately set up for failure with amongst each other and your expectations.

[00:34:40] Eiso: That kind of ends up creating the classic tension between product and engineering that we absolutely do not want. Right. We're saying, "Hey, go and battle it out here." And, and then whoever's strongest in most organizations, often the product org ends up winning. But like you've famously said on this podcast series a bunch of times already, at the end of the day, engineering is where the rubber meets the road and where it gets done. And so if we, if that relationship is not perfect, if that, if that information flows isn't strong back and forth, you end up with, you know, a wishlist of things that say, "we're going to go do X" but we're actually going to be building and executing the vast majority of it, just actually in this mode, that we're that we're talking about. That we're finding VPs of Engineering, and CTO's of just only being able to do things incrementally because you're running behind a roadmap without having any room to breathe.

[00:35:30] So we, we touched upon the questions on the VP of Engineering and really, I think it comes down to, you know, it's the role that makes sure that the organization is healthy to scale from a people and best practices, point of view, while the CTO role in many companies ends up being, "is, the organization healthy and ready to scale from a technical point of view," at least in the classic mode that we often see, where CTO is more technical and the VP of Engineering is more people oriented. At some point there comes this, the notion of the Director, you know, to hopefully the "VP minus minus." What happens in an organization in your experience, once you go from a VP having, you know, Engineering Managers with maybe Tech Leads below, and all of a sudden adding that middle layer in between? What's should organizations be look at?

[00:36:20] Jason: Yeah, no one can see us because we're on a podcast, but I actually put my fingers together and created a diamond in front of me. And I say, if you think about this in terms of like number of decisions that are made at each level. An individual engineer is going to make a set of decisions, you know, my thumbs coming together, my index fingers come together as the executives making a set of decisions. But if you look at how wide the middle band is, majority of decisions in the business will be made by the Directors, Managers, Teach Leads here.

[00:36:46] And if you think about that, if you're one mind and you're like, "oh my God, that's incredibly scary, because I don't know if I trust that, that band to make all those decisions." But if you're also on another bench, you're like, "oh my God, it's liberating because that means I can take all the strategic decisions and the engineers can make the critical one-way door engineering decisions, and everyone else could figure out how to navigate ambiguity in the business." and that's how you scale, and that's how you become a legendary organization, is that you have such a strong Director, Manager, Tech Lead tier, that they can actually handle and navigate that.

[00:37:19] So if you think about what that is from a couple of steps, steps back responsibilities actually become incredibly clear in that. Which is at the executive level, you need to make decisions that only you can make one way door, business level decisions. You need to provide enough context prioritization and all the variables around to give the director tier enough of that, let's call it "" "ambient information" so that they can navigate their specific department division group, to go build the things that need to get built.

[00:37:52] And this is why so many founding CEOs that make it to a certain stage get frustrated, because they say, "do I have to make every decision?" Well, you know, you don't have to, and you shouldn't make every decision. You shouldn't say that, "I want to see this feature or this thing." But what you're finding is that you probably either have not provided enough context or you don't have the right people in seat to take your context and turn it into product.

[00:38:16] Truth be told it's usually a double it's two sides of the story. You're usually not providing enough context and enough clarity. And you also probably have people who are not mindset-oriented to take some of that, navigate ambiguity and turn that into product.

[00:38:34] Eiso: A lot of the directors of engineering today find themselves as really being the people manager of engineering matters. And find themselves with having almost, you know, and being an information kind of gateway from the top down, but not seeing their role as much more beyond that. "I have six or seven engineering managers that report to me, and I want to make sure that they're running well and that the parts of the organization are efficient." What does that director role look like in an optimal world in your mind?

[00:39:05] Jason: Going back to the VP minus minus, what I would love to see, eventually I'd love to see, if you're a scale organization that directors have PnLs to a degree. Like if you have, if you can get to that point where you feel comfortable with that, you probably understand what they're doing. Now, you just can't construct it in such a way that every Director has a PnL, but you could maybe conceptually get what I'm going for here is that, they're oriented in such a way that its possible for you to do that.

[00:39:32] Let me give you maybe a context to how I think about this. So imagine, let's go back to GitHub, and we're at GitHub, I'm joining in 2017, GitHub is largely a code host site with PRs and issues on it that allow people to comment on various git commits and all that sort of stuff. I have an ambition, I want to turn it into a platform, the world's largest, most important software development platform. Where does my direct input into product begin and end with that? And how do I engage with the organization? Well, what I would ideally like to be able to do is say, "here's the strategy. We're going to turn it into a platform. We're going to build X, Y, and Z functionality. We need A, B and C vertical features that look like this certain way to serve a customer set, to do this. We need some depth and security or protections or blah, blah, blah." You get the idea.

[00:40:34] And then eventually once we sequence those things correctly, we release them over time in a two or three-year period. We'll go into the next phase, which is going into the cloud operations space, as well as the idea space. And we largely have what GitHub has been doing for the last four years. Let's say we're going in, and I say that, and a director level, somewhere who's in charge of building out issues, understands what we're saying. So that's amazing. We're going to bring more collaboration to issues. We're going to bring more team-oriented-ness as well as maybe workflows embedded in the side there, so we're going to think about it this way. It doesn't, I don't have to go have that conversation. They're oriented around the strategy, and are able to turn it and translate it into a world that they live every day.

[00:41:19] And let's think we bring a net new thing to it, which is GitHub Actions which became CI. Do I have to get involved and have a conversation around matrix builds? Well, no, I should not ideally have to get involved in the conversation around matrix builds. Somebody somewhere in the engineering or product organization says, "we think we need matrix builds for X, Y to Z reasons, let's verify that with customers, and then validate that this is in fact how we want to sequence this going forward with Jason or somebody else. An ideal situation typically.

[00:41:53] Eiso: Well, I absolutely loved that and can see that work incredibly well in organizations where product and engineering are so aligned. Dev tools, essentially. I know there's probably a lot of directors, you know, listening to this right now and going, "Jason, I don't have any of that power, because director of engineering for me means executing on product." And to be honest, in some cases, in some organizations, accounting software for dentists, you know, the product organization actually, it's right to have a lot of those those insights more. How, how do you see the Director or that role at an organization, where product is really not as straightforward as it is in a dev tool company?

[00:42:37] Jason: So I would hope that the Directors of Engineering in that world still understand the customer at the end of the day, to be able to have some of these conversations. And again, in an ideal situation in that world too, you might not know that you're talking to the Director, you're not talking to the Designer, the Engineering Manager or the Product Manager. You can kind of understand that they all have a view of it. I do think though that in, we'll call them "product-heavy engineering, execution, businesses" engineering in general is thought of as "just go build this, it's a matter of programming, just do what we say," and, that is going to be incredibly frustrating because I don't think there's ever going to change.

[00:43:21] And I don't, I mean, I, it's hard to say never, but I don't think that, I don't know if you can find a way out of that, which is why I think classically many engineers wanted to go product management way. And I think that was because they thought or felt, or truthfully it was, you know, maybe accurate that product is where those decisions were made. And everyone else was just implementing the ideas. My advice to folks in that scenario is to get more involved if they can, with the product managers and start thinking about the future of it and just doing what if scenarios? Like, "what if we did this?" Or what if we did this? Or have we considered, have we considered going this path or haven't considered building this way? You know, what have we found? What have we found when we talked to the customers, what we found when we compare ourselves to this side of the market.

[00:44:11] But there's a reason why, you know, I, as an early engineer, I left big companies is because I was just a simple matter of programming implementer. "Hey, now all that engineering has to do is execute. It will be a trillion dollar business." Well, it's never that simple. And if you view me that way, it's never going to be that way anyway.

[00:44:31] Eiso: So, finding ourselves in these product-heavy engineering execution organizations, and I like that term to think about it, what should the levers look like for a director? What are the things that they can pull out to really be excellent at their job?

[00:44:48] Jason: So, this goes to "core job" and then "secondary job". So the core job in all scenarios for engineering is to execute. So you always have to do that, but in product-heavy engineering, executer mode, like that is what most people perceive your whole job to be. So if you're not executing, your team is not efficient and your team is not executing well, you almost don't earn the right to have any other conversation anyway. So make sure that is taken care of. Your team is healthy, it's executing well, all of those sorts of things. Then I think that you can engage with product in a direct way.

[00:45:25] Or you could also think about how you and your organization as the engineers could build other things as well. I don't mean other things like adjacent to the business. I mean like, "Hey, in our area, we know it so well, we've noticed a bunch of things. Let's go change up a week. We think we'd want to run an experiment or we want to go change this. We want to go talk with customers about this. We think we've got something here that we can do." It's not rare, but it's rarer then I think we all think it is.

[00:45:54] If you could have a portion of your business that you could actually see as like a new business line too, it was like, "Hey, look at what we did here. If we were to pull this out and do X, Y, or Z or reoriented this way, we think we have another thing that we might be able to skew up and sell. You're showing an ability to think about as a business, but you're not doing it in a way that is pulled out of the product-heavy molds, you're still engaging with them in that way.

[00:46:19] Now that can be frustrating, because eight out of nine of those things will never see the light of day. And many of those will not even get taken up as, as valid contributions. But every once in a while they do. And that's when people actually hit their own escape velocity in those organizations. Sometimes they get pulled over into the product and started running things as a product person at that point then too.

[00:46:38] Eiso: I was about to say, I think when, when that's successful, the most common path is that the engineering leader becomes a product leader.

[00:46:44] Jason: Yeah.

[00:46:45] Eiso: So, you were absolutely right at the beginning, this is going to be a three-part episode where part three is going to, you don't have to dive into Engineering Managers and Tech Leads. Are there any final words that you want to talk about today, Jason that relate to the CTO, VP of Engineering or Director?

[00:47:04] Jason: I think in general, the CTO, VP, and director, if you were to ideal state things, just look like progressions, and they have maybe percentage orientations of, "Hey, I'm a little more people oriented, like specifically day-to-day people oriented at the director and then more strategic at the VP and then very product line or company strategic of the CTO." you know, skillset wise, just, they all have the same sets of skills, but percentage that they use on a daily, weekly, monthly basis are different. That's an ideal state world.

[00:47:37]  I don't think that you're actually going to end up in that scenario at most organizations. I think individually for people listening to this, to be honest with yourself too, maybe you're built more like a founding CTO than a Director of Engineering. And that means that you're still hands-on technical. You want to do the technical things. You want to scale to a 10 person organization, but you don't actually want to run a 50 person, people oriented organization. Just be honest with it.

[00:48:06] Now, the unfortunate thing is I think that. There are some staff level engineers that could do CTO type jobs, once the organization is at a scale, but they can't work their way up and don't have any desire to work their way up through Manager, Director, VP for that. And for those folks that are listening, if you're an engineer and you're, you're hearing that. That's when I think you hit staff level and you report to a CTO for some period of time or a VP of engineering. If they have that construction and you're working in kind of like gnarly technical projects, and then you're going to get your own project at some point in all likelihood.

[00:48:39] And so what I'd be doing there is keeping your technical skills sharp, learning about the people side, but really understand how to organize and execute with a 10 person team.

[00:48:49] Eiso: I think that's a great way to end today's episode. This was a blast, and it looks like there's going to have to be a part three.

[00:48:55] Jason: Awesome. Looking forward to the next one too. It's gonna be fun.

‍