Should a CTO be technical? What an odd question! Would it be OK for a CFO not to understand GAAP? The answer may be more complicated than you’d think.
Lets discuss the term technical in the context of leadership. I want to suggest the following definition.
A technical leader is someone who can inspire individual contributors to do their best work, while simultaneously commanding respect for their abilities and accomplishments in the areas of technology.
In contrast, a non-technical leader is an organizer that delegates all technical aspects to others.
In software, we can all agree that all developers must be technical, by definition. Leads usually emerge from that group, shifting some of their responsibilities from coding to enabling others to do their best work. They typically continue to spend a lot of time writing production software, therefore they must remain technical. Following the career ladder we find managers and Heads or VPs of Engineering, directly responsible for software delivery. From my experience, respect and trust are key elements of successful technical leadership, therefore I will declare that everyone up to VP of Engineering should be technical. They can, of course, be non-technical, but that puts them at a significant disadvantage, making it twice as hard for them to earn trust from the engineers they serve.
What about a CTO? The role of a CTO is unique, spanning technology, people and business serving the entire company and often leading the technology organization. By my definition a CTO must continue to be technical, but I simultaneously agree with those, who argue that an overly technical CTO may second-guess the team, while lacking detailed information, or occupy the space of hands-on technical leaders, preventing them from growing or accomplishing results. A CTO does not need to code production software, but should have deep understanding of systems architecture, and be able to accurately measure a team’s capacity and velocity. A CTO must double-down on interpersonal skills and continue commanding respect from the technology team, while earning similar respect from the rest of the company. They must effectively evaluate who’s driving technology forward vs. who is holding it back, understand risks, strengths and weaknesses of people, systems and processes. Finally, a CTO must bring technology expertise to the business and demonstrate what’s possible as the executive leadership collectively defines the company strategy.
I’ll take this argument further and quote another New York CTO.
Being technical establishes a cultural quality internally, beyond tech, of knowledge that is earned. It communicates this cultural quality to external partners, potential investors, and others about the organization. There are instincts that you develop from working with code, building systems in the real world, suffering through making the wrong decisions, cleaning up messes, learning hard lessons. Think about what it says to everyone when the CTO has the right instincts. It’s inspiring.
I want to thank members of the New York CTO Club for contributing ideas to this topic.