What’s my Role as the CTO? The Different CTO Personas

In the previous post in this series, I discussed the three pillars of an executive role, including that of the CTO. In the shortest of summaries, these are the pillars:

1. The business value provided by the engineering organization.
2. Setting the direction within the engineering organization.
3. Holding and maintaining the engineering culture.

These three pillars of a CTO’s role largely remain unchanged, no matter where their focus lies. But on their own, they don’t provide enough clarity on what a CTO can and should do on a daily basis. In our conversations with CTOs, no matter whether they’ve been carrying the title for days or for years, many of them don’t really understand their role in a way that they can live every day. They don’t have a clear picture of what and how they contribute to the business. Shipping code is still the simplest answer at this stage and usually the most effective use of their time. But what happens beyond that, once the team starts to grow, once you’ve figured out that the business needs something different from you?

But there’s no single answer for what to do then. Many folks are inclined to keep going with what they know best, write code and be deeply involved in product and engineering decisions. It’s their comfort zone, what they know best. But what’s the alternative? What should a CTO focus on instead of code and technical or product decisions?

It’s usually for lack of an alternative vision that it’s easiest to just keep going. An additional problem here is that a CTO’s role doesn’t have a single, refined focus. Every role is different, depending on what the business needs and what the CTO wants to focus on. Worse, these priorities can change year over year, quarter over quarter. There’s a variety of areas one can focus on, almost like a set of personas.

Below we’re breaking down the personas that we’ve come across so far. The list is meant as a compass, as a guide, to help CTOs orient themselves in their roles and responsibilities. The personas can help avoid the feeling of being stuck in one specific persona, whether that’s based on outside expectations or just on what you think you should do. One CTO can carry multiple of these personas, with the caveat that the more of these you pick, the less quality time they’ll have for each. As much as we might want to focus on lots of different things, we’re still constrained by how much time we have in a given day or week.

More recently, the CPTO role has acknowledged that technical and product leadership and decision making can benefit from being steered by a single person. That said, while this individual has a lot of authority, they carry a lot of responsibility as well. With more responsibility comes an increased need for upwards accountability and downward expectations, e.g. to and from the CEO or the board.

Making these personas explicit is about making intentional choices about where you put your focus at any given time. More importantly, it provides clarity on where you don’t put your focus.

Choosing any one of these is not meant to be a permanent choice. It’s worth reassessing regularly whether you’re still wearing the right hat based on the business’s and your own needs.

The Architect

This CTO type is spending their time on the current and future architecture of the product’s underlying technology. They look at how individual parts interact and how they together form a well-working product that delivers on stability, performance, flexibility, and whatever else the business might need. They also look towards the future to shape the architecture and technology stack so that it can support new features, products, and levels of scale.

The Tech Lead

This type is involved in mapping out individual features and their technical implementation. They’re involved in discussing and decided what’s feasible, what needs to change in the technology to support a new feature, and in ensuring a smooth delivery.

The Product Person

The product-focused CTO is heavily involved in shaping the product, building product roadmaps, deciding on the future product strategy, and working across departments to get everyone on board with what’s happening. They care about the product and how it evolves and keep a close hand in shaping it. They talk to customers about their use of the product and to learn about unexpected or emerging customer needs.

The People Manager

The people manager is, you guessed it, responsible for the people in their department. This includes personal and professional growth, crafting roles and responsibilities, ensuring feedback is given regularly, having regular one-on-ones with their close reports (and skip-levels across the department) to ensure the overall health and well-being of the people working for them.

The Co-Founder

When you’ve co-founded a company, there’s a whole slew of responsibilities waiting for you. Keeping close relationships with your board, your investors, and your co-founders is key. So is picking up any task that remains when all else is delegated, whether that’s running payroll, assembling office furniture, or giving impromptu presentations at startup events.

The Process Designer

From delivery to decision making, from meeting structure to salary frameworks and career paths, from continuous delivery to code reviews, the process designer’s main aim is to bring clarity on how things get done, an essential role in any growing team.

The Customer Advocate

This CTO spends a lot of their time talking to customers, helping them understand what their products have to offer, understanding customers’s needs, even helping them transform their own business, e.g. towards digitalization. The customer advocate also represents these needs internally, telling the stories of what customers are currently up to, what challenges they have, and where the product could help.

The Coder

This CTO spends their time deep in code, working hands on to advance the product, build new features, fix bugs, reaping the benefits of immediate feedback whenever they ship code. This persona is a comfort zone for most engineers who have shifted into the CTO role. The instant gratification and the sheer joy of building, collaborating, and shipping are the hardest to shed, especially when most of the alternatives require much longer feedback loops, as is the case with any organizational changes and strategic choices. They also bring less interaction with the team, leaving a constant feeling of being out of the loop.

The caveat of this persona is that the coding role is the hardest to combine with most if not all of the others. When you pick other personas together with the coder, you quickly become a blocker for the rest of your team, as you won’t be able to put your focus on code all the time.

The Futurist

The eyes fixed on the horizon, but not to see what’s visible, but to try and guess what’s beyond, the futurist drafts, experiments, and prototypes their way towards the future. They’re building the next, next version of the product. They’ve got a well-oiled team taking care of what’s currently in progress, so they’re making educated guesses at what the technology and the product could look like one, two, three years from today.

The Strategist

Strategy is a fuzzy topic, oftentimes involving wild gestures in vague directions that may or may not offer something useful for a business to grow. The strategist works tirelessly to set a course through the fog of great unknowns, of which there are plenty in business and engineering, by way of a strategy. They talk to analysts, other CTOs, industry experts, customers, and all kinds of like-minded people to explore where trends might go, what technologies may (or will) emerge, and how those might influence not just their business, but the broader landscape they’re working in, all that information influencing where they steer their department in the next twelve to eighteen months.

The Evangelist

Talking at conferences, to the press, to analysts, are all part of this persona. Their main focus is keeping the business, its technology and product in the public eye. Goals may include hiring, funding, or garnering interest by customers or potential technology partners. This persona is on the road a lot and in a lot of meetings with folks whose eyeballs or contributions are valuable to the business.

The Sales Person

Especially when you’re selling technology as part of your product, or sell technology (think machine learning, infrastructure, or developer tools) to developers and non-tech folks alike, you may be involved in the sales process. Integrating your product requires deeper technical understanding of your customers’ stack, so you may be required to build up a joint understanding of the effort needed. Or you’re simply great at translating from the tech and engineering side to your customers’ needs.

The Platformer

You’re still working in code and infrastructure but with a focus on the developer experience. Automation tooling, build pipeline, deployment, infrastructure automation, to name a few areas. They’re important multipliers for your team. Shaving five minutes off the build pipeline may seem small. But when applied to your entire team, that compounds quickly. You may end up saving them and the business hours, days, even weeks of idle waiting time. Your team relies on your work, but you can stay off the critical path in terms of features, bugs, etc.

The Board Member

Being an active member of a company's board requires a different set of skills: presenting information in highly condensed form, translating engineering and development efforts in a way relatable and understandable by non-engineering folks, and maintaining active relationships with board members. The good news is that these skills benefit CTOs beyond the board, they’re a great help in interacting with other departments of a growing company.

---

Now that’s quite the list, isn’t it? The wide variety of CTO hats just shows how hard it is to define this role even in the broadest terms, let alone measure its success and contribution to the business.

The list above is meant as a compass, a framework to provide ideas on where typical focus points can lie for a CTO. We use a list like this to help our clients regularly assess their own role, where their focus is, and where it should be. Some quarters one hat is more prevalent than others, but that can always change. It’s this fact alone, that the key roles can and will be changing over time, that makes it easier for them to adjust to new realities. It’s easier to accept that they will need to wear a certain hat, but that it’s only temporary. Couple of months later, they get to put on a different one.

Tensions between Business and Personal Needs

What happens if the business still needs something from you but that doesn’t line up with what you want to do? Say you’re a CTO and would rather focus on the architecture side but not on people management. Or you would prefer to focus on shaping the product and talking to customers. Or you just want to keep writing code and not be bothered with anything related to direction or management. Well, you can hire someone to do these things instead.

But do keep in mind that there’s still a balance to be struck here. If what you want to do is so at odds with what the business needs, or you’re in a comfort zone that you don’t want to get out of, it can also be an opportunity to reflect on whether you’re still in the right role. There’s no shame in shedding what you definitely don’t want to do and move into a different role altogether, one that gives you only the things you really want to do, without having any expectations or responsibilities regarding the three columns. Which you’ll still have as long as you carry the title of a CTO. This isn’t the most pleasant part of the conversation. But as coaches, that’s not our place to be. Sometimes we push our clients to face a reality that they themselves don’t want to consider. Because it’s painful to leave something behind. It requires humility and personal growth to step aside. And sometimes the path that seems the most painful is the one worth taking.

Reflect: Are you finding yourself in any of these personas? If not, what other personas are you embodying in your role? What other hats are you wearing?

Assess: On a scale of 1 to 5, how much of a part of your work every week are the personas you’ve identified? Are there too many (e.g. more than five)? Are there any personas that take up a lot of your time and others that don’t get the attention that they deserve?

Do: Go through each of these and reflect on whether these personas really are important for the months ahead. If they are and you’re still wearing too many hats, which of these could you delegate? Which of these aren’t needed right now and could be shed, if only temporary?