Episode 6 | A Deep Dive Into Engineering Leadership Roles, Part 1

[00:00:34] Eiso: Hi, everyone, Jason and I are back again for another episode of developing leadership, and I think we both wanted to start off with just thanking everybody who has been sending us tons of great feedback and encouragement. I've really enjoyed that. And it definitely makes doing this extra special. Thanks so much everybody.

[00:00:50] Jason: It does mean the world, appreciate the feedback.

[00:00:53] Eiso: So Jason, the other day, you sent out a tweet, and it got a lot of attention. Can you tell us a little bit about what was in that tweet? And that might be a good intro to what we're going to be talking about today.

[00:01:04] Jason: Sure. These episodes will lag probably by about a week or so from when we're recording them. So by then, there'll be about two weeks since I sent it out. But the tweet was just question asked: would this topic be interesting, to discuss the difference between CTO VPE, Manager, Director, all of those things, but also at various stages. And the reason why I asked it was because it seemed that that was one of several, but probably the most persistent topic that I got on my calls with folks. And as we talked about before I meet with founders or CTOs on a regular basis, and even some seasoned CTOs at companies you know about we're asking the question, "how should I think about this specific role or the transition of several people from a manager to a director or, or hiring somebody out from the outside, when they were at X company and they have this title and what that would translate to us?" And what I found in a lot of those conversations was just, this is, would no one really knows how to do this well and talk about it, but also people are kind of like, "we could really, really have a deep discussion on this in many different ways, we just don't talk about it openly."

[00:02:13] Eiso: So before we dive into the topic, why do you think we're not talking about it openly yet?

[00:02:18] Jason: I think it goes back to what we talked about in a couple of the earlier episodes where, one, engineering is not the topic, most people inside organizations talk about, it's usually the last topic they say, "is engineering, executing?" that's the one topic that seems to come up. I think we even made a joke that a while back that the board once said "now all engineering has to go do is build it", and then, next thing you know, yeah, just that little part of the game. But I also think that this is not well understood, like engineering in general, we talk about, is not well understood. How you build high-performance engineering teams, how you structure them, how you execute all of those things. It's just not that well understood. It's much more well understood in sales, we talk about the difference between Sales and Engineering, which are the two largest orgs at most organizations will ever have. Sales feels so different than Engineering, Engineering feels very much like a team sport where at the end of the day, there's a singular trophy. That's held up and the entire engineering team is holding it. But sales feels more like everyone's on a track and field team. It can win an individual medal, and maybe the team wins the overall medal as well, but ultimately at the end of the day, it's like a collection of individuals on a "team ", it's a collection of individuals.

[00:03:29] Eiso: So before we dive into the core of today's topic, I'd love to unpack that a little bit. Probably none of us want engineering to run exactly the same way sales runs, like you said, which celebrates, to an extreme, individual achievement, because it's so measurable. But what are some of the things from how you look at sales orgs as kind of high performing that you would love to be able to see inside engineering?

[00:03:55] Jason: That's a really good question, and I would say that if, if I were looking at what I see in sales org and have seen over the years, and maybe even adopted myself, the one thing I appreciate most about sales orgs is it's kind of unambiguous. You're hitting your quota. You're not hitting your quota, you're, you know, you've got enough coverage, you don't have enough coverage. Almost to, I wouldn't say not to a fault because it actually works, but basically you can look at a spreadsheet and say, "great, we can hire 32 more reps. and we'll hit this number", in almost like clockwork kind of works. I'm not, not saying like there's not a lot of work that goes into the field or into selling we're into going out and doing these things. But, for the most part, there is like a formula and it feels like a blinker of machine, "here we go. That's how many we need. That's what we're going to get.", because of those sorts of things. And we don't have any of that. We cannot even think about that in Engineering, and the closest I think I've ever seen in Engineering to try to describe what happens is, you're sitting in outer space, looking down at earth and you see the coastline of California and it's this, "how long will it take you to walk from Seattle to LA?" And everyone throws out an estimate that's a 100% off in either direction. And then you start to zoom into the map and see what the coastline looks like, and then you're off by 1000% percent or, you know, whatever it is. And when you overlay those two stories together, you realize how different these two very large organizations are.

[00:05:20] So I wish we could have a little bit more explicitness and maybe obviousness in engineering, but also one of the things I do appreciate about most, really high functioning Sales organizations too, is the lack of ambiguity brings about a transparency, but also an honesty, a direct honesty, which is, "Hey, you're not hitting your quota, what's wrong?" Like, "blah, blah, blah, blah, blah". "No, no, you're not hitting your quota, what's going on. And it all becomes about a little bit of a personal accountability. And in Engineering it is easy to diffuse it from personal responsibility or accountability to team, which is appropriate in many cases in Engineering, but it can be abused too.

[00:05:57] Eiso: So I think that's a really nice segue into, into today's topic about these transitions of different leadership as companies grow, but also just actually, what some of these terms and rules mean to you, because like you said, I know very senior engineering leaders who still struggle to define CTO, in their organization versus VP of Engineering and reporting lines. So let me maybe let you kick it off, Jason with kind of laying out the field for, you know, what should we be actually trying to understand? And not sure we'll cover all of it in today's episode, but I think it will be a good starting place.

[00:06:31] Jason: Yup. So let's just define a set of roles to talk about first. We'll talk about, top-down we'll go CTO, VPE, Director, Manager, Tech Lead. And then we'll throw Staff Enj. in here, just for the sake of like rounding out everything, cause at some point Staff Enj. could come into play based upon where you are in context as well. All those things are at play.

[00:06:56] Then you have stage. Are you super early, let's call it sub 10 people, pre-product market fit. Are you post 25 people, are you post a hundred? That sort of stuff. Have you hit product-market fit? Are you making sales? All of those sorts of things. Then let's talk about dynamics. Is the CTO a co-founder is the CTO not a co-founder is the CTO and co-founder who's still been the business, or is the CTO a co-founder who has decided that no longer want to be involved in the business, or maybe you want to be doing something else? There's there's a lot to go into this here.

[00:07:30] And then you talk about also strengths and weaknesses of the organization, what the superpower, is like what differentiates the organization? If you're a super, super, super, super technical organization developing some of the most technical things in the world, CTO is obviously going to be incredibly technical, but so's the VPE. A Sales and Marketing organization, I'll use Salesforce broadly here, you likely have some people who are incredibly technical, but the VPs of Engineering, they don't need to be nearly as technical as the CTOs to get the same job done as for VPE inside Salesforce. In fact, sometimes that gets in the way, because you have to stop thinking about the technology because it's not about the technology at Salesforce.

[00:08:06] And then . Lastly, I think the most important distinction to talk about when you talk about all of this stuff together is the Director role, because the Director role starts to define at scale what you expect out of your organization, and why I picked the Director role is to like, it's directly in the middle of it all. So it kind of, you understand what the Director role is supposed to be to you, you understand how all the other ones fall in place too.

[00:08:28] So, I asked a simple question of people, "how do you view the director role, and I'll then give you mine", my view of it in most prototypical places. And most of the people will say they think of Director as Manager plus plus, and I have gone to say, "no, I think of director is VP minus minus", and the distinction between the two mindsets will help, I think, talk about it. I'm not saying I'm right. I'm not saying they're wrong. I'm not saying use my way or not. But have a point of view, and then I'll tell you why, I think mine might be more appropriate for most places.

[00:08:57] Eiso: So one of the things that I think you do here, that is often left out of the discussion completely, is you, you call it dynamics and super powers. And I think a lot of the times where we're discussing these roles as an industry, we leave those two things out. And so I'd love to maybe start by, since this is probably the most high-level we can get, I'd love to kind of start by zooming into, you mentioned, you know, dynamics and is the co-founder still a CTO, can you dive a little bit deeper into that and what you mean by dynamics? And is it only related to co-founders or dynamics extend beyond just that level?

[00:09:33] Jason: Yeah, I think the dynamics are the subtext to all organizations as they grow, and though people who can navigate those, and this is like a political statement for what it's worth, people who can navigate the dynamics have the best chance of succeeding. But the nonpolitical version of that is you actually have to understand the dynamics to understand how to bring information about the organization too. So a good example is, if you're working at a multi thousand person company and the CTO is a co-founder, very technical, non-organizational though. What kind of information do you bring to the CTO, and make it successful, and how do you package it? And all those things. And don't expect people to adapt to your way of giving information, part of your job, if you're a leader who's basically trying to lubricate the organization and make it work better, is to understand that you likely have to do a lot more adapting than other people will ever adapt to you. So that's part of it.

[00:10:25] So, but the dynamics typically start with the co-founders and it's actually quite common these days, right now in the funding environment 2021, to see a team come together with no CTO, which is interesting because there are people getting seed and possibly A Round Funding with no CTO on staff, which is, interesting. Side note, that's an interesting dynamic, and also one I don't think I would encourage most people to do to increase their chances of success. I'm not saying get funding, you'll get funding. I'm saying increase your chances of success. A CTO is the most important role in early-stage companies. And I'm not going to even say the CEO is, I will not say that. The CTO is the most important person in early-stage companies. And the reason why I think that to be the case is that they're the ones that are making the most 10-year-bet decisions. If you're unwinding a decision 10 years from now, it's coming from the CTO in the early stage. And I know this as well as anybody, having unwound 10-year-old decisions on architectures. So, yeah, that's a little bit of scar tissue in that comment too.

[00:11:26] Eiso: No, but it's, it's it's I think a very, very common, this shouldn't be under valued. All of us in an early stage company get to, so there's the, you've probably heard of the Eisenhower Matrix of decision-making, which this notion of like, "Hey, are decisions easily reversible or not. And how impactful are they in the company?"I think we might have even discussed this in one of our earlier episodes. And, and you're right that the CTO is one of the only people at the top of the organization who is making decisions that really are almost impossible to reverse later on, or at least take a lot of blood, sweat, and tears, and I'm pretty sure people listening to this have countless horror stories of, of unwinding those decisions.

[00:12:03] You, said something just now, Jason, before, which was going from, you said, "you know, a CTO co-founder who might be very technical, but non-organizational", which seems to map a little bit to this notion of organizational superpowers you're talking about, but also individual superpowers that you're talking about. Can we kind of go a little bit deeper into that?

[00:12:24] Jason: Sure. I actually think the most common pattern I see in early stage companies that do have CTOs. And to clarify on that CTO comment before, too, this is kind of like a one A one B, but I want people to think that CTO's are incredibly important in the early days because of those non-reversible decisions are the hard to reverse. But then this goes to the next part of this comment too. In the startups that do have CTOs or bring in CTOs, they tend to bring in very technical CTOs, which I think is the right way to go in the early stage because they're producing code. They're either directly, which I do believe they should in the early days produce code or they're what I would call the spiritual leader of the architecture. And they're watching the, the architecture, they're reviewing all the PRs they're, they're waiting for that spidey sense with hair on the back of the neck thing, "I don't think that's the way that we should put this together for these reasons, let's talk about it.".

[00:13:10] But those people, not to generalize, but then to generalize in my very next breath, there's a reason why they get up in the morning and they tend not, it tends not to be about HR ladders or review processes or, you know, performance expectation meetings and things of that nature. And a lot of CTOs grow into that. A lot of founding, very technical CTOs do grow into that and they want to go do it, and as part of, you know, that's a 40% part of their job that maybe they don't love, but they are they're, okay at, to get to the other side. But there's some that just don't and they don't want to do that. And you have to be honest with yourself as the CTO in that situation, but also the CEO in that situation, because over time the CTO's importance can either lessen, or it could actually become a detriment if they don't have some of those skills developed as well. And this is also a difficult conversation for some folks to have with their founding CTO as well, which is, "Hey, the organization actually needs something different out of you right now. And it's not about what you have to provide, it just needs something different out of you. It needs you to be more of a spiritual leader or an inspirational leader, or we need you to organize the engineering team more and have those discussions." And that maybe something they don't want to do.

[00:14:21] Eiso: So I've seen this time and time again, and often the solution that a lot of companies jump to is "let's hire a VP of Engineering, and make them the, the owner of call it "the people side of things". And then there's lots of different variations of even how reporting lines will look there, right? Does the VP of Engineering go directly to CEO to the CTO, if you have a deeply architectural-minded CTO, should they actually be managing the VP of engineering? What does the state of the world look like today? And what do you think in your opinion will be optimal if we could get to?

[00:14:54] Jason: This is "no good answer" territory that I'm going to get into. It will be unsatisfying, so I'd like to preempt that part of this. I think it's tough because if you're an incredibly good VP of Engineering, you want to report to the CEO, because you'll want to hear the exec staff meeting, and maybe what they will do in that case is then while you're the VP that reports to the CTO who is also in exec, which is kind of like that sidecar during that conversation. But the VPE, if you're very good at what you do and you've got experience, you want to report to the CEO and it's not an ego thing. It was sometimes it's an ego thing for some folks. But a lot of times it's because they actually need access to the entire E staff, they need access to that information to get that stuff done. And the anytime information gets filtered, it's filtered via somebody else's lens, so if it's being filtered through a hyper-technical CTO, it's actually the wrong information a lot of times for the VP of engineering.

[00:15:55] So they have to go around the CTO sometimes to get that same information anyway. Which is also, again, this is the difference in thinking, you know, a CTO, what they might care about on a day in day out basis is different to what the CEO cares about. And what the VP needs to do the job. So that's one thing I thing. VPs reporting to CTOs is a cleaner line, for what it's worth, it's it just makes the organization a lot more apparent. And especially when you have multiple VPs of Es. If you have VP, if you have a VP of Application Engineering, VP of Infrastructure Engineering, VP of Security, VP of whatever, all reporting to the CTO, it just makes sense. And then what happens is somebody somewhere says, "Well, the CTO can't handle all four or five of those VPs either. So now what we're going to do is we're gonna hire one SVP of Engineering and that person will, oh, wait, we've got to have the conversations. That person reports to the CEO or the CTO." It's the same, same thing all over again.

[00:16:45] Eiso: And so to take a step back for people, and try to define the different types of CTO and the different types of VP of Engineering. How would you kind of, you know, give us the bullet point rundown of, you know, maybe the, the architectural CTO, I think right now you're what you're discussing about was the global CTO, the one that will take organization, and so architecture and what are kind of the different types that we see on each of these top level profiles?

[00:17:14] Jason: Yeah. So I think that there's obviously there's a spectrum and there's going to be more than I can enumerate in reality, but I'll kind of bucket end two ends of the spectrum, which are the "do it all CTO" on one side, versus the "hyper-technical CTO" on the other. And then somewhere in between, I'll add two more maybe.

[00:17:34] Let's start at the hyper-technical, which is the most obvious one. They look at the architecture, they look at the edges, they look at all of the different systems in place and they think about that. And then they think about the next year, they'll think about scale, they'll think about programmability or fault tolerance or all, all those different things you would think about and they'll have deep conversations about that. They probably care a little bit, I mean, not a ton about internal engineering efficiency, but what I mean is not like what Athenian is doing, it's more like, "Is the build process fast enough to a degree or, you know, what are the subsystems look like there? Do we need to invent a new thing? Do we need to, you know, how what's abuse looking like on insecurity? Should we go, you know, build up an ML team that kind of handles abuse" type of stuff. But, it's probably leaning into a lot of their strengths and if their strengths were founding CTO, it's probably the application architecture or the database architecture right out of the gate too, depending what their backend systems look like.

[00:18:29] And then the other end of the spectrum, you would have more of a, "do it all" kind of generalist CTO. And they would grow into some of the things that they didn't have to do early, or they maybe had those as latent hidden superpowers from previous roles. And they're good at organizing people, and they're good at thinking about the human side of the system, and in reality, that's what we're talking about is we're talking about two very complex distributed systems. We're talking about the architecture, and we're talking about the organization and they are literally two sides of the same coin because the architecture is beholden to the people who produce it and the people who produce it are beholden by what they can get done in said architecture.

[00:19:06] And so if you look at it that way, a well-rounded technology organization is able to think and rationalize about both of them at the same time, which is also why a CTO that is able to dive into the architecture and talk about, a very technical CTO who also has the human side and the organization side are basically unicorns in the industry. Because they're both very complex and the dynamics work very different.

[00:19:32] Eiso: So I really liked the way that you put this, because like you said, it, it is a unicorn in our industry, but actually we're, we're looking at two complex systems and more often than not, we find people's passions, I wouldn't even say skills, but people's passions swinging to one or the other, and then rarely actually being on both.

[00:19:50] So to go from the CTO to the VP of engineering, VP of engineering often feels to be the role that people put on execution, you know like, "Here now you have to go get it done." How do you look at that? And what does kind of, what does the spectrum look like for a VP of Engineering, which might look very different than the spectrum for a CTO?

[00:20:11] Jason: Yeah, the VP of Engineering is, I think classified, I saw somewhere it's like the "three Ps", the People, Process, and product kind of like, "You need to build the product via the people through the processes you've put in place." And that's not wrong, it's not even that, I would never say it's wrong, it's actually pretty close to correct, I think, the way the industry thinks about this, and for lack of better definitions is a good one to run with because you can get along way with that definition. I do think the idea of "When to hire a VPE?" typically comes in with the exact same point in time in the organization as "when do we need engineering ladders? When do we need one-on-ones? When do we need performance reviews?" It's like all starting, you're starting to have conversations that look like that. And then someone says, "maybe we should bring in a VPE to handle all those things."

[00:21:01] If I were to look at VPEs, what I would say, for the most part, is you want to think about your earliest VPEs as execution machines. You do want to think about them as, "Hey, we're going to come in, we're going to execute. We're going to make sure some of the basics are getting done in some cases." As you scale and grow with the other end of the spectrum, you're several thousand people, the VPEs have to look quite different, because if you've got 5, 6, 7 directors reporting to you or senior directors and they've got managers and all that, you are a communication machine at that point, that's what you're doing is you're, you're over communicating all of the contexts and the expectations and the deliverables and the why's and all of the various things. And so you're, you're trying to do an outbound information flow to an inbound feedback loop in that cycle, and then you're just trying to tighten that cycle each time. And, you know, you're finding ways to tighten it. And that's why processing people on the product all come into play too. But in my head, it's just this big old loop and the job of the VPE is to tighten the loop as much as they possibly can.

[00:22:05] Eiso: And so, we touched upon the exec team a couple of times, and one of the things that really stuck with me from a previous episode that I've since actually shared with quite a few engineering leaders, and it was like light bulb moments for them, was like, "Hey, how often do you meet with people outside of your function?" Right, outside of engineering. So how do you look at that for the CTO and VP of Engineering and is it different for both of them? And is it different if they're in the exec team or if they're not in the exec team?

[00:22:30] Jason: Oh, let's talk about what I see in the wild first, and then what I would ideally like to see too.

[00:22:35] I think in the wild, what would happen is a lot of the frustration starts to happen as organizations grow because the CTO is not having those conversations. And a lot of the organizations are feeling that they're not being heard, or they're translated incorrectly, or I don't know something along those lines. But it's not because they don't wish to it's just because they're underwater themselves and they probably feel they need to focus on what their core job is. On the inverse side, the VPE should be doing that quite regularly. That's one of the core functions of the job. And that also might be a frustration where the organization starts thinking about bringing in a VPE. I don't think it matters for VPs of Engineering or VPs in general, about where they report, they should be having those conversations. And if they don't feel comfortable going to the CRO, because the CRO and the CTO "are peers", well, one, they should not be uncomfortable, they should just ask like, "Hey, what cadence should we get together on? And like, you know, I think we should sync on some quarterly basis for 20 minutes." But they should be talking to the Sales organization, and it doesn't need to be the equivalent. It doesn't need to be the "Geo VPs" doesn't need to be world-wide or EMEA or APAC. They could go find the solutions group. They can find, what they should be looking for, in my opinion, is the groups that cut across sales, because the way that sales works, just like engineering, is you've got like verticals and you've got horizontals. Go find the horizontals because that's where you're going to get the most information anyway. And have really good relationships there. Same thing with support. VPs should be talking to support on a regular basis because support sees some of the gnarliest things that are coming in, but also they see the meta patterns of like "our customers hate this part of our product," and "oh, that's information that's really good to have. Okay, good," or, "this is a very friction full part of our product," and maybe the lost password flow is just atrocious. And we've seen it before, but you get the idea.

[00:24:25] Eiso: Yeah. And so I want to go even more granular, because I know that we're going to have some people listening to this and saying, "okay, that's great at a strategic definition of the role, but you know, what does the day-to-day look like for a CTO?" and maybe do the same for VP of Engineering before we get to other roles, at different stages. Because I know quite a few people who are, you know, they're are directors today, or they are thinking about being a VP of Engineering at an early stage company. And I spoke to an engineering earlier this week, and he told me, he was like, "Eiso I showed up day one being promoted from director to VP of Engineering, and I sat there and I had no idea what I needed to do. I was responsible for about 400 engineers at this point, and I had no idea what I needed to do. Because all of a sudden directors were managing the senior engineering managers and now I'm, as VP of engineering and I actually didn't know what my role had to be like." So could we actually dive into that very granularly, and what does the day or week look like of a VPE and a CTO?

[00:25:24] Jason: Yeah. So this is obviously going to be incredibly different based on stage. So let's randomly pick a stage and maybe talk that one through. You have a preference on stage for this?

[00:25:37] Eiso: Let's take, I mean, you're a growth investor now, and so let's take early growth. Let's take, you know, a series B company. It probably is at, you know, 40, 50 engineers and it's expecting to double in size in the next 12 months.

[00:25:53] Jason: So perfect, because there's a lot of things at play there, that obviously would change the way your day-to-day looks like. So we'll assume a couple of things. We'll assume that the VP and the CTO were in seed, we'll assume that the VP, it doesn't really matter for the purpose of this of course, the CEO or CTO, 40-50 engineers you said its going to double in size. All right. So when you think about all those, what you just said laid out, there's a bunch of things that you would obviously probably need to put into your head. Here's how I would approach both of those functions.

[00:26:24] They start at the same question. What's the riskiest part of this going to be over the next 18 months? And the CTO's answer to that is "we're running ahead, database scaling, we're gonna onboard a hundred new, a hundred thousand customers or a million new users." And they're going to start thinking about those systems and where they're going to break down and fail. They're gonna start prioritizing those sets of things in conversations with staff eng. or infrastructure or those things. And they're also gonna think, "Hey, we're gonna onboard all these new people at some point, likely like our internal systems might break too." And this is also where the VP starts thinking about it. Like, "Hey, we're going to onboard a hundred new people. Our internal systems are going to break and we're not structured in a way to pull these people in. What's our onboarding look like? Do we have enough managers? Are our managers capable of managing that many more people? Are our directors capable of managing two new managers per director, do we have the information flow? Oh no, we don't have the information flow because I'm still a bottleneck or the CTO is still a bottleneck or the CEO is still a bottleneck and we don't have a planning process at the corporate level to set the prioritization appropriately. Ok prioritization is a real big problem." So, all that to say, that's how I would start to think about those. One's the human organizational side, one's the CTO side, but you can see they kind of meet in the middle of somewhere where people are involved.

[00:27:41] Then if I'm the VP, let's go back to the VP here. You start to unpack those things. You start to prioritize them. And you say, "I need to start having a conversation with the CFO and the CEO about corporate fiscal planning." And then it usually comes in around B stage, like you're gonna start thinking about the year, and you're going to start thinking about quarters as how you're going to plan. Somebody somewhere in here says, OKRs, all that sort of stuff, type of deal. We don't, we can have an OKR discussion at some point too.

[00:28:07] But you get the idea, you're starting to organize the company. It's starting to feel more like a machine at that point, or at least the VP is trying to make it feel more like a machine. Because they have a need, they can't be the one that has to go amalgamate all this information from everybody and then try to distill it and push it out to their folks. Because that is not a scalable approach. And they're about to hit a spot where they won't know an engineer's name once they get hired anymore. So that's a lot of how they're going to spend their day.

[00:28:35] So they probably wake up on a Monday, they do they're E or their Exec Staff one-on-ones in the morning, start doing their team level one-on-ones in the afternoon and Tuesday morning, at least this is how I structured a lot of things in my head. They probably start looking at dashboards. "How are we doing? How are we really saying what's uptime look like, where do we need to spend some time? Where there's risks." They start looking at hiring pipeline. "How long does it take us to close an engineer? How many open roles do we have? Which managers have the most open roles?" You also start asking questions around this stage as well. "Do we have talent partners or engineering managers hiring exclusively still at this point?" Which changes the dynamic as well because if engineering managers are hiring that's a portion of their week where they don't have the ability to go manage other things. Also, you have inconsistency at that point too. Some hiring managers or directors are much better at hiring than others, and you've proved out over time. So you have to start analyzing that sort of stuff too and looking at it. And then you start to realize at some point too, like "I don't actually have a good handle on the most strategic priorities and projects." and you start putting something into a spreadsheet, or you start tapping somebody next to you to say, "Hey, I need to get this information organized. You as a director or manager. I need you to organize this for me. Oh, now you're going to start coming to meetings with me now." This is usually the start of like a Program Manager or Project Manager, or possibly an Operations or Chief of Staff for that person at that point. I would not recommend Chief of Staffs, by the way, until much later, it's just, it's very difficult and all that. But Program or Project Manager is something that's appropriate around that stage.

[00:30:07] CTO is not thinking about any of those things. They're waking up in the morning on a Monday, and yes, they'll probably look at like some strategic dashboard somewhere because they're a co-founder, but they might even skip that and assume the CEO is doing it. And they're just looking at architectures and big strategic projects. Maybe one pet project of theirs is really critical, or they really want to redo the queuing system or something like that, and they're thinking about that on a regular basis. In fact, at this stage, a lot of the CTOs look a lot more like distinguished engineers. And the reason why is because they're handing off the organizational side to the VPs.

[00:30:42] Eiso: So you mentioned something at the very beginning, that I thought was very interesting to kind of try to think this through to the different stages of companies that, you know, at this stage, you know, growth hiring, etc., both the CTO and VP of engineering needs to be asking themselves, "what's the riskiest thing that is going to break either organizationally or architecturally?" When does that transition, in the core question that a VP and a CTO needs to ask happen? Right, in the very early stage of company, it shouldn't be on someone's mind, like "what's the riskiest thing", because it's still about getting to product-market-fit and then you start getting to that, you know, that scaling part. How do you look, if you take, what's the riskiest as kind of the series B question. What's the questions earlier on, and as companies grow and mature, does it still stay the number one question, you know, what's the riskiest part of this complex system?

[00:31:32] Jason: Yeah, I'll back up for a second and talk about in traditional VC terms, like Seed ABC what I think about as each stage too, and obviously again, spectrums, and not everything fits and it's 2021 and people are taking B rounds with no CTO in place and no code still. So it's a little strange, but give me, give me some leeway here.

[00:31:52] So traditionally, what I think about is seed rounds, are some validating routes like, "Hey, should this even exist in the world? Let's take some money to experiment to see if this thing should exist in the world." And what we were actually trying to do is just talk to people, get some validation, get some sort of proxy measure for "people want this." Maybe Seed extension or A is, "will they adopt and maybe slightly convert to pay, like, will they adopt it? Will they quasi give us money either soft commit or commit". But you're not actually optimizing for money yet. You're optimizing still for adoption. So somewhere between Seed and A, or in A, you should be hitting some sort of product-market-fit measure or a quasi-loose definition of product-market-fit. And my definition for what it's worth is just that "people have started to adopt you via themselves, and they see this as a problem that they want to go solve, whether or not they're willing to pay for that is yet to be determined, but that's a little bit of how I look at it.

[00:32:50] The B stage is about, "all right, we've got the fit, we've got adoption, how can we get people to convert to paid?" We've got to build that machine over there to convert that over to a paid mechanism, a monetization strategy. And then you basically largely got the execution machine and thestart of a go to market machine put together.

[00:33:09] And then the C round traditionally would be, "hey, we know how to do all that sort of stuff. We've got the sales team in place, a very small one," but you understand the bottom-up to the tops-down motion. "We've got the conversions kind of in place," and because of what I mentioned before about sales too being a little bit more of a pretty predictable machine, we're like, "we just need to raise this much money to pour it on the sales team to go buy the customer acquisition, essentially. Sales and Marketing and all that sort of stuff, which is also why traditional late stage growth investors are all spreadsheet jockeys, because it is basically a spreadsheet equation at that point, if it's working, they know exactly how to buy customers.

[00:33:45] With that said, you know, going back like, in the seed round its inappropriate to really think about the 10-year risk problem that I even mentioned earlier, except that the CTO should say, "we don't want to do it that way, because if we are successful and do this, the trade-off of doing it this way versus this way is very minor and we should do it this way for future optionality." it's just like a small thing, let's just like not box ourselves in. That's like it, but they shouldn't be prematurely optimizing by certain Kubernetes and Kafka and blah, blah, blah, into the mix at that seed stage. Like quite literally, heroku plus Github plus Rails model lift is a great seed stage approach to all of these sorts of things.

[00:34:23] Eiso: I wish more people were taking that advice because I think we see more seed stage companies today with Kubernetes clusters and microservices and crazy architectures then probably should be the case.

[00:34:34] Jason: Yes. And in fact it increases their risk and it lowers their chance of success because it increases their burn and all that sort of stuff. So don't look at it as a technology problem. Look it as a company problem. Which is like, you're actually spending too much on this and you're decreasing your chances of success. Maybe that's a better way for people to rationalize this one. In the A stage, you're still largely still on a monolith doing that same sort of thing. You might hit the stressor. You might hit at point if you're mega successful of moving off of Heroku, starting right around here, but you're largely still thinking about the same thing. If you have a VP and a CTO in A stage, they're different things. Like the VP might start thinking about the fact that they don't have the right teams in place, and it's not risk anymore. It's optimization still. It's like, "Hey, how do we get better? How do you faster? Or how do we get whatever?" And the CTO is, "All right, so now its time to go pull off this chunk and go build this thing." So again, not de-risking is still like playing offense a little bit in both of those scenarios.

[00:35:29] Now, at some point in the spectrum B-ish stage, you start to play ofense and defense. Which is, "We will go build this and we will understand where this will break. We will go build this and we will understand where the organization falls apart. We go build this, and we'll understand that we don't have the right mix of junior, senior, and staff level people to go to go make this thing optimal." And you have to be able to balance those two things.

[00:35:52] So, and then at some point like you're Microsoft and you are 100% playing defense. Like your entire organization is built around everyone averaging out to. The meaning or something like that and saying like, that is what we are right now, we just need to understand our organization.

[00:36:06] Eiso: So I think you introduced a couple of very interesting mental models here. Right? First I kind of see it like a bell curve of defence, you know, very, very little defense in the beginning. And then you get to a point, sorry, offense. But essentially this spectrum of a curve of, you know, high offense in the beginning becoming more defensive over time until you almost have to be entirely defensive. And then I think the second thing that you introduced here that I found really interesting is this notion of there's a point of where we go from, "Hey, let's just care entirely about making something useful, to let's start optimizing the machine. So let's start thinking about what's the risky things that can break." And then to the point of maturity, where it's no longer thinking about, you know, the riskiest things that can break, its purely of, "Hey, keep the machine oiled and running well and, and able to scale."

[00:36:53] We have various personality types. And I see you already laughing. You see where I'm heading towards that, you know, will, will fit very well at the different spectrums of roles that we've defined at different stages. Let me maybe start by throwing a bit of a curve ball. How often do you see people able to go through this? From the beginning all the way towards, let's call it a, by old definition "a successful growing business". Maybe it's IPO maybe it's an, it's not Microsoft, but right something that where like "this business is not going away anymore tomorrow."

[00:37:29] Jason: I would say that the most common place that that works is the CEO. CEOs tend to be able to make the transition more. And I think there's a lot of social reasons for that, which is, including that they get the most leeway as founder CEOs. They also get the most support from traditional Silicon Valley. CTOs struggle to make the transition typically because they're super, interestingly on that curve, at some point, their super power actually is like, "Hey, we know what we can't do that. Anymore. We can't do that, well, not anymore, we can't do that right now." So then they're left kind of like wandering in the wilderness for a year or two or three until there comes a point when a lot of their super power gets unleashed again.

[00:38:10] So imagine that you're the founding CTO and you produce 60% of the code because there's three of you and that was your job for some period of time, then you go from producing that much code to kind of being oversight on the code, looking at the PRs and producing only 10% of the code and then 1% and whatever. And then you keep growing and, yes, you're at A and B stage, you're saying, "no, we can't do that because this part of the system will break and we can do that. And like, I'll go work with that team real quickly to get this up to speed," and all that sort of stuff. Then you hit a stage where it fits, it's working, and you're selling, but it's all about like small touches or enterprise features or role-based access controls or a SOC2 compliance or HIPAA or FedRAMP and all the different compliance regimes and security and all those sorts of things, then they say, "no, no, we're not going to mess with this for like 18 months," three years up to a point if you're, you know, then also the CTO is like, "wait a second, I'm not trained for this stage anymore." But if you make it through that, and you're successful. And if you've gotten to the point where people are saying those sorts of things, you have a high degree, a high likelihood that you're going to have some outcome that's successful.

[00:39:17] You get to the other side of that. You're probably a persistent company. Then actually the CTOs powers get unleashed again, because you're thinking about product line expansion, where you're thinking about going into new markets, and then they can start thinking about the way the core architecture could change, or they could add new things in and layer and all that sort of stuff. And it gets unlocked again. But there's this moment in the middle where like, "I don't know what to do." And how the organization handles that transition with them will be whether or not they stick around or not.

[00:39:43] Eiso: So I'm really glad you mentioned this because I've never heard anybody so clearly articulate the moment in the middle for CTOs. I hope the people who are listening to this and might find themselves in the moment in the middle is the words of encouragement, like, "Hey, if you stick through that moment in the middle, that's when it gets interesting." Again, you don't necessarily have to leave and be the co-founder CTO that decides to now leave the business, and if someone else become a CTO or transition to another company where you might get to skip that step. And I think that centers around the fact that you, you start it with as the support system and the leeway really isn't there as much for the CTO or even close to it as it is for the CEO. Right. As CEO, you get cut a lot of slack, and we've seen a lot of famous examples of this over the years. What should we, I think the "why" we've covered quite a bit, and the "why" is just a blurb of shame on our industry that we should definitely fix. It's just that, like, I think,you know, otherwise we keep coming back to it.

[00:40:38] But if we take, having people who are listening to this who agree with the "why" on us, which is, you know, the CTO, I liked the way you phrased it, a couple episodes "is where the rubber meets the road." What could we be, or should we be doing to help CTOs really from the earlier days to these later stages, have that same support network and have that same amount of leeway? And I'm starting to think that part of the reason why the CTO might be often the person that gets kicked out or put in the corner, like "you're still a CTO, but now you're, you know, on pet projects, "field CTO"

[00:41:13] Jason: Yeah, field CTO is a really good place for people to dump them off on..

[00:41:16] Eiso: Exactly. Right. Or like "you can work on your pet projects and here you have two engineers and like, this is, you know, your corner now, which is, often because it's like the way for the exec team, and even often I think sometimes the CTO to pass on the blame of," Hey, we're not moving fast enough. Now, if we just get someone else, we can move faster. We don't have these issues. You know, our databases aren't scaling. Well, it must be the CTO's problem. It's not the problem of the decision that was made seven years ago, that we're now facing." So, how do you frame your, what do you frame if you know, you're running a company, Jason, and hopefully one day you you'll go from investor to being a CEO somewhere, what would you be doing to, to avoid this from happening and what would you be providing the CTO?

[00:41:56] Jason: So I think I really do believe it's as simple as, it all starts with awareness and acknowledgement. And this view is born out of my own personal frustration with the industry, which someone asked me the other day, as we're going into like hour, three, a long discussion about the organization. It's like, "where did you pick up all this? Who are your mentors and books and blah, blah, blah." And for the most part, I'd never really had that. And this is my own personal frustration is just born out of the fact, that didn't really exist. And I think that, the fact that there's very few technical investors, is another one, you know, there's technical investors, you know what I mean by that, but not like that were born out of high-level CTO or CPO roles or that nature.

[00:42:38] So they don't fully understand it themselves. And it's not, it's more common these days to have a technical CEO, a former Eng CEO, which is a good change, I think, but it was less common five years ago, even. So I think it's just acknowledge it first, and awareness. And I think second its being really explicit about what the company needs in the moment and how they can support that and what it would mean for them not to be in the spotlight or whatever it would be, or the let's call it maybe "in the frame in the moment."

[00:43:16] And so, you know, if you're an early stage company, it's pretty obvious what the CTO is doing. If you're that B stage company, you start to be ambiguous. They can feel uneasy. And I think it's them, the CTOs acknowledging that they feel a little uneasy. So, but don't try to change the organization to make them feel more comfortable. That's not what you should do because then you're mucking with the soup, just because you didn't like the taste of it, but you're also feeding a hundred other people who love the taste of that soup right now, for whatever reason. And its being open with the founding, the CEO and others. But if the CTO feels that if they say this to the CEO or the board, they're going to get booted or moved out or something, because it's actually quite common to move founding CTOs out of role. They're, they're never going to do that.

[00:43:57] So you've got to make it possible. And this starts again with the CEO, that, that feels very comfortable to have that conversation. Because there are some really great companies today where if you said, "Hey, who was the founding CTO?" Half the time, you have no idea. And sometimes that person might even still be at the company, but they're not in a prominent leadership position, but they're still there and they're still providing value. And that person, if you ask them was actually quite happy. Because the company's doing well, they're, they're finding their own value in the company and their own kind of self-actualization in what they're doing. And so you want to understand how they got that point.

[00:44:32] Eiso: But I think the interesting part, is that what I'm noticing from what you're saying is where, even when we have that founding CTO sitting somewhere in the company where they're actually quite happy, it's kind of like taking somebody who was, you know me, I'm not one for the best sport metaphors, but at somebody who was, you know, playing in the B league, did great there at a company, graduated to A league, and instead of giving them, pushing them almost, and saying like, "Hey, its normal that there's this awkward transition from one to the other. And there's this time, this kind of, you know, window in the middle," like you called it, "stay here, hang out here, you get the full support and then you're going to be an A player." Instead, we're actually saying like, "Hey, let's just, you know, make you happy on the short term or even the long end, let's put you somewhere where you're going to be comfortable." Like, right, we push CEOs out of their comfort zone all the time. Are we pushing CTOs as much out of their comfort zone as we should?

[00:45:24] Jason: No, I don't think we are. And in fact, I think that we should challenge them to a degree too, to say, "part of your personal journey is going to be deciding let's make a first decision on their part to opt in or opt out that something different would be wanted out of you, or you would need to be uncomfortable and develop some skills. And let's go do that. Let's build that. Let's get you ready for the B stage." Start this at the A stage, get them mentors, have them, again, take money from the right investors who can back them as well as they can back the CEOs or the go to market teams. Get them some support structure and start challenging them. So that they're ready for the B stage, maybe they opt out and say, "you know what? That's just not for me either. Let me go look at special projects or field CTO, or when I'm fully vested I'll cycle out." But, you know, making a decision.

[00:46:07] Eiso: So I realize we're saying here, actually it makes me think that, we still have a couple episodes probably to dig further into this topic, but it definitely makes me think that you and I should do an episode one day that will be titled. "This is for the CEO, what you should know about your CTO and what you should know about your engineering leadership".

[00:46:26] Jason: I'll make two last comments here, I think for this episode. One is whenever I get into a discussion, with CTOS, where I'm talking about growing the organization, planning, prioritization, you and I have been having these deep conversations. I say, "this is actually a CEO conversation, but I'm talking to you, so here's what I would do to go talk to the CEO about this topic". And I lay out how to grow a company. And the talk I give, which is called architected teams for scale, all CEOs say, "go talk to my CTO. I would love for you to tell them all this wisdom." And I tell that person, the CEO, "this is actually about you, and it's about the organization, the company," and they don't quite fully understand that.

[00:47:07] And eventually when they do, they realize that the product, for most CEOs, at some point it's the company they need to build the company and that this is that topic. And once they do, they realize that they were actually offloading one of the main things of their entire company, the growing of the company to the CTO and the CTO is again, very, very important. Maybe number two, in that whole thing, because that's where the rubber meets the road. As you mentioned earlier in that conversation. But if the CEO is not on board and not driving a large portion of that. Well, then it falls to the CTO to do it, but almost later than it needs to. And in a, let's be honest, a jankier way, because they're trying to make up for a whole bunch of broken parts of the system and get information and pull it out.

[00:47:48] And the last comment I'll make, like the whole CTO idea, VPE CTO, technical leadership is so poorly understood in our industry. I think that you would, it's amazing to see what kind of decisions will be made. I mean the best example I could, and I'll be very transparent with all the listeners here and you Eiso as well, is that, when I was thinking about leaving Heroku, it was because I was frustrated with the overall mechanism that was Salesforce and Heroku and my personal journey inside there. And I remember saying to my wife at one point and I'll use numbers here, but I said, "if Salesforce just gave me a comparable equity package to what I was supposed to be making on the open market. And this was in 2017 or late 16 or something I'd say "it's just, it's just like half a million dollars over four years. That's all I really want to be getting paid half a million dollars worth of Salesforce stock for four years. I'll stay and I'll do it." And I hadn't gotten a real raise in quite some time.

[00:48:42] Instead I went to GitHub and then, I, you know, the GitHub story is kind of self-evident and obviously worked out much better for me financially, but also for GitHub and probably developers in general. And then I had the exact same conversation inside Microsoft, because they didn't quite understand what technical people are supposed to do inside these organizations, and here I am, now I'm an investor. And I laugh about this because it's just like, well, if somebody at Salesforce made a different decision at some point, well they have Brett Taylor, they got Stewart Butterfield, they got Cal Henderson from Slack, well, those two guys from slack now, they would have had me who was essentially the CTO at GitHub in some part. And then they would have four or five other people that had since left. What would Salesforce have been with the amalgamation of all of those people put together. And it was simply because they didn't understand what technical talent and leadership looked like.

[00:49:30]Eiso: I think that's an excellent place to end today. And it still blows my mind. Like you'd have this conversation so many times, that the simple connection between this is the part of the org that builds actually what you bring to the market, the fact that there's still such a disconnect there, it just seems like it's a deep-rooted, almost historic belief. That's just been there for so long. And that like a company like a Microsoft or even a Salesforce, which are known, particularly Microsoft for their engineering quality, still can't wrap their head around that, is hopefully a state of our industry that we won't see in the future again.

‍