An Ideal Partnership: How and When to Split CTO and VP of Engineering Duties
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.
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCTOs #Podcast #CTOs #CTOPodcast #ChiefTechnologyOfficer #Technology #Engineering #SoftwareDevelopment #SoftwareEngineering #TechLeadership #EngineeringLeadership #EngineeringCulture #TechDebates #VPofEngineering #Gemini #CTOvsVPE #VPE #SecurityMindset #AI #DevOps #GrowthMindset #TeamCollaboration #CorporateCulture #BusinessGrowth #AIIntegration #Operations #StrategicVision #ManagementStyles #RoleDivision #ExecutiveDecisions
Articles from this episode
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.
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...
Scott: Scott Porad.
How are you today,
Brad?
Brad: I'm doing great. What is on your mind today,
Scott?
Scott: It's not about AI.
Brad: It's not?
Are you sure?
I bet you will find a way to talk about AI.
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
Brad: That's awesome.
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
Brad: Yep.
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.
Brad: Totally. Well,
there you go. That's our discussion of AI for this episode.
What's really on your mind, Scott?
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
Brad: Yep,
Scott: you know
Brad: right.
Scott: Dunbar's number yeah
Brad: Yep, yep, totally.
Scott: so
Brad: But you want to explain Dunbar number to our 39 listeners?
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
Brad: Yep.
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
Brad: Yeah.
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.
Brad: Yep.
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
Brad: Yeah.
Scott: and just like
just like operating day to day like how
Brad: Yep.
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
Brad: Totally.
Scott: so I'm just wondering what you think about there's so many different ways we could talk about this um
Brad: Yeah.
Well,
Scott: yeah
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.
Scott: Oh, yeah.
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
Scott: Mm
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?
Scott: Mm-hmm.
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?
Scott: Well, would you like to hear what Gemini has to say about
Brad: What
Scott: that?
Brad: does Gemini
Scott: Because
Brad: have to I say
Scott: as
Brad: about that?
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
Brad: Sure.
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,
system reliability.
I wonder why retention,
I guess for people.
Brad: The people retention.
By the way, how are you feeling about this? How are you feeling about
Scott: Pretty
Brad: the good. speed of this?
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
Brad: Yeah.
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,
Brad: Yeah.
Scott: you know, providing the direction. So big up, that's what Gemini has to say. And that is.
aligns with my thoughts.
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.
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.
Brad: Yeah, totally.
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.
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
Scott: That's right.
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.
Scott: Mm
Brad: And
Scott: -hmm.
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
external facing a leader,
right?
Scott: It's interesting. I more often get the opposite call,
which
Brad: Oh, yeah?
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,
Brad: Totally, that happens too.
Scott: but they both happen for sure.
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
Scott: Yeah,
Brad: when you should bring in the vp of engineering right
Scott: that's yeah.
Brad: a
Scott: Or when the engineering organization maybe needs more vision.
Brad: revision or supervision yeah
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.
Brad: Yeah.
Scott: Right someone who has that ability to have that vision
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
Scott: Mm
Brad: then
Scott: -hmm.
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
Scott: Hmm
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.
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
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
Scott: Right.
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.
Scott: They are running the show.
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?
Scott: Mm
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
Scott: Mm-hmm, mm
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
Scott: -hmm.
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
Scott: Mm
Brad: up you
Scott: -hmm.
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
Scott: Mm hmm.
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
Scott: Yeah,
we got we got to the end real fast,
actually.
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
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.
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
one has to have that manage that relationship with your finance team as
Brad: Yeah.
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
Brad: How
Scott: how
Brad: do you define?
Scott: do you carve up the pie
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.
For strategy.
Scott: Can I get a little detour on that for a second?
Brad: Yeah.
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
Brad: Yeah.
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
Brad: Fair
Scott: part
Brad: enough.
Scott: it's a core part of information security so
Brad: Fair enough.
I agree.
I will argue that point.
And I'll just say like.
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
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
Scott: you punt it
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.
Scott: Yep.
Brad: Deciding what to build and building it.
Scott: Yeah.
Brad: Is that a fair dichotomy?
Scott: Yeah.
And the one thing it doesn't really include is operating things.
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
Scott: Mm-hmm.
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
Scott: Mm
Brad: that's
Scott: -hmm,
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
Scott: mm-hmm, mm-hmm.
Brad: Right.
So
Scott: Yeah.
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
of
Scott: Mm-hmm.
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,
Scott: Mm
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
Scott: -hmm.
Brad: of things.
So that's that's kind of the framework that I use to think about how to divide the pie.
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.
Brad: under the six head metric of the VP of engineering totally
Scott: VP of engineering. Yeah.
Brad: well
Scott: So I would think like your SRE team would be part of the VP of engineering kind of thing.
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
Scott: Mm-hmm.
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
Scott: Mm hmm.
Brad: like out of the gate, I realized that there was this toxic relationship between these two teams and
Scott: Oh, yeah.
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
Scott: Mm-hmm.
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?
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
Brad: Sure.
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.
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
Brad: That's
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
Brad: Yeah,
Scott: so
Brad: totally.
Scott: so
Brad: That's fair.
Scott: that's kind of what i mean when i say operations that's kind of what i mean
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.
Scott: 100%.
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
Scott: Yeah, and the number one way to do that is to have them be on call.
Brad: be on call.
Exactly.
Exactly.
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.
Brad: Yes, systems at rest tend to stay at rest.
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
Brad: Right.
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.
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.
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?
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
Scott: Yeah,
Brad: talking
Scott: love
Brad: about
Scott: that one.
Brad: how much how important it is to him and how much joy he kind of gets from the developing of the culture.
Scott: Mm
Brad: Right.
Scott: -hmm.
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?
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.
Brad: Yeah.
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.
Brad: I was asking a slightly different question.
I'm
Scott: Yeah.
Brad: asking the question,
you know you have to pick and maybe you've even decided how to allocate it.
Scott: Mm
Brad: Then
Scott: hmm.
Brad: you really have to let go.
That requires us to reflect on our ego and be willing to hand something over to somebody.
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.
Brad: Yeah.
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
Brad: Right. Exactly.
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
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
Scott: Right.
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
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
Brad: Yeah,
Scott: can't
Brad: totally.
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
Brad: Yeah.
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?
Brad: Yeah.
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.
Brad: Oh, interesting.
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,
Brad: Okay.
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?
Brad: Yeah, totally.
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.
Brad: Sorry,
Scott: So if
Brad: I probably interrupted you.
Scott: that's your fault.
No,
no, I interrupted me.
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?
Scott: Mm-hmm.
Maybe you as the CTO are not still Maybe the one in you parts
Brad: realize
Scott: of the job.
Brad: for yourself,
hey,
you know what?
I'm not very good at this part of my job.
Scott: Or I don't enjoy doing it anymore.
Brad: Or I don't enjoy doing it. Sure.
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.
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
Scott: to this job and
Brad: Mm
Scott: it's
Brad: -hmm.
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
Brad: Mm-hmm.
Scott: It's going to be much harder if they don't realize it.
Brad: Mm-hmm. That's right.
Scott: And
Brad: That's right.
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?
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
Scott: Yeah.
Brad: though those are not how the titles work
Scott: I've never seen those titles get configured that way, right?
Brad: of course not
Scott: The
Brad: but like
Scott: only
Brad: if
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
Brad: Right.
Scott: that's when that's your problem
Brad: Imagine if the titles were Chief Technology Strategist and Chief Technology Executor.
Scott: Yeah,
Brad: Right.
Scott: exactly.
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?
Scott: What's the postscript?
Yes,
Brad: I
Scott: let's give it remember to us.
Brad: the thing that I forgot.
Scott: Yeah,
totally.
Give it to us. Give it to us.
At least one of those listeners wants to hear it. Me.
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,
Scott: The metrics.
Brad: does this match your,
are we on the same page about this?
Scott: Mm-hmm.
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?
Scott: Yeah.
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.
Scott: Yeah,
Brad: How
Scott: totally.
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?
Scott: Right.
Brad: and do things get done as fast as I want them to get done and
Scott: Right.
Brad: have
Scott: The answer
Brad: enough
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.
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
Scott: 100%.
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
Scott: Yeah,
Brad: totally. this is this is what we as an engineering team are being evaluated against we
Scott: Totally.
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.
Scott: Yeah.
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
Scott: So
Brad: success.
Scott: what's your KPI for uptime?
four nights yeah
Brad: Four nights.
Yeah,
Scott: so you beat it by
Brad: we
Scott: 60
Brad: beat
Scott: percent
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
Scott: cycle time
Brad: remember the third
Scott: and
Brad: one.
Scott: you define cycle time
as essentially from
Brad: when the tickets started to when it ships because
Scott: yeah okay yeah
Brad: the in progress or something like that to when it's yeah deployed we
Scott: cool
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.
Scott: Yeah, totally love it. Well,
Brad: All there right.
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?
Brad: All right. That was fun.
Scott: Yeah.
Brad: I hope there's some CTOs out there that find this one helpful.
Scott: Yeah.
Yeah.
Let us know. Let us know in a comment on
Brad: Let
Scott: Spotify
Brad: us know
Scott: or
Brad: in a comment.
Scott: Apple podcasts.
Brad: If you are one of the 39 that got all the way to the end of this episode,
leave us a comment.
Scott: Leave us a comment.
Brad: All right.
Brad, it's been fun talking this week.
Scott: It's been fun. Have a good one.
Brad: Remember, All right.
Scott: smash that subscribe button.
Brad: That's right.
All right, buddy.
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
Brad: Where's
Scott: for listening.
Brad: the sea of the day today?