[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.