The three key CTO skills

I’ve been CTO of HappyFunCorp since last year, and it has been a deeply edifying experience. Everything people told me was mostly true: I write less code; I go to more meetings, and turn up in more conference calls; I think more strategically, and less tactically; my time is spent in a more fragmented and kaleidoscopic manner.

Oh, yeah — and I’m a lot more involved in bizdev and sales. I’m, uhhhh, not always in perfect consonant agreement with Sam Altman, but he pretty much nailed this one:

There are, however, a few things that surprised me.

HFC is more a services company than a product one — i.e. we build products for our clients — so CTOdom is a little more ill-defined than it is at other places. I don’t define and decide how to evolve the tech stack which is our competitive advantage, because, well, we have so many of them. (We build web services, smartphone apps, blockchain ecosystems, etc., and we’re a “right tool for the right job” company.) I do try to foster excellence and a coherent team spirit across our very distributed team. I do a lot of assessment and estimation. And I talk about tech to clients, and prospective clients, a whole lot.

In doing so I have found there are really three key transferable skills here, all of which I used fairly extensively when I was more of a coder, but which just keep getting more and more important the more senior you become. And they are:

Reading. I’ve always read like the wind; good thing, too, because nowadays I need to. Machine-learning papers and Github READMEs and API documentation and technical tutorials. Aspirational design documents and Statements of Need from clients. Emails and Slack backlogs. Oh, and the reading just required to keep up with the state of the art in general, when “the art” covers nearly every facet of software engineering. That is, I assure you, a lot of words.

Writing. The ability to crank out thoughtful, coherent, and concise prose on demand and on short notice — explaining problems to clients, explaining projects to engineers, breaking down projected solutions into their granular constituent parts, summarizing technologies for the non-technical, summarizing business requirements for the technical, all using the written word so that there is a tangible record that can be referred to later on — is well past “valuable.” You might think I overstate its importance because it comes so easily to me thanks to my weird background. But honestly I think I probably understate it for that same reason.

Empathy. Easily the most important of the three. Communication is often futile if you don’t understand the person you’re communicating with. Whether I’m talking to a curious client, a frustrated project manager, a questioning engineer, or a speculating designer, I need to be able to identify with them, put myself in their shoes, and comprehend the costs and benefits from their own personal point of view. If you can’t do that, it’s very hard to help them, or yourself.

Obviously I’m stacking the deck a bit here. Obviously a deep and broad technical background, and a track record in the trenches writing a panoply of software myself, are crucially important too. But the most striking thing about growing more senior in the tech industry is how, more and more, non-technical skills — dare I say it, liberal-arts skills — begin to dictate your success and/or failure. Food for thought.

Featured Image: Szczepan/Wikimedia Commons UNDER A Public domain LICENSE