My job title has had CTO in it for around ten years now.

By now, I have a pretty clear picture of what a CTO should be all about, what makes you a successful CTO, and what doesn’t.

Still, even now, I find that the role of CTO is one of the most misunderstood roles in tech.

For a part, this might have to do with the rise of the so-called “startup-CTO”, a role name that seems to have been introduced by VCs, and is actually more of a tech lead for early startups.

Let’s try and clear things up a bit, by answering the 5 questions I get the most about the role.

1️⃣ What is the CTO’s Primary Job?

💡 Short answer:

“The CTO’s primary job is to make sure the company’s technology strategy serves its business strategy” — Eric Ries.

📖 Long answer:

Clearly, Chief Technology Officer is a business role, albeit at the crossroads where business and tech meet.

This is an important one, so let’s do a thorough analysis of what specific business and tech goals the CTO should pursue:

Business goals

1. Alignment of business & tech strategy, by being the communication bridge between business and tech.
2. Cost efficiency increase, by looking beyond hype cycles, a few years ahead, with TCO in mind.
3. Turnover reduction, by creating and nurturing a tech culture in which everyone thrives. Although you might counter that this is the responsibility of line managers, on closer look, what makes people leave might range from getting a better offer to frustration with legacy, technical debt, lack of vision, etc. This is where a good CTO can slowly take necessary actions that the team values, where they might have felt unheard or overruled before.
4. Building up IP/value. A CTO should always keep value growth in mind. This will then lead to better build-or-buy decisions, intelligent outsourcing tactics (you don’t build up IP if you outsource everything tech).
5. Find the 80/20: continuously balancing what the business needs and what costs tech most efforts to create an optimal outcome for the company.

Technology Goals

1. Be ultimately responsible for Technology decision making, including architectural design, patterns, build-or-buy, etc.
2. Improve technology, development process, tooling, infrastructure
3. Create and sustain an innovation culture; staying on top of emerging technologies that could be of value to the organization
4. Assisting in Tech Recruitment
5. Total Cost of Ownership (TCO) Management
6. Software governance: compliance, security, tech debt control, etc.

2️⃣ Can a CTO be an Operational Manager?

💡 Short answer: no

📖 Long answer:

It’s important to note that the CTO role is 100% strategic.

Looking at the goals above, you can clearly see that none of the tasks could be fulfilled from within an operational position: You can’t see the forest for the trees.

As a CTO, you don’t work in the box, because your task is to examine the box and make it better.

Engineering managers, and even Heads of Engineering, are operational leaders. As a CTO, you might come up with stuff you want to improve that literally conflicts with their operational goals. This is perfectly normal, because as a CTO, you’re observing from an outside position, looking at what could be better. The friction caused by these conflicting positions is natural and should lead to healthy discussions.

Now you also know why a CTO cannot also take operational management tasks: conflict of interest.

3️⃣ Does a CTO Code?

💡 Short answer: yes, but only PoCs and prototypes.

📖 Long answer:

Normally, a CTO doesn’t develop software. Instead, the CTO develops the strategy in which software development can thrive.

Obviously, technology leaders should have their roots in technology. In fact, having been in senior+ roles as software engineer & architect gives you a tremendous advantage as a CTO:

• It helps you relate to developers, because you speak their language.
• It allows you to still read their code, show best practices, challenge them on actual code.
• It allows you to quickly build Proof-of-Concepts (PoCs) and prototypes to show the direction of travel when implementing new technologies or services

So, if, after all, a CTO can sometimes code (and is probably still good at it), why should the CTO not work on production code?

You want an answer? I’ll give you five:

1. Operational responsibilities conflict with strategic ones. We’ve seen that one. Operation always wins because of commercial pressure. So if, as a CTO, you actively work on code, this will inevitably come at the cost of having to neglect strategic responsibilities.
2. The “flow” most seniors feel when being deep into coding, is counterproductive to strategic thinking. It absorbs a high percentage of your brain capacity, at the cost of losing track of time and interest in other stuff. Relationships have stranded because of it. Good strategic decision making, out-of-the-box thinking, putting things in perspective, these are all things that don’t happen when we’re “in the flow”.
3. It’s an unhealthy situation to be a C-level leader and a peer to developers at the same time, due to conflicts of interest for instance.
4. Dotting the i’s is extremely expensive for a CTO to do, the reality being that the last 10% of your software efforts accounts for 90% of development time.
5. It’s a much more sustainable growth strategy to empower development teams using your own skills and experience, than to keep doing production yourself.

4️⃣ Can a Software Engineer Grow into the CTO Role?

💡 Short answer: yes, but be prepared for a dramatic switch.

📖 Long answer:

For one, I personally don’t think developers/architects can easily grow into a CTO role at the same company. This has less to do with their growth potential than with team dynamics, especially in smaller companies. More than once have I seen undesired outcomes after ‘one of the guys’ got promoted and suddenly got more responsibility. People are people, so what can I say…

From my personal experience, it is crucial for CTOs to no longer be part of the operational side. Senior devs are extremely important in the pressure cooker of software production, so the gap left behind is big, both for the company and for the person in question. I personally know people who weren’t ready for the shift at the time they were promoted.

Net result: everybody unhappy!

Again, from my experience, it’s better to make the switch starting at a new company (or as a consultant).

A CTO is a strategic business role. Having a business perspective, as a C-level, is very different from being entrenched in dev. As a dev, this is not something you automatically get taught.

Also, there’s so much stuff a CTO needs to be aware of (and is responsible for) that many developers find boring: ISO certifications, GDPR legislation, wage subsidizing, security, Cloud TCO, etc.

Be careful what you wish for….

5️⃣ Do Startups really Need a CTO?

💡 Short answer: yes, but not full time & permanent

📖 Long answer:

The pitfall of many startups is that they get sucked into operational focus. The whole modus operandi of startups is ad-hoc and opportunistic, and there’s nearly always a lack of seniority in tech and on strategy.

It would help them to have an experienced CTO. Someone who’s built SaaS products multiple times, who knows Native Cloud practices, who’s built teams and optimized software development processes, etc.

And someone who looks at strategy, beyond the next deliverable.

There are two big issues however:

1. Budget: startups mostly don’t have the money to be able to afford an experienced C-level, and giving away equity to reduce spending isn’t the right bait until there’s proven value. Net result: permanent CTOs are seldom affordable, even for later stage startups.
2. Scarcity: experienced CTOs are among the hardest people to find. Ask any recruiter/headhunter who’s tried.

Is was only a matter of time before these very real issues lead to the emergence of a part-time consultancy role: seasoned CTOs who’ve seen the inside of a many startups and scaleups and help startups and scaleups on a consultancy basis.

Some people will say you should never hire an external consultant to be your CTO.

I hear them. I’m very much aware of what it means to have what some people say is the second most important role in startups (after the CEO) be a consultant. Plus, you want to have someone 100% invested in the company.

I can’t of course speak on behalf of all CTO consultants, but I have a set of rules I have found really helpful in providing my services:

1. I make it very explicit that I’m a temporary gap filler.
2. I encourage learning from what I do, showing what a CTO does,
3. I always try to help people see the higher perspective, help the business understand tech, and help tech understanding business.
4. I digitally record every step, so the inevitable handover includes a full log of what I’ve done, and for what reason.
5. I normally don’t accept a mandate. This means that I specifically have to get buy-in across the board on every decision I make. Takes more time, but pays off in the sense of transparency (and stimulates learning)
6. When needed, I help in recruiting a permanent CTO. Most of the times, being a half-insider by then, I know what type of CTO fits best.

This article was first published on LinkedIn.

A Dutch version of this article has been published on Emerce.nl