Introduction to How Many CTOs Does It Take? Podcast
How Many CTOs Does It Take?: Bridging the Gap Between Engineering and Business
In the inaugural episode of 'How Many CTOs Does It Take?', hosts Scott and Brad explore complex challenges in engineering management and software development.
They delve into topics such as managing technical debt, measuring engineering team performance, and improving communication between engineers and product stakeholders. Through discussions with fellow CTOs, product teams, and business leaders, Scott and Brad aim to uncover insights and create better understanding to tackle these persistent issues.
This episode sets the stage for a podcast series focused on solving the difficult problems that engineering leaders face daily.
Brad: How many CTOs does it take?
This podcast is all about exploring the vexing questions of engineering management and software engineering.
The challenges and problems that we face that nobody seems to have found a good solution for and seeing if we can explore,
discuss,
uncover,
and maybe just possibly.
Find a way forward to solve some of these problems.
Scott: Scott,
you and I have known each other for years.
And we started chatting regularly just as sort of like CTO to CTO support group,
you know, banging our heads against the wall for these problems that we've run into throughout our career.
And I think I mentioned to you like,
hey, this is a lot of fun. We're talking about this.
Is there a way for us to like turn this into a larger conversation?
And I think that's really what inspired us to turn this into a podcast,
the idea that these things that we keep running into,
how to manage technical debt,
how to measure the performance of an engineering team,
how to have a stronger relationship between the product stakeholders and the engineers themselves.
we've through our career we keep running into these things and each organization sort of struggles with these challenges and so our goal here with how many cto's does it take podcast is to sort of explore those those challenging problems we don't we don't think we've solved it right you haven't solved it yet have you scott
Brad: No, nobody's solved it. That's the thing that's so both.
challenging,
invigorating, and frustrating all at the same time.
Scott: Right.
So with this podcast,
the two of us get together,
we talk through these challenges,
we bring other CTOs on,
interview them and talk to them about the challenges that they're facing.
We're bringing in product folks,
stakeholders,
CEOs,
chief product officers to try to explore this space with them as well.
And that's our goal here with How Many CTOs Does It Take podcast,
to explore these challenges that we all face and hopefully maybe find some answers in this giant ball of mud.
Brad: Yeah, Brad,
I just want to talk to people and ask, how have you done it?
Do you see a light at the edge of the forest?
Is there a way that you've made progress?
And just, I haven't figured out a lot of these things. And I just want to talk to the people and see if I can learn from them to see if they've figured out these things.
And most people haven't.
The conversations often end up being pretty frustrating.
I don't know if frustrating is the right word, but like, well,
we figured out nothing in this hour.
But sometimes just through the exploration and the discussion,
we get a little bit better understanding of the shape of the problem.
Scott: Yeah, I think that's the key.
And I also think that when I've talked to other CTOs or other engineering leaders,
we have this common set of themes that we all run into.
And then when you talk to product owners or non-technical founders,
maybe CEOs or product team members,
they often feel very helpless in understanding what it is we do behind the curtain,
right?
There's often this mystery to.
what it is that the engineering team is doing.
And so I think that's another really interesting aspect of these conversations is to try to have,
to try to build that.
That communication channel,
improve that communication channel to try to get a better understanding of what those non-technical founders,
non-technical executives,
what their struggles are so that we can do a better job of both advocating for the engineering teams,
advocating for the technology and also advocating for the businesses back to the engineering team,
right?
Helping the engineers understand the challenges that the business people.
people face,
right?
And sort of build that two-way communication channel.
Brad: Yeah,
I mean, as an engineering leader,
whether your title is head of engineering,
VP of engineering,
CTO, whatever your title is as the person who leads an engineering team,
that is.
Maybe the most important part of your job is to be that bridge,
to be the Rosetta Stone,
the human Rosetta Stone,
so to speak, between what your stakeholders want and what your engineering teams do,
because it really,
they're perpendicular to each other,
they're different languages,
they're different rhythms,
they're, you know, I don't even know how to describe it. And one of the things that I think
We can do, I don't even think, I think one of the things we do that is of most service to our business stakeholders is help them understand and find ways to explain to them engineering in language they understand.
And I don't mean as much engineering like, well, I'm, you know, here's the code I'm writing.
And I mean a little even less like, hey,
why would you choose one database technology over another?
But more the impact,
the costs and benefits of what we're doing.
in ways that they can understand.
And often that means translating from our language to their language.
Scott: Yeah.
Brad: Very rarely can I effectively translate from their language to our language. I have to go the other way and figure out how to express what we're doing in engineering in terms of time or money or.
outcomes or whatever customer experiences etc I'm very rarely can I get it to go the other way and get
Scott: Yeah.
Brad: non engineers to understand the other way around in part I think because so much of the engineering side is kind of well it is a craft and so much of that craft is based on experience and learning over time it's not based on
You know, it's not just paint by numbers or very mechanical.
Scott: 100% agree with all of that. Another thing that I think is interesting, I had a mentor,
one of my earliest executive mentors,
I first became a VP.
And this mentor, he used to always say,
engineer meets problem,
problem goes away.
Engineer meets wrong problem.
wrong problem goes away.
And I think that that is a nice, you know, it's a nice summary of another concept that we hear a lot about before
Brad: Mm-hmm.
Scott: you come with solutions really understand the problem.
And that's, I think, most of us sort of understand that.
But when I think about that, what was great about this mentor was
He was a he was a technologist and a business person,
and he he taught me how to wear both those hats in a way that for the non-technical business owner.
It's so hard for them often to to articulate the real problem that they have in a way that.
is open-minded to potential multiple solutions.
And often it's human nature for technologists for sure. Technologists love solutioning and often non-technologists also sort of gravitate towards solutions.
And so sort of that's another really important piece of this. And it comes up in multiple themes that we touch on, you know, technical debt,
product debt.
How do you measure performance? How do you measure appropriateness of a project?
How do you scope a project?
This notion of that translation,
that Rosetta Stone,
as you said,
between what is the product stakeholders,
what do they really need for the business to succeed and translating that into
words that the engineers can understand so that they build the right so they solve the right problem they build the right thing right and
Brad: Mm-hmm.
Scott: then being able to communicate back to those stakeholders this is why that's hard because it's so often they don't they don't understand like
Two asks sound equally hard to them, and the thing that's easy to change in the code versus difficult to change in the code is often a complete mystery and almost it's almost unfathomable to them that one is hard and one is easy.
And so being able to be that that real connective tissue is a big part of these challenges that I think we face.
Brad: Well, Brad,
it seems like we could have these conversations endlessly.
There's never a good place to stop, but now is the time to stop.
Scott: Everybody remember to subscribe,
rate,
and review.
That helps us grow our listenership and we really appreciate the time that you put in to listen to this episode.
It's great talking to you again,
Scott.
See you next week.
Brad: Bye, Brad.
Scott: This episode of How Many CTOs Does It Take podcast was edited by Safran Eptigal.
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.
Brad: How many CTOs
Scott: Thanks for listening.