First, what is a CTO?
Oxford Definition: a chief technology (or technical) officer, a senior executive with responsibility for managing the technological requirements of a company or other institution.
There’s often a misconception that the CTO needs to be the most technical person in the room and certified as such. However, a wealth of engineering degrees does not a good CTO make. The role of CTO is not to be the most technical person in the room, but rather to lead the most technical people in the organization. This requires technical acumen, but more so requires good communication and leadership skills.
That’s the fundamental basis of the CTO role: make technical decisions.
The Innovator/Visionary: Generator & prover of new ideas & strategies
Let’s go into a bit more depth on each of these.
The People Manager: This is a VP of Engineering (VPE) by another name, usually in a company that hasn’t split the role into two yet. Theoretically, one could be both the most technical contributor in an organization as well as the best technical people manager but the two are rarely met with in a single individual. However, a very good people manager will often provide more value to a company than even the best technical contributor precisely because they can attract and retain the best technical talent.
Quite often, the people manager will also be adept at laterally managing their co-executives on the leadership team thus providing effective executive support for the technical team.
Usually, the greatest challenge for the People Manager CTO is to be seen as having the necessary technical acumen to lead the technology organization. The key to overcoming that challenge is by being a great listener and communicator with the team so that they always feel connected to and heard. As well as ensure that the strongest technical team members are delegated to and entrusted with the power of making most of the technical decisions.
Famous Example: Randy Schoup: Former CTO of Kixeye and former VPE of Stitch Fix, WeWork, and Ebay. Randy is one of those rare individuals who both has great people skills as well as deep technical expertise.
The Experienced Operator: The Experienced Operator has done the role before multiple times. They have many years of experience to back up their title and often that experience is associated with well known Silicon Valley tech company names.
In my opinion, the experienced operator can vary the most in how they lead amongst all in this group but they all share a common trait:
They have a playbook and they consider it their role to run that playbook
You’ll often hear terms like “The First 90 Days” and “KPIs” from experienced operators. They’ll almost invariably have been recruited into the role and often by someone in the company who previously worked with them. They will come in and assess the company and the team, taking detailed notes, and then form a plan of action which they will communicate out and ask the team to commit to following. They will also usually have some top lieutenants they bring with them or have worked with before who they recruit in to help lead.
An experienced operator is best fit for a medium to large size company or enterprise that has already found and scaled their product and now wants to have a stable and repeatable process for delivering tech value. Given appropriate resources and power they should produce expected results in most scenarios, but beware of trying to recruit an experienced operator into a small startup as that is unlikely to be a good fit.
Famous examples: Gerri Martin-Flickinger, CTO of Starbucks and former CIO of Adobe. Scott Burke, CTO at Verily former VPE of Yahoo.
The Architect / Engineer’s Engineer: The Architect is the person perceived to have the most technical acumen on the team. They’re often highly credentialed and have deep experience in various technical topics. They usually care quite a bit about the technical architecture of the systems in the organization and spend most of their time working with the team to define the roles and scopes of those systems.
An archetype of this is the “Engineer’s Engineer”, someone who is looked up upon and well-regarded for their technical knowledge and/or contributions. They’ll usually lead an architectural committee of their team members and peers to explore new tech and make architecture decisions (e.g. choosing cloud services, network design, microservices vs. monolith, etc.).
Quite often the architect is a bit of a tinkerer and explorer of new technology as deep down they really just love working with technology. Nowadays, there is often a “Chief Scientist” role which can better fit this type of CTO as they often want to just focus on the technology and not tasked with the other pieces of executive management. Thus, retaining the authority for final technical decision-making, but without having to manage the team and able to avoid some of the executive politics.
Famous Example: Steve “Woz” Wozniak. There’s no better example of the “engineer’s engineer” than Woz, co-founder of Apple. As is often the case, he was a bit sidelined by the “business” execs but his technical contributions are unassailable. He’s also a Visionary, but nowadays the respect he receives from techies everywhere is what really defines him.
Rebecca Parsons, CTO of ThoughtWorks, churning out excellent technical architecture thoughts and leadership for decades.
The Innovator or Visionary: The innovator or visionary has a different way of seeing the world. They’re not trying to manage to an existing playbook or process but rather create whole new businesses, product lines, or technologies. They often work on special projects to find new strategic direction / prove out new technologies. In some cases, this can be as a skunkworks within the company or as a special “office” outside the mainline executive management. They often have a small, highly gifted and specialized team focused with them or get main team engineers to do rotations on their team with them.
An Innovator is another role that nowadays can also be a “Chief Scientist” as their focus is almost exclusively on R&D. They need a secured budget, long timelines, and political cover to succeed. But from such people and/or teams they lead can come amazing breakthroughs.
Famous Example: Mira Murati, CTO of OpenAI. Though there is less public info on Mira, she’s been pushing technical boundaries forward for quite some time including at Tesla, OpenLeap, and now OpenAI where some of the greatest product innovations of our time (ChatGPT and Dall-E ) have come about.
The Generalist: Usually in a smaller startup the founding engineer or in a larger org someone who has risen up through the ranks. This CTO does a bit of all these things until can fill in with other folks. Often the most active contributor to the codebase. Has a strong VPE or Directors of Engineering for people management (or regrets not having them).
The generalists excels not by becoming a deep expert on a particular system but rather by being willing to work on and understand the entire breadth of systems and codebase(s). They are problem-solvers and for that the business finds them highly valuable, especially because they are often not adherent to a particular technical ideology but rather just focused on putting out fires and “getting sh*t done.”
Generalists are great for small startups where as CTO you have to wear dozens of different hats and tackle all manner of different issues from technical spend decisions to IT management and procurement.
The challenge for a generalist is often to find the right area of focus as the team grows and to find the right people to put into place to hand off areas of the systems and codebase to so they can focus on the more priority items.
Famous Example: Chris Slowe, current CTO of Reddit as well as first hire and founding engineer at Reddit.
If you want to aspire to be a CTO someday, heed one author’s advice: “Apply technology to the business need.” You can be the smartest and most technical person in the room, but if you don’t know how to resourcefully apply tech to efficiently solve business problems then the executives are not going to look to you for that role. And: “respond to changes in the environment.” I’ve so often seen the smartest and most technical team members get stuck in a rigid way of doing things, but the folks who advance are the ones that adapt quickly to the present need.