It is widely accepted that the team that starts a company is rarely the same team that scales it to a large or public entity. Yet in practice this transition is often treated as an unexpected anomaly at each step, causing internal tension and conflict that can be a major distraction to the company to say the least.
What happens when the “hacker” CTO who built the v1 of a product is now needed to manage hundreds or thousands of engineers? They either get layered or pushed aside, or have leverage and stay in their role but hinder the company’s growth — all of which cause internal strife and inefficiency. Yet, the “growth CTO” may lack the hacker mentality which is required for subsequent product innovation.
If you subscribe to the 3 horizons model, you will probably agree that both of these CTOs are crucial to the company’s future growth, since no company ever exists in a single homogenous stage of the maturity curve.
Segmenting roles by functional area is ubiquitous in today’s business - CTO, COO, CMO, CSO, and so forth, but segmenting roles by maturity stage is almost unheard of.
I have been thinking about this recently, and one of the ideas that comes to mind is formally versioning or staging roles. In software systems, it’s very common to use multiple versions of a software package or ML model simultaneously, so perhaps companies, too, can benefit from a “CTO 1.0” and “CTO 2.0”, or an “Horizon 1 CTO” and a “Horizon 2 CTO” or a “Pre PM-fit” and a “Post PM-fit” CTO, working alongside each other, which is proactively and explicitly reflected in their titles and responsibilities, rather than a reactive change once the gap between their skills and talents and the company’s needs arises.