Should the CTO Know How to Code? – Hywel Carver, Skiller Whale

This is Textron TV. Hey everyone, welcome back to Tech strong TV. Our next guest is a new guest with the first time company on our show to tell you about.

We have a good conversation. I think I want to introduce you to Howell Carver. How welcome to Tech strong TV.

Hi Alan. I'm really glad to be here. Thanks for having me our pleasure.

So the first thing I want to get out of the way is, you know, our audience is watching they see the little third on the bottom of the screen as your name in title and company name and you know, we have an unusual. Spelling of the first name Howell. And you know, why don't we share with the audience?

What's behind that? Yeah, definitely. So I am half Welsh and I have a Welsh name and and that's why that's where how we'll come come from which is why it's spelled in such an unusual way and I guess I'm lucky not to have a double D in there as well, which is also another common with thing about there or an unusual thing about the Welsh language and well, I'm not Welsh myself I have this watch name that no one can print out but you you got it right with howl so you are the one Personnel speak to you today.

He gets it, right. All right, thank you all and you know, what half Welch better than that. Well s***.

All right, so welcome how give us a little let's hear a little bit of your story of your background. Sure. So I've been writing code since I was nine years old and self-taught from self talk from a book.

So I had the Sands teach yourself sea in 21 days birken. I learned see from that wrote websites from the age of 14 and studied engineering and then I've been a CTO for the last last 10 years or so of my life and either leading founding companies or mentoring and coaching other ctOS as well as running dinner events for ctas and all of that led me to start skill away. The company lead now where my title is the CEO.

excellent You mentioned the company what you mentioned it again. Skill a while. So tell us where is that name come from and so my Founders and I all have a love of terrible puns and one of the things that we thought early on is that we wanted to do a very different kind of learning.

I think I think the majority of learning is focused on knowledge transfer and isn't really focused on outcomes of people's ability changing and so we wanted to focus very hard on skills on making people genuinely capable not just giving them the knowledge again try something and hopefully become capable over time. And of course when you're naming a company you one of the key requirements is making sure that you can get the com domain name for it and most of the obvious things with the word skill in and were taken and so that's together with our love of bad puns that we had a kind of 10 minute session just riffing about puns based on words, like skill and capability and and one of us came up with skill away and it was one of those kind of like, you know, the first time someone says it you laugh and then the second time someone says that you love quite a lot less than the third time. You're like, it's not funny anymore, but that might work as a company name and absolutely it's then I I you know, I just want to make sure I want to spell this for the audience.

com exactly website like a killer whale but with an s on the front. Okay. There you go.

That makes it easy to remember. So how long is the company been around? So we incorporated in early 2018 and it was a side project of mine for a long time.

And while I was I was doing consulting work and doing being an intern CTO and coaching other ctOS and and then it kind of grew it was always a side project. I hoped with gray but and I wasn't able to be full time on it for a long time. And so it starts out two days a week and then I've been full-time and we've been going full-time with the company since the end of 2019.

Actually love it. and you know I I wanted we know what we want to jump into here about ctOS and stuff. But before we get there, I want to flesh out a little bit more about what the company offers and how people can.

You know find out more and and you know getting an on-ramp here if you will. Yeah, absolutely. So one of the things I've always found hardest as a as a CTI is the constant need to achieve more right you want to be able to build stuff faster build stuff better, but you still have a limited resource available to you have limited budget and and limited people and so there's this constant problem where I wanted to adopt new technologies that would enable us to do more stuff in the team to do better work faster or I wanted to hire more experienced and able people then my budget or the market competition would allow and I suspect that's a problem that's got a lot worse recently and for people as as kind of macroeconomic conditions are really hitting hiring and lots of companies letting people go but still we have this need to achieve more and get more done.

And it always felt to me like there should be an approach to learning that would make teams more capable allow you to take a group of people and make them genuinely good at a new technology or genuinely better at technologies that they already use and looking at all the all the L&D training eLearning options that were available to me. None of the ones that I tried made made any difference there was no noticeable impact on team abilities on velocity or anything and so skill a whale really the ideas for that came out of how I was taught as a student that Cambridge where they have a very kind of unique approach to and small group learning and we worked out that the things that were needed for genuinely effective learning were to be Diagnostic and which is to to understand exactly what someone doesn't know already eat individual on a team and then only offer learning at the intersection between the kind of top-down leaders strategy and the bottom up individuals skill gaps for that learning to be experiential and expert LED. So you are solving problems and doing things yourself in the learning but you can get immediate feedback from someone who's already expert in it and for all of that to be problem-based.

You can't really learn a skill without trial and error and feedback. And so our goal is for everyone to come out of a session having not just learned new information, but put it into practice solved hard challenging problems with it failed understood why they failed and then being able to succeed so that when they come out they're able to put that into practice in their work immediately. And and we we call this form of learning deep coaching partly because deep relates to kill a whales and we as a company really Embrace ocean puns and partly because deep stands for Diagnostic experiential expert LED and problem-based which are the cool things that mean that learning is not just a perk or a kind of side benefit to reduce churn of your engineers, but it becomes part of your strategy it becomes how you think about evolving the capabilities of your team and achieving more growth next year without having to grow head count.

Love it. You know I I think giving current macro conditions economic conditions This is really a lesson that teams ctOS and you know hiring teams need to understand. right because otherwise, it's it's for too many in the tech world.

It's been a churn and burn. Of a hiring Cycles, right? Look I are you you're gonna be here 12 to 18 months and I'm getting someone else.

Sometimes you hear less than 18 12 to 18 months and then I'm gonna start over again and I I get all this Tech debt and kind of tribal knowledge. How do I transfer that? This is you know gaps and it's hard.

So this I I love what you doing. This is one of the things that comes from tying growth to headcount is is if you want to do more next year you have just have to keep bringing in more people and as soon as conditions change, you you have to let them go again or you know, they leave by themselves on a kind of relatively short after a relatively short time. Which has a huge human impact all of the people on on visas, you know, which are tied to their work might have to uproot their lives and go move back to a different country.

But it's also extremely expensive like hiring is not a fast or easy or cheap process and whereas if you can invest in your people and gain new capabilities that way the research we've done suggests that 61% more efficient as a way of growing the team to the same as growing with what the team can do and becoming more productive than if you hire to achieve the same productivity. a great I want to turn we probably took more time on this part, but I think it was worth it. But I want to turn to what we wanted to talk about today, which is you know, look a lot of times.

There's different flavors of CTO. I guess they're always happen right back in my day when I was. You're doing Venture back startup.

See some ctrs are very forward-facing doing a lot of marketing analysts relations, press that kind of thing. And then some ctOS were sort of backroom, right? They were running engineering really there were VP of engineering ctOS or product.

Running product and strategy there and then you know today we have things like field CTO. So we're out there talking to customers and so forth. But in many organizations, right the CTO role is is pivotal in in picking the kind of team you have whether that is the Developers.

Sales engineer support product Etc. And your question comes up how technical should that? Ctov, right.

Should they should they be able to code? Right? If you've got a CTO who doesn't know how to code how the heck can he be CTO and be working, you know, maybe managing a development team or what have you?

So I'm gonna throw it out at you. How should ctOS? Have some coding skills.

I I see too extremes here and I don't think either of the extreme answers is right. So one streams rarely right? We're good definitely true.

So one of the extremes I see is people who say every CTO must be able to code. And the Other Extreme that I sometimes see is if you can if your job involves coding then you can't be the CTO. And I think neither it neither is true.

So for me the CTO is the the most senior executive who oversees that the tech organization and sometimes product and sometimes like that includes CII responsibilities, but the job of that person is to ensure the kind of commercial success of the company through technology. And I think that's that job title applies when you're a two-person company as well. Of course at that stage.

Your CTO is almost certainly having to write code or manage the manage their the code writing of an Outsource group of people. I think that broad responsibility stays the same when you talk about a 5,000 person company, but it is almost certainly not an effective use of that person's time to be coding. So I definitely think if you are coding as part of your job, you can still be a CTO but whether you need to know how to code is slightly different question, right?

Can someone run a 5,000 person Tech organization say without knowing how to code and I think it is possible so long as you have enough understanding that you can be empathetic to the people who are writing code. I think software development is a team sport. Ultimately.

I think we know this as well established now that it's The Human Side is the the side that ends up holding you back as soon as you have more than say two people working on a project and therefore it's the human skills of empathy to do with coding that we need in our engineering leaders at the top level. So I don't mind if a CTO doesn't know how to code but if they don't understand Concepts like technical debt or they they can talk about what an API is and then I would I think they would struggle to Be an Effective leader of that organization to make sensible trade-offs to ask the right questions. To know how to do due diligence as part of an acquisition and all indeed to go and talk to customers about how they could integrate with our product.

So I think while you might not need to know you might not need to be able to write code you need to have enough of an understanding that you can still make sensible decisions and make good judgments, which is harder if you can't code but not impossible. Got it. Got it.

Got it. You know push back on that. mmm Right.

I I know a lot of ctOS where I sit here I talk to cto's all day. But I also even before doing this I you know, I was very involved in I've been involved. I know a lot of a lot of friends who are CTS.

and I think if you are as I call it an inward facing CTO working with engineers. Yeah without having some coding. knowledge skills It's very hard to empathize and really yeah, I always say you got to be able to talk the talk and walk the walk.

Right, I could talk to talk but I can't code so I don't walk that walk. Right, and I think you need that for that sort of. internal CTO role but for other ctrls like the field CTO and maybe the forward facing CTO.

I think you really have to have it intimate knowledge of the market and your products. But I don't believe coding. is a must-have skill right, I I think You know, I learned I did a company.

I helped take public back in the com days and was basically we were offering hosted Lotus Notes and people soft and stuff like that old stuff. And but we we did a study back then about water companies willing to Outsource. Right and they'll Outsource things that are non-core and non-critical if something's core, but not critical though out.

So I said if something's critical but not core. They'll Outsource it if it's not going not create a cold out. Absolutely Outsourcing so I'll apply the same test here.

If coding is not core to what the company Mission is on my mission is and it's not critical that I do coding. It's not. Then it it's it's not a must-have.

It's just not it's something you know, you can Outsource in essence. So I think that's sort of the litmus test. Is it core and critical?

For the CTO to and and I think it changes organization organization, but that's to me that the test and just my two cents. I think that makes sense that if if the if the so if the company is doing something very software heavy but if what you sell is sold to other software companies. For example, if you're CTO of AWS, I expect you need to have much more understanding of how infrastructure works then able to see here at most other other companies, but I think one of the things that can help you with that is the fact that that there are so many roles now that you can hire under the CTO that can that can supplement for that so you could your job title might be the CTO but you might have a VP of engineering or VP of infrastructure or if information security and if if you as a CTO don't know how to code you can entirely compensate for that by surrounding yourself with with people who do and I think that's one of the nice things about about having an executive level job title is to some extent you define.

Which bits are your role and which responsibilities you can delegate and that you know what that brings up a whole nother subject. Which is looked today, I'm not saying we're inventing roles. But we are.

we you know, so I I'm the CTO and these are my strengths but these are the things I need. Help from staff on and so you we start You Know Chief digital offices Chief data office. So we might have a chief coding officer.

Right and we kind of make titles up as we go to fulfill these roles that maybe weren't You know traditionally. Roles that we looked at so yeah, absolutely, right anyway how we're about out of time here. I got to wrap up.

I just want to go through again. It's like killer whale except with an asset the top. com, check it out it an interesting take and a new take a fresh look.

at how to build technical teams Fair exactly how to get the capabilities you need with the people you already have so you don't have to hire them in. And get off of that hamster wheel how thanks for being I guess do come back and keep us posted on this and best of luck to you. Thank you so much.

And I really enjoy chatting to you. Alrighty, this is Alan schemel for texture on TV. We'll be right back.