The Problems of the CTO Role

This made me think a little about things I’ve not talked about for a long time, but think I want to say:

I know a few things about being a CTO: I ran a consultancy doing “CTO for hire” stuff for half a decade (it eventually failed, dramatically, and quickly), and have taken the seat full-time a few times.

If you have your eye on that role for yourself one day, or you’re looking to hire somebody into that role, I want to explain why the role is broken and suggest some advice.

What does a CTO do all day?

When I ask this question of engineers — particularly those with more experience in smaller companies — they imagine a sort of “super Tech Lead”: a very senior engineer who is going to lead the technical direction of an organisation.

Tasks I have undertaken in various roles include:

• Working with commercial stakeholders (CEO, board, investors), to identify the commercial roadmap over ‘x’ months.
• Working with product owners and business analysts to develop a realistic product roadmap that supports the commercial roadmap.
• Identifying a tech roadmap aligned with product and commercial roadmaps.
• Negotiate when you realise the commercial or product roadmaps are unrealistic because of technical constraints. Note: negotiate, not “tell others it can’t be done”. Negotiation skills are critical.
• Figure out how to structure teams, line reporting, process and cadence within the technical team.
• Get the balance between feature development, BAU and technical debt/bug quashing right for the commercial and product culture within the firm (no, in most firms, you don’t get to insist all bugs are fixed as a top priority every time).
• Keeping up to date with changes in law that have impact on technical roadmaps.
• Preparation and negotiation of budgets to be spent on tech staff — salary budgets often have to be treated differently to others.
• Preparation and negotiation of budgets around technical operations such as hardware, service fees (data centre, cloud, etc.), software licensing, patent licensing where appropriate, etc.
• Validating all of the above with senior management and board members, mostly using the language they are most fluent in: finance. You will spend a lot of time building spreadsheets and slide decks, and you’ll ideally need to do basic interpretation of a balance sheet to keep up.
• Communicating the above with shareholders and future investors whilst giving yourself enough margin to not get fired if it doesn’t pan out.
• Setting cultural tone for the technical team. All of the below contribute to that, but ultimately you are going to set the example. The kind of behaviour you choose to reward is what the team will eventually value.
• Explaining all of the above with technical staff using non-financial language. For example you might say to the board “we’re moving from a CAPEX model to an OPEX model over 18-24 months”, but explain the same project to the technical team as “we’re decommissioning all of the data centre kit and moving to cloud services over the next 12–18 months”. (Note the sneaky deadline shift to set expecations: you’ll need do that a lot until you build trust in your team and your board)
• Making sure as little as possible is impeding technical staff from executing on all of the above. You could just shout at people to get things done, but culturally most people seem to agree trusting people and making sure nothing gets in their way works best. I learned this from Joel.
• Recruitment of senior technical staff. This is one of the most time-consuming and hardest parts of the job, but if you get it right, the rest of this becomes easier.
• Management, mentoring and support for senior technical staff.
• Pay reviews, share option management, etc. which is politically contentious and hard to get right from a consistency point of view.
• Firing technical staff who need firing. You just need to get it done. Remember on this point a piece of management advice I was once given and still live by: judge somebody by their motivations, not by the actions that you’re finding fault with. Try not to fire people for poor outcomes if their motivation was sound, mentor them instead.
• Providing a consistent story with others on controversial decisions, and acting as a unified team.
• Making sure your team are recognised for the good things, when things go well.
• Making sure you own and are fully accountable for the bad things when things don’t go well. I’ve offered my resignation multiple times in my career, not always for mistakes I made myself. If you’re not brave enough to do that, don’t go into management: you’ll be hated by the remainders of your team after you throw some of them under the bus, and your management career will be over.

Notice, there isn’t much engineering going on here. Depending on what’s going on within your company, it’s unlikely you’re going to be spending too much time working on product, and it’s worth expanding on that:

In very small companies, you are going to have to work on the product directly. In larger companies you won’t have time to work on the product directly.

In my last CTO gig I used to “joke”: we’re large enough that I don’t have time to work on code, but small enough that I have to, hence me being tired all the time.

The different types of CTO

It’s worth pointing out at this point there are different kinds of CTO even with all of the above responsibilities.

I broadly call them “operational management” types, and “technical leadership” types. Their backgrounds — and therefore what they can offer in the role — are very distinct.

I once went to a soiree for CTOs organised by a management consultancy. We met in an exclusive hotel in central London, did some networking and had a rather fine dinner provided by the consultancy. After dessert they opened a “round table discussion” so they could listen to what was on our minds as “leading technology managers”. This was market research for them, but the food and wine was excellent, so why not partake?

Some of you may be surprised at one fact I found interesting: I was one of only two CTOs in that room of 20+ that had ever learned how to write code.

The other person with an engineering background whispered it to me, lest it be overheard and he was thought a geek by the others. I seemed to be the only one present who confidently and proudly exerted a technical background.

The others definitely thought an engineering background was odd. Why on Earth would you want to learn to code if you were going to be a CTO?

Some of you reading this right now might be a little taken aback: aren’t all CTOs engineers who moved up?

Some CTOs I’ve worked with once did some code dabbling at some point (“I did some COBOL once”), decided it wasn’t for them and looked for management roles and then jumped over.

More have come from a project management or operations background, taken to understanding technology quite well and found themselves leading a technical team in a larger organisation.

These are the operational management types: they’ve probably studied finance, project management, operations, mentoring and other skills engineers would consider the “soft stuff” around technology, and left the engineering specifics to others they trust.

I would say this model is the norm for CTOs working in larger firms that need technical product development functions, but which would not be considered primarily a technology company. Retailers, utility service providers, banks, government departments, etc.

The good news if you’re an engineer wanting to get to CTO is that it’s definitely not the only route, and there are many, many engineering types out there in the CTO role. They are more likely to offer strong “technical leadership” rather than operational management.

Technical leadership is more about leading by example. It’s about being the person the senior engineers go to when they’re not sure how best to solve a problem, and you being able to work it through with them in a way that gives them confidence it’s the best technical solution.

Not all firms need this. Some can make do with a manager who brushes such problems away with a “well, I’m sure you’ll figure it out”. But when technical leadership is needed, failure to provide it can cause a company to fail.

Where technical leadership seems to work best in my experience is in a “pure” technology firm: the main product is a piece of technology, typically either software or component sold in a B2B context, or in the consumer space they are selling something that you would go to the “technology” section of a store to find.

CTOs in these sorts of companies tend to be good engineers who understand the product in its entirety, but also are empathic and have skills in management and leadership.

These two Worlds overlap, of course. Service providers are increasingly being driven by the technology within them, and technology firms are increasingly being driven by the need to take a wider more holistic view of their market proposition.

My first tech job was at an ISP. My first CTO knew his way around a unix command line, could write code in a bunch of languages and could normalise a schema into 3NF intuitively.

That ISP was bought out, merged with half a dozen more, and grew considerably. The company that emerged is now one of the largest ISPs in Europe and a year or two back I watched an interview with their CTO where it was clear they knew very little about the intricacies of engineering. That’s an ISP — the archetypal tech firm of the 1990s — that is now clearly in the service provider/operations mould.

And this is an important point: the kind of CTO needed in an organisation might well change over time. That means either you change with the role, or you become a nomad: moving from one outfit to another of similar size. There’s more scope for the latter model for good engineers wanted at smaller firms where tech leadership is more valued.

How it’s all broken

In summary, then:

1. The job title might mean different things in different companies, and might carry different responsibilities
2. Most engineers don’t understand how little engineering there is in the role even in very small companies without a core technical proposition, and might lack the skills needed to do operational management well
3. Most non-engineers who do it, don’t understand engineering well enough to really understand what’s going on in the team on a day to day basis, and might lack the skills needed to do technical leadership well
4. What is required of the role changes dramatically over time as the company evolves in size and function
5. If you get it wrong, you need to probably resign. You might not be able to get another gig easily, because not all firms have CTOs, and those that do might need something very different to what you can offer because of #1 above
6. As a final cherry on the cake, it’s rarely as well paid as other C-suite roles, and if you don’t get the finance stuff down pat, you won’t have as much influence as others either

I’m therefore not convinced it’s contractor rates causing the disruption for this role: people are learning all the above either through observation or experience. If you’re a senior thinking about it, it’s more likely today that you have a colleague who has made the jump and regretted it, than it was 10 years ago.

In short: it’s a broken job title that people have sussed out, and therefore people who could do it, don’t want to as it carries too much downside.

What does that leave us with? Quite often people who shouldn’t be doing it either because they’re underqualified on the management skills (they’re engineers going into a team that doesn’t want/need an engineer as CTO), or they’re underqualified on the engineering skills (they’re ops background people who are being asked to lead a team that needs technical leadership, not operational management).

One possible fix is the emergence of roles that sound like CTO but aren’t: director of engineering, VP of engineering, technical director, etc. are all roles I’ve seen/heard bandied around and often in orgs with a CTO as well. These roles all mean different things in different companies, but I hope in time that the roles and definitions settle down.

I’ve seen setups where a CTO has done board-facing work and a technical director has been responsible for tech-team facing work, but it’s not worked because both had management backgrounds and had no interest or idea about technical leadership. I honestly believe this is because nobody else in management understood the skills needed to do technical leadership well.

Getting this right is hard, but might well be the difference between succeeding and failing as a business over the next decade.

Advice for hiring a CTO

If you’re looking to hire a CTO, think carefully about the skills and background you need.

If your team needs tech leadership, hire a senior engineer and give them time and space around the non-technical stuff. Support and mentor them, and be explicit at the outset that you think they need that and you want to provide it. Make sure you follow through.

If your team needs operational management, hire somebody with an operations background, make them hire a Director of Engineering and make it clear the responsibilities are split.

Advice for becoming a CTO

Think carefully about what you want from the role, and what sort of CTO you want to be. You might prefer a Director of Engineering role, or even just a Tech Lead in a larger firm.

It is unlikely you will get it all right the first time. Make sure you ask for and get the support you feel you need in your first role to do it well. Be prepared for the fact that it’s going to be exhausting and frustrating at times, but when it goes right you’re going to be able to feel pride in your team and colleagues.

Finally: know the difference between leadership and management, and learn when to apply each well.

Good luck, and godspeed.