Show Notes
With Andy away, Mon-Chaio dives into the topic of what it means to be a Chief Technology Officer (CTO) in today’s diverse tech landscape. Inspired by a recent conversation with a venture capitalist, Mon-Chaio reflects on the wide range of skills and experiences that different CTOs bring to the table. He discusses the various types of CTOs, from deeply technical experts to those who primarily manage vendor relationships. This episode questions how well communities designed for CTO networking really serve their members given their vastly different roles and day-to-day tasks. Don’t miss this reflective and thought-provoking episode.
Transcript
Hello everyone. Mon-Chaio here recording from San Diego, which for those of you that know me is not Seattle. I am away out of town on spring break, which is also why Andy and I are unable to hook up this week. And so I am recording a short vacation cast episode for all of you today. The topic of this episode is something that I’ve had rolling around in my mind for a while, but have never sort of verbalized.
It came to a head recently when a VC contacted me and asked me whether I knew anyone from my network that would be a great CTO for a company that was in their portfolio that got me thinking about my network and thinking about who I might or might not recommend.
And this was more challenging than I expected because the thing that’s been rolling around in my mind recently is how many different people and different skill sets roll up to a title of CTO. As I started thinking through this, it reminded me of my times. When I would help companies interview for CTOs.
And how many types of candidates would come in with prior CTO experience on their resume? Sometimes , 5, 10, 15, 20 years of CTO experience on the resume and how different they would look. I’ve had CTOs come in that were very deeply technical in one area. But had no leadership experience whatsoever.
They couldn’t really tell you how to do organizational design. They couldn’t really tell you how to create a three or five year product strategy. Their value add for their company throughout their years of experience was being very deeply technical. I’ve had the opposite CTOs as well. People that have spent years in the industry essentially being.
Ahead of product. A lot of them have never had onshore engineering teams.
Many of them have never even had their own development agencies. Outsourcing the entirety of their work to various vendor companies that were kind of mini software companies in and of themselves. These CTOs would simply give requirements to these companies and act as a product manager where software came back, they would demo it, see if it met their acceptance criteria, and have those vendor companies release it to the world.
I’ve also had CTO candidates who seem to be more vendor managers. And here I’m not talking about product vendors, I’m talking about cloud vendors. These are folks that were very well plugged into all of the different. MSPs or MSPs that were out there in the world that were able to negotiate different cloud vendor contracts or were managing specific telephony contracts, that sort of a thing that didn’t seem to understand product engineering at all and weren’t very technical in so far as they hadn’t had any modern engineering experience.
And I think this is strange, especially because there are communities out there that purport to bring CTOs together
to network and to learn from each other, but when your skill sets are so different and your day-to-day work is so different, what does it mean to be a community of ETOs?
How well do these communities end up connecting these folks? And I wonder if these communities do find that these folks are actually able to build connection and mentorship and learn.
I’m gonna keep this week short and sweet. Andy and I will be back next week for a full episode of the TTL podcast where we will resume talking about models that help with organizational diagnosis. But until then, be kind and stay curious.
Leave a Reply