Transcript: Introduction to How Many CTOs Does It Take? Podcast
0:00 Brad How many CTOs does it take?
0:01 Brad This podcast is all about exploring the vexing questions of engineering management and software engineering.
0:09 Brad The challenges and problems that we face that nobody seems to have found a good solution for and seeing if we can explore,
0:18 Brad discuss,
0:19 Brad uncover,
0:20 Brad and maybe just possibly.
0:23 Brad Find a way forward to solve some of these problems.
0:43 Scott Scott,
0:44 Scott you and I have known each other for years.
0:47 Scott And we started chatting regularly just as sort of like CTO to CTO support group,
0:56 Scott you know, banging our heads against the wall for these problems that we've run into throughout our career.
1:03 Scott And I think I mentioned to you like,
1:06 Scott hey, this is a lot of fun. We're talking about this.
1:08 Scott Is there a way for us to like turn this into a larger conversation?
1:14 Scott And I think that's really what inspired us to turn this into a podcast,
1:18 Scott the idea that these things that we keep running into,
1:21 Scott how to manage technical debt,
1:24 Scott how to measure the performance of an engineering team,
1:28 Scott how to have a stronger relationship between the product stakeholders and the engineers themselves.
1:36 Scott 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
1:58 Brad No, nobody's solved it. That's the thing that's so both.
2:04 Brad challenging,
2:05 Brad invigorating, and frustrating all at the same time.
2:10 Scott Right.
2:11 Scott So with this podcast,
2:12 Scott the two of us get together,
2:14 Scott we talk through these challenges,
2:15 Scott we bring other CTOs on,
2:17 Scott interview them and talk to them about the challenges that they're facing.
2:20 Scott We're bringing in product folks,
2:23 Scott stakeholders,
2:24 Scott CEOs,
2:25 Scott chief product officers to try to explore this space with them as well.
2:30 Scott And that's our goal here with How Many CTOs Does It Take podcast,
2:33 Scott to explore these challenges that we all face and hopefully maybe find some answers in this giant ball of mud.
2:45 Brad Yeah, Brad,
2:46 Brad I just want to talk to people and ask, how have you done it?
2:52 Brad Do you see a light at the edge of the forest?
2:56 Brad Is there a way that you've made progress?
2:59 Brad 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.
3:09 Brad And most people haven't.
3:12 Brad The conversations often end up being pretty frustrating.
3:15 Brad I don't know if frustrating is the right word, but like, well,
3:17 Brad we figured out nothing in this hour.
3:19 Brad But sometimes just through the exploration and the discussion,
3:24 Brad we get a little bit better understanding of the shape of the problem.
3:28 Scott Yeah, I think that's the key.
3:30 Scott And I also think that when I've talked to other CTOs or other engineering leaders,
3:40 Scott we have this common set of themes that we all run into.
3:47 Scott And then when you talk to product owners or non-technical founders,
3:54 Scott maybe CEOs or product team members,
3:57 Scott they often feel very helpless in understanding what it is we do behind the curtain,
4:06 Scott right?
4:07 Scott There's often this mystery to.
4:12 Scott what it is that the engineering team is doing.
4:14 Scott And so I think that's another really interesting aspect of these conversations is to try to have,
4:23 Scott to try to build that.
4:25 Scott That communication channel,
4:27 Scott improve that communication channel to try to get a better understanding of what those non-technical founders,
4:33 Scott non-technical executives,
4:35 Scott what their struggles are so that we can do a better job of both advocating for the engineering teams,
4:42 Scott advocating for the technology and also advocating for the businesses back to the engineering team,
4:48 Scott right?
4:49 Scott Helping the engineers understand the challenges that the business people.
4:51 Scott people face,
4:52 Scott right?
4:53 Scott And sort of build that two-way communication channel.
4:59 Brad Yeah,
5:00 Brad I mean, as an engineering leader,
5:01 Brad whether your title is head of engineering,
5:04 Brad VP of engineering,
5:05 Brad CTO, whatever your title is as the person who leads an engineering team,
5:09 Brad that is.
5:11 Brad Maybe the most important part of your job is to be that bridge,
5:15 Brad to be the Rosetta Stone,
5:16 Brad the human Rosetta Stone,
5:17 Brad so to speak, between what your stakeholders want and what your engineering teams do,
5:24 Brad because it really,
5:25 Brad they're perpendicular to each other,
5:28 Brad they're different languages,
5:30 Brad they're different rhythms,
5:32 Brad they're, you know, I don't even know how to describe it. And one of the things that I think
5:38 Brad 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.
5:58 Brad And I don't mean as much engineering like, well, I'm, you know, here's the code I'm writing.
6:05 Brad And I mean a little even less like, hey,
6:07 Brad why would you choose one database technology over another?
6:12 Brad But more the impact,
6:15 Brad the costs and benefits of what we're doing.
6:19 Brad in ways that they can understand.
6:23 Brad And often that means translating from our language to their language.
6:27 Scott Yeah.
6:28 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.
6:43 Brad outcomes or whatever customer experiences etc I'm very rarely can I get it to go the other way and get
6:50 Scott Yeah.
6:50 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
7:09 Brad You know, it's not just paint by numbers or very mechanical.
7:12 Scott 100% agree with all of that. Another thing that I think is interesting, I had a mentor,
7:16 Scott one of my earliest executive mentors,
7:19 Scott I first became a VP.
7:22 Scott And this mentor, he used to always say,
7:27 Scott engineer meets problem,
7:30 Scott problem goes away.
7:32 Scott Engineer meets wrong problem.
7:35 Scott wrong problem goes away.
7:37 Scott 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
7:45 Brad Mm-hmm.
7:45 Scott you come with solutions really understand the problem.
7:49 Scott And that's, I think, most of us sort of understand that.
7:53 Scott But when I think about that, what was great about this mentor was
7:57 Scott He was a he was a technologist and a business person,
8:01 Scott and he he taught me how to wear both those hats in a way that for the non-technical business owner.
8:11 Scott It's so hard for them often to to articulate the real problem that they have in a way that.
8:23 Scott is open-minded to potential multiple solutions.
8:28 Scott And often it's human nature for technologists for sure. Technologists love solutioning and often non-technologists also sort of gravitate towards solutions.
8:44 Scott 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,
8:55 Scott product debt.
8:57 Scott How do you measure performance? How do you measure appropriateness of a project?
9:05 Scott How do you scope a project?
9:08 Scott This notion of that translation,
9:11 Scott that Rosetta Stone,
9:12 Scott as you said,
9:13 Scott between what is the product stakeholders,
9:16 Scott what do they really need for the business to succeed and translating that into
9:24 Scott 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
9:31 Brad Mm-hmm.
9:31 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
9:42 Scott 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.
9:57 Scott And so being able to be that that real connective tissue is a big part of these challenges that I think we face.
10:06 Brad Well, Brad,
10:07 Brad it seems like we could have these conversations endlessly.
10:11 Brad There's never a good place to stop, but now is the time to stop.
10:16 Scott Everybody remember to subscribe,
10:19 Scott rate,
10:20 Scott and review.
10:21 Scott That helps us grow our listenership and we really appreciate the time that you put in to listen to this episode.
10:28 Scott It's great talking to you again,
10:29 Scott Scott.
10:29 Scott See you next week.
10:31 Brad Bye, Brad.
10:32 Scott This episode of How Many CTOs Does It Take podcast was edited by Safran Eptigal.
10:37 Scott Our theme song was AI-generated by Brad.
10:41 Scott Please follow us on all the social media platforms at howmanyCTOsPod.
10:46 Scott You can find us on YouTube,
10:48 Scott LinkedIn,
10:49 Scott Instagram,
10:49 Scott Facebook,
10:50 Scott Threads, X,
10:50 Scott TikTok,
10:51 Scott and Patreon.
10:52 Scott Or at our website at howmanyCTOsPod.com.
10:57 Scott And remember to rate, review,
10:59 Scott and subscribe on the podcast platform of your choice.
11:01 Brad How many CTOs
11:03 Scott Thanks for listening.