CTO — Role and responsibilities

Introduction

The role of a CTO changes when the company grows. In the first months of this year, I have spent most of my time in the Growth Engineering (GE) team and have been heading up the infrastructure team. Now that we have a Product manager and a team lead for the GE team, and someone onboarded on the infrastructure side. I’d like to evaluate where I could add the most value to the company.

This quora answer is surprisingly applicable to our history and current situation. To my understanding, we are currently in:

Phase Three — Growth
With a stable platform and team structure in place, the ability to add new functionality and products comes into focus, and the CTO needs to set a product strategy in place, possibly separating the engineers into separate product teams, with one or more Product Managers. The focus shifts even more to leadership and culture, and the CTO may make a move away from the day-to-day, tactical oversight, bringing in a VP of Engineering or Head of Development to take over, so they can retain a strategic view.

And in about 6–18 months, we’ll move towards…

Phase Four — Domination
As the business starts to hit its stride, the CTO becomes most involved in thought leadership, culture building and talent attraction, and the role becomes all the more outward facing. Their primary duty is to ensure the business uses technology to retain competitive advantage, and that the right people are in place to ensure that happens. In this phase, the business may also acquire other businesses, or be acquired, and the CTO is responsible for ensuring that happens effectively and without disruption.

The question now becomes: Which responsibilities remain with the CTO, which get added and which are removed?

Responsibilities

I envision taking on the following 4 responsibilities, listed below in order of importance, and with a rough estimate for how much time I expect these to take:

1. Architectural decisions (30% of time)
2. Building MVPs (30% of time)
3. Technical evangelism (20% of time)
4. Recruiting (20% of time)

Responsibility 1 — Architectural Decisions

As the engineering team grows, and more microservices are created, it becomes increasingly more difficult to understand how they work together. The engineering subteams (Growth, Learn, Teach engineering, etc.) are all responsible for multiple microservices, that need to interact with services from other teams. Someone needs to make sure that these microservices are interacting in a way that represents the vision of all PMs and teams:

• Data architecture:
  What if a microservice stores data that’s relevant for many other microservices?
• How microservices interact:
  The goal is to decrease coupling between microservices. When a microservice goes down, the impact it has on the rest of the architecture should be as small as possible.
• Align with the future vision of the feature:
  How loosely coupled certain services are depends on the future vision for some of these services.
• Performance of different microservices:
  If a team wants to track 100s of millions of records, it needs to scale. That expertise may not always be available .
• Input on language / framework for new features:
  Technology choices have a significant impact on recruiting, performance of the applications, etc. so feedback/guidance from a high-level should be provided.
• Promote knowledge sharing between teams and limit overlap (in collaboration with the VP of Engineering.

Responsibility 2 — Building MVPs

In order to be able to make good architectural decisions, it’s important that the CTO has a good understanding of the latest technologies. The best way of learning is by doing ;-). The goal is to investigate the viability of new projects / features / products that could have a huge impact on our business. The deliverable is an MVP, combined with a plan on how the MVP can be turned into a full application.

Responsibility 3 — Technical evangelism

The biggest challenge we have faced so far is hiring. Yet, we have not managed to come up with a scalable solution. Right now, it takes us months to hire 10 really good software engineers. That sets a bottleneck on our growth as a team. How can we make this scale?

Most really great developers don’t go to job fairs (often), and already have a job they love.

Great developers, to my understanding, want to stay up-to-speed with what’s going on in the space and are intrinsically motivated to learn about new things. The best places for this are meetups and conferences.

Why do people want to work for Heroku, Netflix, Zalando, Google, Facebook? Their products aren’t that different from their competitors, yet they seem to attract a huge amount of applicants. I believe that one of the reasons is due to the perception that they are working on super cool problems. Just reading Netflix’s tech blog, or Facebook’s engineering blog makes you want to apply for a job.

The ultimate goal is to have a self-reinforcing system where:

We hire great developers working on cool projects -> We can talk about these at conferences / write about them on blogs -> Attract more great developers and improve the ones working for us -> Close the loop. If we provide the support so that our engineers can become authorities in their domain (rails, react, etc), everyone wins.

Giving awesome talks at conferences is not only fun, we’ll attract the interest of devs attending. Even if they are not looking for a job right away, when the time comes that they are looking for alternatives, DataCamp has to be the among the first names that come to mind. A more scalable alternative to conferences/meetups are webinars and podcasts (check e.g. this list of podcasts).

I believe that the only way this can be done is by creating an engineering culture that promotes working on open-source projects, speaking at conferences and meetups, and writing about technical challenges we overcame. In my opinion this can only work if I focus a lot more time and effort on technical evangelism.

Responsibility 4 — Recruiting

I think the focus for the CTO should be on the Technical evangelism when it comes to recruiting longer term. Making sure there are as many great applicants as possible applying for our positions is something that works at scale. In the next 6–12 months, it also makes sense to keep the CTO as one of the final checks on technical ability in the recruiting funnel.