What does a CTO even do?

Ever hear the whispers in the tech hallway: “What does a CTO even do?” It’s a surprisingly common question, shrouded in a bit of mystery. This story aims to illuminate the role of the CTO and its interplay with other key players like VP R&D, architects, and the wider organizational puzzle.

Everything I am saying here is an accumulation of perspectives I gathered over the years, and is how I view this role and its relation to others.

First, how does someone get to that role?

In a young startup, the CTO might be the lone tech pioneer, coding the first lines or if they won’t code, they will hire the first engineer or manage the external team of developers if there is one. This — is not a CTO. It’s just a title that shows the intention of the company/board to make this person the leading technological executive. But as the team expands, the role evolves.

Here are two drawings that show the point I will be discussing here.

In this first one, the connection between Process Orientation and Technological Knowledge for various roles is presented.

In this chart, the Product (VP, PM…) is very much aware of the process but has little technological knowledge. The Team-Lead has some process orientation and technological knowledge as she manages teams. Engineers are scattered along these axis (have some process orientation, less than their team-lead and their technological knowledge varies yet is expected to be higher than the VP for instance). VP, Architect and CTO are discussed later.

The second one shows the focus each role has on the current or future work:

The VP R&D is mostly concerned on the current quarter’s objectives and plans the next. The Architect intervenes on the work done in the current quarter but has their main focus on the next quarter and beyond. The CTO is mostly focused on the next quarter and the future endeavors of the company.

VP R&D

Enter the VP R&D, a maestro of daily operations, orchestrating sprints, assigning tasks, and ensuring deliverables land on time and with quality. They’re the process guru, navigating the intricacies of “now” to keep the machine humming and are focused on the current quarter.
Their “tomorrow morning” is literally, tomorrow morning.

Architect

Meanwhile, the architect sculpts the technological foundation, ensuring its stability and adaptability to future evolutions. They champion guidelines, explore new technologies through proof-of-concept (PoC) experiments, and optimize costs.
Note, that this individual has high technological knowledge, but is somewhat unaware and mostly doesn’t really care about the current sprint or the current quarter. Their gaze often transcends the current quarter, peering into the next one, laying the groundwork for a resilient tomorrow. Their awareness or orientation towards the “process” or methodologies used in this area is limited, and while it depends on the individual they can somewhat discard most of it.

CTO

As these two positions get filled (VP R&D and Architect) it seems like the CTO doesn’t have much to do, right?
So, where does the CTO fit in? Picture them as the captain, charting the course and aligning technology with the company’s broader vision and strategy. They contemplate challenges, both near and far, ensuring tech decisions made today won’t capsize the future. They’re the outward face of technological prowess, representing the company to the world (as opposed to VP or Architect that are mostly working inward).
They are somewhat aware of the process, and they still have technological knowledge but they are less concerned with the day-to-day aspects of the sprints and current quarter (as opposed to VP R&D) or the most up-to-date hype and details of certain technologies (as opposed to the Architect).

As the organization gets bigger more roles are presented — Architects tend to be more focused on one product, a Chief Architect (or “Enterprise Architect”) might then be added to oversee and orchestrate the “inter-product” architectural aspects and the lines get even more blurry between the CTO and that role, but at that point that really depends on the individuals, the enterprise, the higher-management team and its methodologies.

Organizational chart

It’s obvious that the CTO is reporting to the CEO. But does the VP R&D report to the CTO? How about the Architect?
There are tons of organizational charts, depending on company size, number of products, verticals, the customers, whether it’s a SaaS product or something else. We can’t go over all of them here, but typically you’ll see one of these, or a variant deriving from them.

There are a lot of different models and I am not suggesting one is better than the other. One might be more suitable for the specific case and the individuals in the company.

Model #1 — A highly technical product — CTO is also taking care of product

When the product is highly technical (for developers for instance) this model might make sense. Product and R&D all report to the CTO. Architects may be “floating” alongside the R&D and managed by the CTO “office” or by the R&D department itself.

Model #2 — CTO is about strategy and someone else takes care of execution

As the CTO is more focused on strategy and less on deliverables, it might make sense to let the R&D and product report to a joint manager (CEO/CPO), while the CTO takes care of strategy building, future innovation and so on. Architects once again, may sometimes be under the CTO or managed by the R&D (mostly depends where they are needed the most)

Model #3 — Various products, CTO also manages the “core” infrastructure

In this model the company has several “sub-companies” or products each delivering on its own goals, pace and roadmap. The CTO takes care of aligning the strategy between all, sometimes even takes care of the Core components that are shared by all products. The architects may work for a certain product (in such case they “belong” to that manager) or take care of the “company-wide” architecture, standards and future work. In both cases the architects could be professionally guided by the CTO, even if they are not directly manage by her.

The VP R&D reports to the CTO while the VP Product reports to … CEO? CPO? CSO?

Consider this — if an issue arises between product and R&D, who do they come to? If the R&D is reporting to the CTO and product reports to someone else it might create a problem as they don’t have a mutual manager to go to that can help resolve the issue. Furthermore, in that scenario, as the CTO is less focused on the day-to-day, it has less context to help out.
So in my opinion either both VPs report to the CTO (if it’s a product for developers for instance, it might make sense) or both report to the CEO (or another individual such as the CPO that can and should handle both).

That makes the CTO an “external” resource to the R&D, more of a compass to lead the company’s technology, and less as a direct manager of the day-to-day.

Does the CTO manage the Architects?

It can, and sometimes it should. Anyway, in my view the CTO should at least be the professional focal point for the architects even if they don’t manage them directly. Weekly meetings to discuss technological advances, PoCs, challenges ahead, lessons learned and making sure they are all aligned so the stack and technological aspects of processes make sense (like tools that are used).

Conclusion

The CTO, along with their fellow technology maestros, plays a vital role in orchestrating a company’s technological symphony, ensuring every note rings true and propels the organization towards a successful future.

Credit where credit’s due: This blog post I read a few years back uses the first chart seen here. I disagree with some of the takes and my experience differs from it. But the model holds and it’s a great read anyhow. So thanks Rob Sharp for the idea!