How Many CTOs?
S2E17 · May 5, 2026 · 47:02

An Ideal Partnership: How and When to Split CTO and VP of Engineering Duties

Listen to the audio 0:00 Cold Open
0:00 47:02
Transcript

In this episode

In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub discuss the recurring question: when it's appropriate to hire a VP of Engineering and how to divide responsibilities so the CTO can better align product, business, and technology strategy. They define CTO vs VP of Engineering work, review Gemini's matrix (strategy/vision vs execution/people/process, external vs internal, success metrics, and typical direct reports), and add nuance about internal stakeholders within and outside the company.

They discuss cases where leaders can't do both jobs and why founders shouldn't give the CTO title too early. They emphasize CTO/VPE as a yin-yang partnership with clear decision rights and KPIs.

Brad shares experiences with split dev/ops teams and argues for engineers having operational skin in the game, while Scott outlines his org functions and defines ops as what's required to keep systems running. They propose carving up responsibilities by strategy vs building (and operating), debate punting corporate IT to the CFO versus keeping it tied to security, and consider using Gemini to suggest how to split roles.

The episode closes on letting go of ego through clear expectations, Scott's recommendation of the book "First, Break All the Rules," how skill or interest gaps can force a split despite hierarchical titles, and a pro tip to align on expectations with your CEO so teams can measure progress and celebrate wins like uptime and cycle-time improvements.

← Back to episode

Transcript: An Ideal Partnership: How and When to Split CTO and VP of Engineering Duties

0:00 Scott I think as organizations grow, one of the risks points is people having an unwillingness to pick because organizations need to have the subdivision of labor in order to grow.

0:27 Brad Everybody to another episode of the How Many CTOs Does It Take podcast. My name is Brad Hefta-Gaub and my trusty co-host is...

0:35 Scott Scott Porad. How are you today, Brad?

0:37 Brad I'm doing great. What is on your mind today, Scott?

0:42 Scott It's not about AI.

0:43 Brad It's not? Are you sure? I bet you will find a way to talk about AI.

0:49 Scott Well, we can talk about AI for just one second. I just had lunch with a friend, a long time friend, who is a small businessman. He owns some stores that sell fitness equipment, treadmills, dumbbells, things like that. Basically has two lines of business. He owns four or five retail stores. in the greater Seattle area and then he sells direct commercial to like you know gyms hotels apartment buildings that have little gyms I have lunch with him he's a friend we just have lunch together and he was telling me about what he's doing with Claude

1:24 Brad That's awesome.

1:25 Scott it's awesome I mean he's like he's just blown away he is he's so blown away by it he's like I mean just whatever he's using it for their bookkeeping he's using it he told me he said i was paying a person a thousand dollars a month to write for to write to research and write four blog posts for me per month i can have claude do that like in three minutes now i had he said i had claude make a content calendar for a whole year and write all the posts for the whole year took me like two hours

1:56 Brad Yep.

1:57 Scott And he's a small businessman. He's like, that's $1,000 a month. That's just money that goes right in his pocket. He was excited about that.

2:02 Brad Totally. Well, there you go. That's our discussion of AI for this episode. What's really on your mind, Scott?

2:08 Scott Okay, here's what's been on my mind lately. I need to give a little bit of context here. The size of the engineering team I'm currently managing is roughly 100, let's just say 125, 150, somewhere in that range. including managers and operations folks, IT is in there. It does not include design. It does not include our data team. So that does not include data engineering, machine learning, data science. That's not part of what I'm managing right now. It doesn't include product management either. So that's the scope. And this is not the biggest team I've managed, but I've managed teams of this size roughly. for the last decade let's say 15 years and that's an interesting number by the way that's done that that's around Dunbar's number

2:57 Brad Yep,

2:57 Scott you know

2:57 Brad right.

2:57 Scott Dunbar's number yeah

2:58 Brad Yep, yep, totally.

2:59 Scott so

3:00 Brad But you want to explain Dunbar number to our 39 listeners?

3:04 Scott the 39 listeners Dunbar's number is a number presented by a professor I think he was English I think his name was Robin Dunbar I'm not 100% sure of that, but you all can ask AI to answer that for you. And he was a professor of maybe psychology or something. And he said, I can't remember if the number was 125 or 150, but it's the number of sort of high quality active social connections a person can maintain at any given time. Right. So when you think about a group at work, like once it gets sort of above that 125, 150 range, it's sort of hard for it to operate as a cohesive unit because those people can't maintain all those social connections with

3:49 Brad Yep.

3:49 Scott the working relationships. And so at multiple points in my career, as I've been at companies that have been growing, the CEO has asked me. Hey, at what point do you think it's appropriate to hire a VP of engineering, somebody to work with you, I guess, as the VP? And I've never had a great answer to that question. And I'll tell you, for me, the biggest thing that's a puzzle to me is what parts of the organization would I have? report to the VP and what parts would I still have to continue to report into me what would our how we divide our responsibilities essentially

4:32 Brad Yeah.

4:33 Scott is another way of saying that and it's you know it's a topic that comes up from time to time and I would just I was I've been thinking about it recently and the reason I've been thinking about it recently As, you know, as a CTO where I have directors reporting to me, so I do the job of CTO and VP of engineering.

4:53 Brad Yep.

4:53 Scott And recently it became clear to me that there's some CTO type work. that isn't getting done well enough or maybe I should say the company deserves could use having it done better specifically some work to weave together our product and business and technology strategies into a sort of a cohesive plan so that those are more tightly aligned and it came clear to me recently like that's something I need to spend more time on but then I got all these other I got the VP of engineering responsibilities

5:24 Brad Yeah.

5:25 Scott and just like just like operating day to day like how

5:27 Brad Yep.

5:27 Scott would I make those things happen that's that's to put it in my mind lately is like maybe it's time to have that conversation in my head again and

5:34 Brad Totally.

5:34 Scott so I'm just wondering what you think about there's so many different ways we could talk about this um

5:38 Brad Yeah. Well,

5:38 Scott yeah

5:39 Brad let me let me suggest how I think we should maybe start talking about it. The first thing you already said a couple of things that are like the CTO part of the job or the VP of engineering part of the job.

5:50 Scott Oh, yeah.

5:51 Brad And so I feel like one way we could start to kind of explore this, and I think this is a. Like this is a very common question you get from, you know, people that are engineers that are moving up in their career and they're trying to figure out like what, you know, when they always ask the question like, oh, if I go into engineering management, what does my job look like, you know? And so I think its first thing is worthwhile is to kind of like, what are the different parts of the job, right? And in some organizations, like you actually said this, in some organizations, they'll actually give this title. title right you said i am the cto and i also do the vp of engineering job like there

6:27 Scott Mm

6:27 Brad was a-hmm. time when i had a actually the first time i was hired as a cto i actually had the title of cto and svp of engineering like they gave me both titles at the same time and that was because like that organization had a handful of vps already and they were like they wanted to very clearly say like brad we're hiring you to do the cto CTO job. And in their minds, that meant certain things. And we're simultaneously hiring you to be the senior vice president in charge of running engineering, right?

6:59 Scott Mm-hmm.

7:00 Brad So I think that's a worthwhile, that's a worthwhile place for us to start. Like, what are the jobs of a CTO versus the jobs of a VP of engineering?

7:11 Scott Well, would you like to hear what Gemini has to say about

7:15 Brad What

7:15 Scott that?

7:16 Brad does Gemini

7:16 Scott Because

7:16 Brad have to I say

7:17 Scott as

7:17 Brad about that?

7:17 Scott you were bringing this, first of all, very astute place to start. So that's great. I'm glad you brought that up because even as I was saying it, I was thinking to myself. to myself what are the differences between these things exactly and then when you were saying we should start there i went and quickly typed it into gemini because that was the thing that i happened to have open at the moment at a glance key differences and let me tell me i should say the prompt too so everyone knows

7:41 Brad Sure.

7:42 Scott where i went what is the difference between a vp of engineering and a cto in a software company okay key differences it made a little matrix for me first row um Primary focus, CTO is strategy, innovation, technology vision, VP of engineering execution, people, process. Main goal, ensuring the tech stacks aligns with the business's future. VP of engineering ensuring the team delivers high quality code on time. External versus internal orientation, CTO is often external facing, VP of engineering is mostly internal facing. Success metric. CTO. Competitive advantage and technical IP. VP of engineering. Velocity, retention,

8:27 Scott system reliability. I wonder why retention, I guess for people.

8:30 Brad The people retention. By the way, how are you feeling about this? How are you feeling about

8:34 Scott Pretty

8:35 Brad the good. speed of this?

8:35 Scott Pretty good so far. With one little tweak I would make, but let's go to the last thing. Direct reports, a CTO, often just the VPE or specialized architect. Context, VP of Engineering is Engineering Managers, Directors, Developers. The only tweak I would make was the internal-external. orientation and not much of a tweak right it describes external facing investors partners customers but i think the one thing i would add there is in the internal stakeholders right

9:06 Brad Yeah.

9:06 Scott that's the that's your first set of external which is external to your engineering team then your next set of external is external to your company is what i would say so i actually think in total that's i mean this says it better than i would have said it but if you just asked me to rattle it off but off my head, I would have said your VP of engineering is responsible for your day-to-day execution. They are the kind of your kernels or your something, you know, and your CTO is more your general. Actually, I'm sorry, the VP of engineering might be more of your general, whereas like your CTO is maybe more of your, the politician, the civilian leadership is,

9:40 Brad Yeah.

9:41 Scott you know, providing the direction. So big up, that's what Gemini has to say. And that is. aligns with my thoughts.

9:47 Brad First of all, I also agree with you. That sounds like a pretty good characterization of what I would sort of say if you're really thinking about what's the difference between the two. And then, of course, when you are a CTO that doesn't have a VP of engineering reporting to you, then essentially you're accountable for all that stuff, right? You're doing both those jobs at the same time.

10:05 Scott And the thing that I told you I felt like I was missing the other day, I shouldn't say missing, but that I wanted to, that I felt like our company needed just a little bit more of was ensuring the tech stack aligns with the business's future.

10:16 Brad Yeah, totally.

10:17 Scott I was like, oh, we need to spend a little more. Something came up and I was like, oh, yeah, we got to spend a little more time on that.

10:22 Brad So now the question that you asked is, how do you know if you're taking on, if you are existing in the role of. full of cto plus vp of engineering like you're doing both those jobs how do you know when you need to hire somebody else to do and split the job into two okay and i think that like fast forward to the end of this conversation i think it's going to basically be look when one person can't do both those jobs for whatever reason then you need two people to do those jobs right like that's

10:51 Scott That's right.

10:52 Brad the answer right now i what i think is interesting is um There might be any number of reasons why one person is not able to or not. You know, not not not efficient at being able to do both those jobs. Right. So I think a very common example of this, by the way, and this is in my in my space, I am almost always working in, you know, startups and those startups want a very common call that I get from executive recruiters. Right. Goes something like, hey, we're looking to hire new CTO to come in. Because our team is ready for a CTO.

11:32 Scott Mm

11:32 Brad And

11:32 Scott -hmm.

11:32 Brad a lot of times that's a leader who maybe is the technical visionary and maybe even a founder, like maybe even a co-founder, right? And they were doing all the stuff. They were building the tech. They had the technology vision. They were in the room with the co-founder so they certainly had to be aligned with the business vision. and the technology stack right so they're doing some very ctoe things and depending on how big the organization is they're they're running the engineering team you know they're doing all that stuff and and and sometimes you get the call and i'm sure you've gotten this call too where the person that maybe is doing the job is able to do the vp of engineering job but is struggling to do the cto job right and and the org needs to move to a place where they have x

12:19 Brad external facing a leader, right?

12:22 Scott It's interesting. I more often get the opposite call, which

12:25 Brad Oh, yeah?

12:26 Scott is, hey, we had a CTO co-founder who brought technical vision, you know, was tightly aligned with the rest of the founding team, had understood intuitively or because they've done the work to know what to build, but now their team's gotten bigger. And it's the VP of engineering skills that that person doesn't bring to the table, like of how to just run the program of engineering,

12:51 Brad Totally, that happens too.

12:52 Scott but they both happen for sure.

12:54 Brad It's interesting because in that scenario that you're talking about, maybe the answer to the when does the CTO hire a VP of engineering, maybe the answer is when the organization needs more VP of engineering structure and they didn't have it. have it before and they got away with not having it before that's

13:09 Scott Yeah,

13:10 Brad when you should bring in the vp of engineering right

13:12 Scott that's yeah.

13:13 Brad a

13:13 Scott Or when the engineering organization maybe needs more vision.

13:18 Brad revision or supervision yeah

13:20 Scott It goes either way. That's what I'm trying to say. Your organization might need one or the other. You might need to bring in a, you might be a person doing both jobs. You might need to bring in a VP of engineering or you maybe are the VP of engineering and you might need to bring. Need to bring in a CTO.

13:35 Brad Yeah.

13:35 Scott Right someone who has that ability to have that vision

13:38 Brad Yeah, exactly. And I think that obviously, and again, this isn't really the question that you asked, but it's worth pausing for a moment and kind of speaking to this. One of the pieces of advice that I have given to founders, like, you know, because I, you know, as a fractional CTO, I often get brought in as like, I'm being brought in by a, you know, a non-technical founder, and maybe they have like a engineer that's been with them from early days and that. and that engineer like maybe even was a co-founder and then they kind of like did or did not give them the CTO title you know and

14:10 Scott Mm

14:10 Brad then

14:10 Scott -hmm.

14:10 Brad when you're when you're bringing in another CTO and the founder already had the CTO title that's going to be a super awkward conversation right and so of course one of the pieces of advice I give to founders if I can get to them before this happens is like don't give away the CTO title early you know because

14:28 Scott Hmm

14:28 Brad because you don't know like if that person that you're giving it to is not going to be able to do that full job or do that once you get big enough that you really need a vp of engineering and your cto needs to be that kind of like real executive mindset leader then you kind of end up having that awkward conversation where the the co-founder gets you know shuffled over into a you know he no longer the cto or she Or she's no longer the CTO and that's an awkward conversation to have.

14:56 Scott That is an awkward conversation to have, and it's interesting to think about from the perspective of these two titles, because they are hierarchical, right? CTO is generally up higher in the hierarchy than VP however they're really almost companions they're more yin and yang like but we structure them as hierarchy

15:18 Brad Well, yeah. And for sure, like, you know, I would say like if you are in the CTO role and you are doing a fine job of being the VP, you're in the CTO plus VP of engineering role and you're you know, there's pressure to have you move into a more CTO like role and you're looking to. looking to hire a VP of engineering you're definitely going to want to make sure that the person that you bring on board is

15:40 Scott Right.

15:40 Brad going to think of it as a real yin and yang partnership right and if you've got that mindset that you're already thinking that way that's going to make it much better right like you you you need to be able to like If you are in the CTO role, you need to be able to know that this VP is really a trusted executor of the job and that there's not tension there.

16:04 Scott They are running the show.

16:05 Brad They're going to run the show and you need them to be able to run the show so that you really can focus on the CTO stuff. And also, I would say. They need you to make sure that you're keeping them in the loop as well, right?

16:22 Scott Mm

16:22 Brad Like, you know, you don't want to get in a situation where like, oh, you get the CTO title and then you go off into an ivory tower and don't actually engage with the VP of engineering. I actually have seen that structure before in an organization where a CTO existed with no direct reports and there was a, you know, senior vice president or VP of engineering. engineering that reported into the ceo and the cto was like a appendage right um

16:50 Scott Mm-hmm, mm

16:50 Brad and you know there are reasons why that might exist you know i can see reasons why that might exist in fact i was at a again the company that i was cto um svp of engineering at uh we had a chief scientist and that chief scientist was in the executive suite with me and

17:07 Scott -hmm.

17:07 Brad that was very much had we we had very much a much a positive interacting relationship but you know he was very much like off in you know vision land and trying to think

17:17 Scott Mm

17:17 Brad up you

17:17 Scott -hmm.

17:17 Brad know stuff you know that but ultimately it would only get built if you know the engineering org built it once he envisioned it right so so that's a great another kind of one of those weird configurations that's like semi-hierarchical but semi-peer related where like real good synergy matters or else the whole thing falls apart but

17:38 Scott Mm hmm.

17:39 Brad we kind of digressed so we if the if the answer if the end answer is like when one person can't do both jobs that's when you need two people

17:48 Scott Yeah, we got we got to the end real fast, actually.

17:52 Brad but but no but there's different but but i think there's i think the reason that like i'm just sort of saying like that's the end but i think there are a lot of different configurations that cause the oh we need more we need more than one person to do this

18:07 Scott yeah that's right well and then i think there's also like if you're going to insert it so how do i i should i should express a little bit of how i think about my organization and then not not just to task her but elsewhere there is i think there's software engineering those are all the that's the bulk of your team those are people who are um you know developing well okay context take a step back i've always worked on the internet so i'm doing internet applications basically websites and mobile apps i've mostly worked in consumer in my career and a little bit of business to business type of stuff mostly consumers that's the context that i Okay. So you got your software engineering. That's your people building your apps, right? You've got, what else is there? You've got information security.

18:53 Scott You've got IT. Those are the folks keeping your workforce work going, right? You've got some operational type people, you know, doing your cloud infrastructure, making it so you can have a DevOps-like environment, things like that. And then you've got... And usually these are not separate roles, but I like to have somebody, well, somebody has to be a point person for these things. And I enjoy using it as an opportunity to help my directors grow. You need to be somebody, be the point person for your sort of people operations, meaning your review processes, your professional development plans, the last of who's going to drive those processes. Often, well, yeah, often you've got a director, at least I've had a director who likes that. it's that kind of stuff and so it's like cool yeah you can run with that and then you got um like your engineering finance partnership like you got all these bills and you got you know budgets to plan and stuff like that and somebody needs to keep on top of that i tend to find that couples well sort of with the cloud infrastructure i.t type of people because they tend to be spending a lot of the most money so they're they're closest to it

19:59 Scott one has to have that manage that relationship with your finance team as

20:03 Brad Yeah.

20:03 Scott well and so those are kind of like the five or six pieces i think about well i'm sorry and then you've got your architecture function i forgot that one which is what is our what's the what's the vision for our system what i lost my train of thought i was just trying to say like

20:17 Brad How

20:18 Scott how

20:18 Brad do you define?

20:18 Scott do you carve up the pie

20:19 Brad Yeah, how do you carve out the pie? Well, yeah, so I love it that you kind of like described a bunch of the components of like that. like that are often like job functions underneath the cto and i think that that's a good way to look at like how do you carve up the pie uh let me let me start by saying the first thing that i've always done if i have a cto is is uh convince the cfo to take over corporate it because it's not really an engineering function and it's like it's like an operations function and it like so i i i personally hate on notice headhunters like if you If you ask me to be your CTO, I'm going to like try not to be in charge of corp IT because I think it just it 100% distracts from both the two other functions that Gemini told you the most important thing for a CTO and VP of engineering to do, like, you know, people's email access and people's like, you know, logins to the, you know, or their computers back when we used to, you know, or their desks and stuff like that, like, oh my God, like that's so not useful.

21:18 Brad For strategy.

21:19 Scott Can I get a little detour on that for a second?

21:20 Brad Yeah.

21:21 Scott I have worked in companies where it's been part of finance. I've also worked in companies where it's been part of HR as

21:27 Brad Yeah.

21:28 Scott related people. But the one reason I would kind of like having it. is because I like I both like and really value information security and it is a core

21:39 Brad Fair

21:39 Scott part

21:39 Brad enough.

21:39 Scott it's a core part of information security so

21:42 Brad Fair enough. I agree. I will argue that point. And I'll just say like.

21:46 Scott I guess what I'm really just saying is I'm a little bit of a control freak about the information security part because I get at the end of the day I get you know that those are the things honestly of all this stuff we do information secure there's a lot of things that keep me up at night i worry about projects being late i worry about bugs i worry about all sorts of things about people and developing people and i worry a lot about ai but man what really keeps me up at night is freaking worrying about security breaches

22:11 Brad Fair enough. Fair enough. I appreciate that. That being said, it is an interesting way for us to explore that. So if we look at all the job functions under CTO, you enumerate things like I

22:20 Scott you punt it

22:21 Brad punt IT. But if I'm not. If I'm not going to punt it, what category is it? And so here's the thing, right? Like if we look at your Gemini answer, right, it basically divided CTO and VP of engineering into sort of strategy things and building things.

22:40 Scott Yep.

22:40 Brad Deciding what to build and building it.

22:43 Scott Yeah.

22:43 Brad Is that a fair dichotomy?

22:45 Scott Yeah. And the one thing it doesn't really include is operating things.

22:50 Brad Great. Good call out. And if you have a – so I think that those are the pillars under which you decide what job functions are more like deciding what to build. more like building things and more like operating the things that are built so

23:09 Scott Mm-hmm.

23:09 Brad one one really straightforward configuration would be for you to for the cto who is essentially like bringing in extra help is to say to yourself okay well if the building things because traditionally the building things is the thing that's most easily hireable and definable as the job description description of the VP of engineering right

23:30 Scott Mm

23:30 Brad that's

23:30 Scott -hmm,

23:31 Brad that's like sweetly that's in that sweet spot like really clearly in that sweet spot right but architects staff engineers principal engineers those might be in the deciding what to build they're they're much they're a little they're kind of in the building things but they tend to be structured in a way that like they are resources for the strategy

23:49 Scott mm-hmm, mm-hmm.

23:51 Brad Right. So

23:51 Scott Yeah.

23:52 Brad that's like immediately out of the gate. And again, I'm not this is not the this is not the always answer, but I think this is a framework by which you can kind of go, OK, how do I divide up these pieces? Right. And for things that are not squarely in the strategy or squarely in the building, and let's talk about operating in a second, but like for things that are not as squarely in that, like, for example, if you said, well, I've got a you know, I've got a big enough organization that I actually have this kind of like. of like engineering HR function you know like when we talked to Ted remember the interview we did with Ted Newhart back in the our first season where he talked so much about like hiring and you know level ladders and it was like you know he had a clear responsibility that was very much about culture in the engineering organization and building the engineering organization to me that's much more in the strategy component

24:42 Brad of

24:42 Scott Mm-hmm.

24:42 Brad the is under the strategy pillar than it is under the build stuff pillar right so that's an example of the type of thing where you can go okay yeah i'll if i'm the cto and i'm hiring a vp of engineering like here's the stuff i'm gonna let the engine the vp of engineering really focus on and the stuff that's gonna distract them from that is the stuff that i will keep you know as long as it's not going to distract me from the strategy The strategy,

25:09 Scott Mm

25:09 Brad if it's more likely to distract, you know, her or him from the executing of the getting it built, then I would rather keep it out of their hair so they can really keep they can really focus on on the building

25:22 Scott -hmm.

25:22 Brad of things. So that's that's kind of the framework that I use to think about how to divide the pie.

25:27 Scott Yeah, now I'm glancing here at the table that Gemini gave me and under success metric, it does talk about system reliability, which starts to get into that operations piece of it.

25:39 Brad under the six head metric of the VP of engineering totally

25:42 Scott VP of engineering. Yeah.

25:43 Brad well

25:43 Scott So I would think like your SRE team would be part of the VP of engineering kind of thing.

25:48 Brad let's talk about that for a second right like I'll just come out and say like I'm 100% a believer of the engineers who build the code should be. testing it and operating it right

25:59 Scott Mm-hmm.

25:59 Brad like i like the old school like i my first cto gig actually uh i had a i had an ops team that like originally the vp of the ops team reported the ceo and i was hired as the the cto vp of engineering and it's like i had a bunch of engineers that wrote code and then they threw it over the fence to this other department and this ops ops team had to run it And

26:23 Scott Mm hmm.

26:23 Brad like out of the gate, I realized that there was this toxic relationship between these two teams and

26:31 Scott Oh, yeah.

26:31 Brad I was like brought in to be the leader of one team and I spent the first two months probably trying to convince the op team ops team that I wasn't this bad guy that was brought in to somehow beat them up or like only take the side of the dev team or something like that. that

26:49 Scott Mm-hmm.

26:49 Brad you know and you know eventually the um the ceo gave the ops team to have them report to me as well you know they ended up that ended up being part of the configuration but that only worked because i had spent a ton of time like kind of patching bridges and repairing repairing bonds you know but that being said like that old model of like people over here are running it and people over here are writing it man like Isn't that super dated at this point? Like, don't we kind of want to make sure the engineers aren't throwing stuff over the fence at another team?

27:23 Scott Yes, let me be clear about what I mean by that because it's an evolution of those words and I think that's not always clear. So when I say ops, I'll just use concretely what we have in our organization now. To me, it consists of. essentially four functions, let's call it. One we talked about, which is IT. I think that is workforce operations. Keep your people working. We'll

27:44 Brad Sure.

27:45 Scott set that aside. Then the remainder about, well, then you got your security team, right? Your security team is doing multiple things. They are doing operationally they're doing like day-to-day they're getting alerts about threats and um they're getting cves that they've got to notify people about evaluate and decide if we need to address and you know and then there's um like project work they're doing to like improve the security of things so but i that The preponderance, I shouldn't say the preponderance, but I tend to include the security team. Well, let me actually pause and interrupt myself and phrase this all differently. I tend to think of the operational teams as if we weren't doing any development on this system, but we just needed to keep the system up and running.

28:38 Scott Those are the operation teams, right? So, okay, if we just needed to keep the company going, we would need IT to just keep the employees doing their things. We need security because there's outside security things happening all the time, so we couldn't just ignore that. We would need someone to pay attention and maintain our cloud infrastructure because that world is changing all the time. And what we would need, I refer to as an SRE team. team which is somebody to be monitoring this somebody somebody to be building either to continuously build and improve the observability of the system or build frameworks and platforms so that software engineering teams can have their own observability but my point being is if you were just trying to keep it running you would want somebody to be paying attention to see if it's working properly and

29:25 Brad That's

29:25 Scott so to me to me that's how i think of operations is operations is a cost of doing business if we want to keep our system going and everything else is kind of discretionary like we could choose to hire more software developers and change it or we could wind it all down and maybe you just need a handful of people to like fix bugs as they happen right

29:42 Brad Yeah,

29:43 Scott so

29:43 Brad totally.

29:43 Scott so

29:43 Brad That's fair.

29:43 Scott that's kind of what i mean when i say operations that's kind of what i mean

29:46 Brad Yeah, and I agree with all that. And I... I think there's value in having dedicated resources for that. And I think your model of thinking about it where you're like, well, I mean, even if you didn't write a single line of new code, you'd still have to operate the code that you've written. Like, that's a good way of framing it. I am only saying cautiously, like, you never want to have a culture where there's the engineers aren't also thinking about those things. Like, you know, it's like you.

30:15 Scott 100%.

30:16 Brad Build for operations, you know, and the best way to make sure your engineers are building for operations is by making sure they have skin in the game of the operations and

30:26 Scott Yeah, and the number one way to do that is to have them be on call.

30:29 Brad be on call. Exactly. Exactly.

30:31 Scott That's right. And of course, if you weren't doing any development of your software, you'd probably need less people in those operational roles because In my experience, most problems with the system are self-inflicted.

30:47 Brad Yes, systems at rest tend to stay at rest.

30:51 Scott Yeah, we do a code freeze during the holiday season at TaskRabbit. I've done this at other companies too. And lo and behold, we have very few problems during

31:01 Brad Right.

31:02 Scott that time, knock wood, because you know why? Because engineers aren't out there breaking stuff, right? So, but anyway, we've digressed, but I agree with you 100%. You do not want to throw it over the wall because that breaks. all sorts of problems.

31:17 Brad Yeah. And so, again, what do you think about this as the way of thinking about how to divide up the pie of the CTO? Okay, let's just imagine we fast forward to a point, the organization has got a single CTO, VP of engineering doing both roles. They've got architects, they've got engineering teams, they've got data team and SRE team and ops team. You know, they got these things. What do you think? I'm proposing that you use your Gemini framework and you basically look at the job functions that are in the CTO accountability and you make those people be, you know, those leaders be direct reports to the CTO and you make as many of the functions that are in the VP engineering side of it and you make those give those to the VP of engineering.

32:04 Scott Yeah, probably something like that. I think there's just a few that are a little bit, I think there's a few that are a little bit gray in my mind, but it could get worked out. I mean, I should feed it into Gemini. I should say, okay, this is how I think of my, here's the, I should actually just try it. I should put in, here's my organization as it is now with a number of people in each team and what they're responsible for. So how would you divide that between these roles and see what it says? They wouldn't even need me. They wouldn't even need me then. We could just have a. How about a CTO agent?

32:33 Brad Exactly. What do you think about, okay, so, you know, we had a recent interview where we were talking to the CTO from RevenueCat and it was enjoyable because he was

32:47 Scott Yeah,

32:47 Brad talking

32:47 Scott love

32:47 Brad about

32:47 Scott that one.

32:48 Brad how much how important it is to him and how much joy he kind of gets from the developing of the culture.

32:56 Scott Mm

32:56 Brad Right.

32:57 Scott -hmm.

32:57 Brad I thought that was pretty compelling. He talked about the importance of the technology, pretty compelling. And he talked about the sort of the business fit of it and him seeing his own role that way. And so what I think is interesting is, let's just, how do you give up? If let's say you enjoy all these pieces of the job, how do you give up the part that you've got to give something up so that you can go focus on the part that you need to go put more focus on?

33:25 Scott This is a great question. It's relevant that we're talking about this CTO VP conversation, but it's very relevant to smaller startups. Right. And very painful for a lot of founders and early engineers and those first 10 or 15 people who are doing everything. And then you start to have to have some division of labor. Not everybody can be doing everything.

33:49 Brad Yeah.

33:49 Scott Not everybody can be an admin of every tool and just go do stuff. And so your question is, how do you pick? Well, I think I guess I'm really trying to say is I think as organizations grow, one of the risks points is people having an unwillingness to pick because organizations need to have the subdivision of labor in order to grow in terms of people.

34:14 Brad I was asking a slightly different question. I'm

34:16 Scott Yeah.

34:16 Brad asking the question, you know you have to pick and maybe you've even decided how to allocate it.

34:21 Scott Mm

34:21 Brad Then

34:22 Scott hmm.

34:22 Brad you really have to let go. That requires us to reflect on our ego and be willing to hand something over to somebody.

34:30 Scott Yeah. Yeah, that's right. Well, and I think it actually there's another piece in there, too, which I think is important. And again, not just for this, but for everything. If if you're in a role where you're hiring somebody to take a piece and going to let them can have them run it. You have to be exceptionally clear about this is what you these are the decisions that you make and these are the KPIs and outcomes that you're responsible for. And as long as you are delivering on those outcomes, I'm not going to interfere with those decisions. Right.

35:03 Brad Yeah.

35:03 Scott And that's that's really hard. In fact, we had a I wouldn't call it an incident, but a conversation this week about. Um. somebody on our team who we thought was underperforming well i shouldn't say we thought was underperforming but a few things happened and the conversation came up was like hey is this is so and so doing a good job and their manager was like they're delivering on every kpi we've put in front of them why would you think they're not doing a good job and

35:25 Brad Right. Exactly.

35:25 Scott i was like i was like well that's pretty interesting because the things that people are complaining about have nothing to do with their kpis so

35:32 Brad Right. I had a back in the. back in the day i worked for a company that had unlimited vacation and there was like one of the star performers was like absolutely a rock star and would just you know nobody could complain about their work but even though there was unlimited vacation you know they still had to report it and it was like you know he took like 10 weeks vacation in the year and they were like god how can we like what he's taking 10 weeks of vacation but that that seemed right and we're like no but it's unlimited vacation like you set it up up and he's getting

36:04 Scott Right.

36:05 Brad all his work done they're like so the next year they gave him like twice as much work and guess what he got all that done and still took 10 weeks of vacation and then they they complained again and they're like like what like you know you the person is getting the job done like and it's totally within the framework that you guys agreed was part of the framework so like

36:27 Scott To me, that's the key letting go is to be clear with myself, whatever it's been, to be clear with myself, here is a relatively quantitative way that I can understand if you're doing the thing that you should be doing. And then I can let go, but actually I'd say it puts me in a different position that I think is really, I believe, I hope helpful to people I work with, which is now I can be your thought partner. I

36:57 Brad Yeah,

36:58 Scott can't

36:58 Brad totally.

36:58 Scott just right because because in this conversation we're having you're not I'm not judging you anymore like we have we have a metric over here which is the evaluation of the performance now let's just talk about what's the best way to get this done and ultimately I can completely let go and say well it's your call you know you know that you know the KPIs are trying to hit so you make the decision to

37:16 Brad Yeah.

37:16 Scott do anything like this whether it's a VP of engineering you're hiring a head of information security or head of IT whatever it is whatever you're hiring Hiring person for you got to really know how will I know if this person is successful?

37:27 Brad Yeah.

37:28 Scott In fact, there's a book I'm I have two other things I want to say really quickly. There's a book that I'm a really big fan of for managers of any type called first break all the rules. It comes with a checklist of 12 questions to answer. If you search for first break all the rules, 12 questions, you'll find a million articles and infographics about it. And so there's these 12 questions that an individual asks themselves to understand that their manager is doing a good job.

37:58 Brad Oh, interesting.

37:59 Scott And the question, and then of course the manager can use these same questions to evaluate whether they're doing a good job. And by the way, if you use any of the sort of culture tools out there, culture amp, any of the free package review tools that are out there, a lot of these questions are, you'll see the same questions in this stuff,

38:16 Brad Okay.

38:16 Scott right? This book was written by the Gallup organization. They surveyed like 150,000 people or something across all sorts of industries. Okay, so the questions are in an order from most important to least important. And the most important question, do I know what is expected of me?

38:33 Brad Yeah, totally.

38:34 Scott And then I said there was a second thing I was going to say, but I lost my train of thought when I was talking about the first one.

38:39 Brad Sorry,

38:39 Scott So if

38:39 Brad I probably interrupted you.

38:40 Scott that's your fault. No, no, I interrupted me.

38:43 Brad This has been a super productive and useful conversation to interrogate the original question you had, which is how do you know when it's time to kind of split the CTO VP of engineering role into two different roles? I don't know if we have time to get into this question, but I am a little curious about the conversation around this doesn't necessarily apply to the CTO VP of engineering role, but what if the reason you need to split is because someone was not skilled at the part at one of the parts of the job?

39:16 Scott Mm-hmm. Maybe you as the CTO are not still Maybe the one in you parts

39:20 Brad realize

39:20 Scott of the job.

39:20 Brad for yourself, hey, you know what? I'm not very good at this part of my job.

39:25 Scott Or I don't enjoy doing it anymore.

39:27 Brad Or I don't enjoy doing it. Sure.

39:29 Scott I don't enjoy, maybe you don't enjoy the strategy, so you need to hire a CTO, or you don't enjoy the execution people or process. It's one of those things.

39:38 Brad Yeah, I feel like I've been there's been times in the past when one of the reasons that I was either courted or actually brought into an organization was, you know, an existing leader, what no matter what their title was, whether their title was CTO or their title was not yet CTO in the organization. or identified that that individual didn't have the desire or capability to do one of the

39:59 Scott to this job and

40:00 Brad Mm

40:00 Scott it's

40:01 Brad -hmm.

40:01 Scott certainly easier to have that conversation if the person has the realization themselves right like i don't like this part of my job or i don't like or i don't or i don't feel like i'm good at this part of my job let's bring somebody in that is good at this and likes doing it that's going to be the easier conversation

40:17 Brad Mm-hmm.

40:19 Scott It's going to be much harder if they don't realize it.

40:22 Brad Mm-hmm. That's right.

40:23 Scott And

40:23 Brad That's right.

40:24 Scott you said this earlier that the other interesting part about this is the CTO, VP of Engineering, the language of the titles has a hierarchical nature to it. So, you know, that can be. That can be awkward too, right?

40:40 Brad That's right. And especially because depending on where your company is at, one function might actually be more superior. You know, you might be in a phase where you need more strategy and you need the strategy to lead your execution, but you might be in a place where your strategy is pretty solid and what you really need is strong execution. And it actually might make more sense for your CTO to report. to report to your VP of engineering your CTO's function to be subservient to your VP of engineering function even

41:08 Scott Yeah.

41:09 Brad though those are not how the titles work

41:11 Scott I've never seen those titles get configured that way, right?

41:13 Brad of course not

41:14 Scott The

41:14 Brad but like

41:15 Scott only

41:15 Brad if

41:15 Scott way I've ever seen that would be where the VP of engineering reports the CEO and the CTO reports the CEO and their peers. I've seen that configuration. And I think that tends to be the... solution when

41:30 Brad Right.

41:31 Scott that's when that's your problem

41:32 Brad Imagine if the titles were Chief Technology Strategist and Chief Technology Executor.

41:40 Scott Yeah,

41:40 Brad Right.

41:40 Scott exactly.

41:41 Brad And then we would organize them in all sorts of different ways, depending on what we need. But we've got these weird, weird titles. OK, does the does the audience 39 people other do they want the postscript?

41:53 Scott What's the postscript? Yes,

41:54 Brad I

41:54 Scott let's give it remember to us.

41:54 Brad the thing that I forgot.

41:56 Scott Yeah, totally. Give it to us. Give it to us. At least one of those listeners wants to hear it. Me.

42:01 Brad This is this is a pro tip I have found as a. technique for success when I step into a role coming back to that question of do I know what is expected of me to take the lead on that to go to my manager who in this case is a CEO, but go to my manager and say, these are the KPIs that I am going to operate against. Is that what you're,

42:23 Scott The metrics.

42:24 Brad does this match your, are we on the same page about this?

42:27 Scott Mm-hmm.

42:28 Brad Now, if they've given me, if they've given me KPIs, that's fine. But that's, this is the scorecard. This is what I'm operating against. Are we cool with this?

42:35 Scott Yeah.

42:36 Brad And I found that effective for a variety of reasons. One is, do I know what is expected of me? Two is it sure eliminates a lot of churn, especially if you're a CTO reporting to a CEO who is maybe not technical. They don't even know how to evaluate you.

42:52 Scott Yeah,

42:53 Brad How

42:53 Scott totally.

42:53 Brad do I know if my CTO is doing a good job? And I say this actually all the time. The only thing I know is, is my site up and running?

43:01 Scott Right.

43:02 Brad and do things get done as fast as I want them to get done and

43:05 Scott Right.

43:06 Brad have

43:06 Scott The answer

43:06 Brad enough

43:06 Scott to the first one had better be yes. And the answer to the second one is almost always no, because I always want things faster than they get done.

43:13 Brad so I found that I'm even doing a form of education sometimes by helping the CEO learn like this is how you need to evaluate things

43:23 Scott 100%.

43:23 Brad and if they say well then there's these other things I want too it's like okay sweet now I know I can also another KPI kpis that i can put in there Yep. um and i found that's and then i but then also i'm going to swivel the chair around from my superior my ceo to my team and say okay gang this is our scorecard right

43:41 Scott Yeah,

43:41 Brad totally. this is this is what we as an engineering team are being evaluated against we

43:45 Scott Totally.

43:46 Brad do that at our company we've got a once a month review with our with our all hands of what our we've got So our engineering KPIs, we have six top level KPIs, then we've got another 25 like lower level KPIs, each of those six, there's five categories and they're spread out and we review them every month. In fact, one of our folks on our team just used Clod to automate the collection of all that data. And it's a great tool then finally for this piece. Nobody's ever happy with engineering. Why are they never happy with engineering? Because they can never build stuff fast enough. There's always bugs. There's always resource contention, etc., etc. It just provides a great tool for me to celebrate victories.

44:31 Scott Yeah.

44:31 Brad So for instance, we just reviewed our March KPIs at our company. We had good zero E0P1 incidents with an uptime of 99.996. And I was like, I was, yeah, it was awesome. I was able to turn around and just say to our leadership team like, hey guys, February was a great, sorry, March was a great month in engineering, right? Just, you know, celebrate some

44:54 Scott So

44:54 Brad success.

44:55 Scott what's your KPI for uptime? four nights yeah

44:57 Brad Four nights. Yeah,

44:59 Scott so you beat it by

44:59 Brad we

45:00 Scott 60

45:00 Brad beat

45:00 Scott percent

45:00 Brad it. I guess so. Yeah. So we actually we actually had a good. I can't. There are two other really big winners. Oh, we had a really good improvement in cycle time. We have a goal of reducing cycle time by 50 percent this year. And we were down compared to where we started the year. We were down 47 percent in March, which is pretty awesome. And I can't

45:22 Scott cycle time

45:22 Brad remember the third

45:22 Scott and

45:22 Brad one.

45:23 Scott you define cycle time as essentially from

45:26 Brad when the tickets started to when it ships because

45:29 Scott yeah okay yeah

45:31 Brad the in progress or something like that to when it's yeah deployed we

45:35 Scott cool

45:35 Brad use a tool called jellyfish that captures all this data for us so we don't have to do a lot of manual capture of it really well i mean some of it let's take that back sorry like incidents during data dog The engineering stuff, life cycle times and jellyfish, you know.

45:49 Scott Yeah, totally love it. Well,

45:51 Brad All there right.

45:52 Scott you go. We figured it out. How many CTOs does it take to know when you need to split the CTO and VP of engineering jobs?

46:00 Brad All right. That was fun.

46:01 Scott Yeah.

46:02 Brad I hope there's some CTOs out there that find this one helpful.

46:06 Scott Yeah. Yeah. Let us know. Let us know in a comment on

46:09 Brad Let

46:10 Scott Spotify

46:10 Brad us know

46:10 Scott or

46:10 Brad in a comment.

46:11 Scott Apple podcasts.

46:13 Brad If you are one of the 39 that got all the way to the end of this episode, leave us a comment.

46:18 Scott Leave us a comment.

46:19 Brad All right. Brad, it's been fun talking this week.

46:21 Scott It's been fun. Have a good one.

46:23 Brad Remember, All right.

46:23 Scott smash that subscribe button.

46:25 Brad That's right. All right, buddy.

46:26 Scott Bye. This episode of the How Many CTOs Does It Take podcast was produced and edited by Safran Head. Our theme song was AI generated by Brad. Please follow us on all the social media platforms at HowManyCTOsPod. You can find us on YouTube, LinkedIn, Instagram, Facebook, Threads, X, TikTok, and Patreon, or at our website at HowManyCTOsPod.com. And remember to rate, review, and subscribe on the podcast platform of your choice. Thanks

46:56 Brad Where's

46:57 Scott for listening.

46:57 Brad the sea of the day today?