Only 3 types of CTO?

For a few months now, there have been a lot of articles explaining that there are 3 types of CTO: the hacker, the stabilizer, and the industrializer. Although accurate in substance, these articles are incomplete when we go into practice. But why is that?

Let’s start by going over these three types again.

The Hacker

You have just created your startup and you are looking to deliver your product as soon as possible with your famous MVP that will allow you to make yourself known and really launch your business. To do so, your company relies on a very limited number of people, whose role boundaries are relatively fluid. This allows you to gain flexibility and to do as much as possible with as little as possible. This schema also applies to your technical referent: once architect, one “hands-on”, he will go through phases to tackle technical related matters. Your referent finds himself having to touch everything, but never 100%, since you can’t know everything, or do everything alone. Doesn’t the saying go “to go fast, go alone; to go far, go together”? This profile is therefore all-rounder, passionate more than experienced: it will allow you to go fast, even to take shortcuts, but it will work … for the MVP. The risk for this type of profile is to persist too long in this type of role. Indeed, he will certainly gain experience, but his expertise will be to always want to do everything, alone, and quickly. It will then become difficult for him to delegate or even manage. To the extreme, he will develop an aura of saviour/messiah within your company, and will monopolise speaking time (and reflection time) with your tacit and silent agreement.

The Stabilizer

Your MVP was launched a few months ago now, your business model is being refined, after a few turnarounds, and your situation is motivating the company and the product to grow. So it’s time to hire and to assess the situation. This step is often perceived as painful or risky, because it involves questioning everything that has been done so far. Why painful? Because no one is “wired” in the same way and, because of the personal commitment required to create an MVP, some will take these questions as a challenge to themselves. However, in order to stabilize the product, and to prepare its scalability, i.e. your ability to accelerate your business development and attack new markets, it is essential to know your strong points, on which you will rely, and your weak points, which you will correct. It is therefore necessary to treat everything in the same way and manage to motivate and structure your teams accordingly. On technical subjects, this will naturally be the role of the CTO. Structuring the team, from a human and managerial point of view, implementing adapted processes and methodologies, he will gradually nose up to become the orchestrator of the technique. Where the hacker was managing alone, the stabilizer will have to orchestrate to make sure to find the right balance between new features, patches, and stabilizations, these last two subjects having strong impacts on the morale of the teams, and thus the quality of their rendering. The risk of this type of profile is linked to the ambivalence between the technical aspect, since the team remains relatively small, and the time needed to structure the whole. In case of imbalance, he would then fall into one of the other two profiles, which would not be in adequacy with your company, and thus your need.

The Industrializer

Now that your company has made a place for itself on the market and is well known, your work continues: it is time to become the absolute reference and to project yourself to several versions/iterations of your product in advance, the famous long term vision. This is the moment when your company sets up its ComEx, when the teams are counted in several dozen and you want/need to add a 0 to the number of employees to realize your plan. Your CTO must then let go, officially at least, of the technique to focus on the strategy and how to get there. You are entering an era where the long-term technical orientation will merge with the vision of future technological developments mixed with the evolution of your market. Everything has to be formalized; the roadmap is then done over several years, where it was defined over a few months; the teams become specialized, needing to improve exchanges between teams and individuals, through human management, processes, … any useful tool for these purposes. Your CTO is therefore at work on strategy, competitive analysis, an in-depth work of your company to find the levers necessary for your commercial success. The risk of this profile is to be too disconnected from technology, to lose touch with technological advances and to be drowned in hypes. The direct consequence would be that the technical teams would no longer have faith in him, with all that this can have as an impact on their productivity but also on the pure realization of his strategy.

So?

Since these definitions are relatively fair, clear and, on paper, non-exclusive, where is the lack? These various articles have been written for “pure players”, i.e. editors of solutions that will be exclusively usable on the web, and where the role of CTO is relatively unique, and that it will be the same person who will manage your internal and external issues. This is a simple echo of a growing trend where some companies are no longer able to distinguish the roles and missions of each, with the direct consequence of having several CTOs in the same structure. I have had the opportunity to note this point several times recently with, for example, an agency that recruits a CTO for one of its clients, and who will have to work in pairs with the CTO in place, each sharing specific but related subjects. But then, what are these missions that require different titles?

The list is long but we could mention the management of your IS, especially if your company starts to develop on several different locations, the management of your R&D, especially with the diversification of technologies, the operational with the support of the customer, the product and its roadmap definition, … Of course, the boundaries are not watertight between these topics, especially depending on the size of your company, but for all that, titles exist to clearly mark the distinction: CTO, CIO, VP Engineering, VP Operations, VP Products, … At some point, your CTO will assume all these roles (the Hacker in this case), but the more you move towards a stabilizer, even an ndustrializer profile, the more he will need support. Depending on his profile, he will refer you to one or the other of these roles as a complement. So who has to do what in this story? Let’s focus on the 3 most technical roles: CTO, CIO and VP Engineering. As much as the difference may seem obvious between the last two, their proximity to the first one adds a significant blur. So let’s dig into their missions

VP Engineering

Simply put, he’s your R&D boss. As a former engineer who rose through the ranks, passing through lead developer and architect roles, he has also developed an ability to manage people. As an internal technical referent in your R&D, he is the person your company relies on to transform the defined strategy into a real product.

CIO

Do you have an internal IT or infrastructure to manage? The IOC is your boss on these matters. He is the face that everyone in your company knows when it comes to IT and related topics: security, cloud, automation, … At the crossroads of all the other professions in your company, even the non-technical ones, he will make sure that your IT teams guarantee the quality of service necessary for the proper functioning of your product and your company itself. Because of its positioning, it will often have a strong impact on your processes and methodology.

CTO

This is the technical face of your company. As a technical referent for the whole company, with priority given to business issues, it must stay up to date technically, so that it can respond to your customers and your board, while guiding product development. How is he not your VP Engineering? Because he has to be able to keep his hacker and hacking side to test and therefore stay up to date, where your VP Engineering has to move forward in accordance with your roadmap and little opportunity to play. How is he not your CIO? I will repeat the discussion I had with the CEO of a large transport group: what is your job and therefore on which technique will your CTO intervene?