A good friend recently wrote to me to ask what it takes to become a CTO in this day and age. Unfortunately, he DM’d me over Twitter: try as I might, there was nothing of note I could squeeze into that format (usual adage of “if I’d had the time, it would have been briefer”). So, I wrote this largely for him, but I think it’s generally useful.
Steps to becoming a CTO
What is a CTO?
More than ever, this is a nebulous job title. So our first stop has to be answering this question - what makes a CTO, and what differentiates the role from other C-suite roles?
I think a business without a CTO is making a statement, largely implicitly, that technology is not a strategic concern for them. This is fine for some businesses; it’s unlikely a top-class restaurant (for example) will ever benefit significantly by adding a CTO to their ranks when a commis-web-developer is good enough. But most businesses these days ought to have one.
The role of the CTO is to enable a business (or other organization) to make progress on its strategic goals through the exploitation of technology. Some CTOs may be extremely R&D-focussed, and may have a deep scientific background. Other CTOs may be largely managerial and oriented around creating high-performing teams. How the CTO does the role will be highly contextual, and vary across organizations - but the outputs will be extremely similar.
Progress on strategic goals?
In order to work out what this means, we need a working definition of the term “strategy” plus some way to measure progress against it.
I talk at some length about strategy in my book on Wardley Mapping, and I like this definition due to Mintzberg and Waters (1985):
“Strategy is a pattern in a stream of decisions”
A strategy may be implicit or explicit. If I’m constantly choosing the cheapest solution on the market, then I have a cost-reduction/limitation strategy, even if I don’t realise it. Even if I’m going with “gut feel”, some strategy is operating - but it will be a reflection of my experiences and biases, rather than something I can describe.
“Having a strategy”, therefore, means that there are a set of criteria that affect decisions. If a goal for my organization is to sell twice as many widgets next year, building the capacity to handle that increase in sales is going to be a key criteria.
If my current systems are at breaking point and even adding a load of extra hardware won’t get my capacity up far enough, then I may well adopt a strategy that involves complete replacement of that system. Tactics that I could bring into play here might be to migrate to some later version of the same system, migrate to a competitor, or even put in place processes which mean I don’t need such a system at all.
With a “complete replacement” strategy in play, I’m unlikely to decide to upgrade the current system at all - that decision makes no sense. Strategy, at the end of the day, allows you to reach decisions more quickly and soundly, because you can judge the choices against the clear outcomes you’re seeking to achieve.
What about progress?
The CTO is a member of a team: sometimes called the C-suite, senior management or just “top management”. The difference between this team and any other team in the organization is that this team sets the goals for the entire organization, and is entirely responsible for the day-to-day running of the organization.
Progress against goals may be quite a simple affair, then. Have we sold as much as we wanted to this quarter? Are we likely to meet our goals for future sales? Are we retaining enough of our existing customer base? Top management are jointly and severally responsible for all these things.
As a role, the CTO tends to be quite forward-looking, though. They are not concerned (technically) with whether the business has enough cash to operate (that’s the CFO), or whether general service delivery is working properly (that’s the COO). The CTO’s accountability begins to kick in properly with the arrival of new capability within the organization.
1: Know your stakeholders
Any CTO will tend to have approximately the same set of core stakeholders:
- their line manager (often the CEO, not always though)
- the board of the business
- their immediate team
- the overall technical “department” / section of the business
- the rest of the business
- their customers
And there will be obligations to the past and future members of these sets, as well as the current. The concerns of all these groups are very different, the types of communication needed for each are different, and a CTO often has to move from one group to another swiftly.
One difficulty of being a CTO is that there is often more tension between the concerns of these different groups than you would expect. Just to name a few examples:
- a board often cares about the six-month to eighteen-month timeframe, and will want to see regular progress against goals that will impact the near future - but many CEOs are often focussed on the here-and-now.
- technical staff are often highly paid and operating in a competitive market. Other staff in the organization will wonder why their terms and conditions are so much better, either in pay or other benefits (such as remote working).
- new customers will often be interested in the delivery of new features and up-coming/promised work; current customers are often more interested in bugs being fixed.
- hiring new staff is easier when you can attract them with the latest technology, or methodology - but working with cutting edge technology is often much less productive and leads to issues, which can affect delivery for customers.
The job of a CTO is, if nothing else, the continued adjustment of the various factors within an organisation that lead to balance between these various competing tensions.
2: Know your market
All businesses operate in some kind of market; most organizations operate within an environment which is very similar. Having a broad awareness of what other people are doing, and why, is hugely important. Without knowing the market well, it’s difficult to attain that forward-looking vision which is critical to the successful decision making that good strategy relies on.
A common mistake for CTOs who have come up through the ranks of development is to be mostly focussed on operational aspects of that previous role. I don’t discount that knowledge at all, but the step up to C-suite specifically involves leaving most of that behind: knowing the operational aspects is the “How?", but the CTO’s job primarily is to give answers to the “What/Where?” questions (in much the same vein, Top Management are there to answer “Why?").
Key things to understand about the market include:
- how big is it, who are the players, and how to people make money in it? Although simply stated, this is actually quite hard to define, and it’s not unusual for a business not be generally clear internally about this.
- how mature is it? Most markets are operating at a specific stage of maturity, and knowing how to navigate a small strongly-growing sector is very different to understanding a shrinking market for legacy product.
- what are the products or services that are likely to enter the market in the next three to five years?
This last question is particularly crucial. The word “disruptive” gets used a lot and there are a few different definitions; the one I would use here is that a disruptive product is one no-one saw coming three-to-five years before its arrival and that went on to be a top #5 product within three years. It’s very rare that a new disruptive product emerges - they are the “unknown unknowns” of the market - so don’t spend much time worrying about them, but it’s important to be aware of the direction competitors are taking.
3: Know your strengths and weaknesses
Obviously I could mean this personally, but I largely don’t (at this stage). It’s important to know what is strong and weak about your product or service, about your technology choices behind the scenes, and about the people around you (and those in your department specifically).
Strengths and weaknesses are often relative terms: what is a strength in one context may well be a weakness in another. For example, a well-designed application which requires little development or support may be a strength right up until the point you need to change it fundamentally, at which point it might become a liability.
It can be useful to enumerate these various strengths and weaknesses. Large organisations can deploy resources rapidly if they choose (whether that’s money, people, or other things), but getting them to that point of decision might be quite time-consuming, or they might stop projects quickly if they don’t achieve results quickly. Strength and weakness.
In many ways, it’s a job a lot like a sports coach. You’re often given the squad of players, and while you might be able to transfer some in and out it’s fundamentally your job to identify the strengths within the team and allow them to play to those strengths.
4: Train (yourself and others)
The CTO role is a learning role. In order to succeed, you have to be able to continually learn - but having that “stuff” stuck in your head is of no use to anyone. Demonstrating you can apply that learning is important, but being able to transfer that learning is essential.
So as well as those various crucial communication skills for the different types of stakeholder, an ability to teach is also pretty critical, and that’s more than just a communication skill: that’s fundamentally about your grasp of material as well as your ability to convey it.
Parents will children will know how difficult this can be in practice. “Why is the sky blue, mummy?"-type questions can be exciting to answer, at least at first. But then you get “Why can’t I fly?", all the way along to “Why are there hedgehogs?", and it quickly descends to a level of philosophy which is very difficult to engage in.
“It just is” is perhaps the worst answer a CTO can give to a member of their team when trying to answer a question.
5: Know the technology
Seems weird this is last, right? Well, I’m kind of assuming this is a given, and since most CTOs are operating in quite different areas, there is no one-size-fits-all here.
I did a piece of analysis last year which looked at the various pieces of knowledge that I used to do my job on a day-to-day basis, and came up with a list of about 100 keywords: everything from compliance issues like HIPAA or GDPR through to specific technologies or approaches, like REST. There is an enormous breadth of different areas you need to be reasonably conversant in.
A bunch of these will be common across a large set of CTOs. These days, most CTOs are involved with software one way or another, as businesses are becoming increasingly digital. That doesn’t mean you need to be able to code per se (although that clearly helps), and even if you can it doesn’t need to be in the language(s) your business uses (although again, that clearly helps). Understanding that, increasingly, processes and capabilities within businesses are being defined by and written into software is crucial, though.
There is little “right” or “wrong” about technology. Just off the top of my head, here are a series of technical choices:
- vi or emacs
- systemd or sysv init
- MacOS or Windows 10
- Chrome or Firefox
- Event sourcing or RDBMS
- Functions or classes
- Mutability or immutability
Each one of these choices has caused large arguments in the past, to the point of vitriol on both sides. There are lots of war stories on either side about how terrible the other is. Very occasionally I’ve written about choices which I think are often wrong and why (see posts on CQRS passim). However, the sun still rises, the world keeps turning.
It doesn’t necessarily matter what technologies you use (within reason), but what does matter is your personal mastery and the mastery of the team around you: a common failure mode is for a team to rewrite a legacy application in the latest/greatest framework (that they have no experience of) and make a dog’s breakfast of it. That says nothing about the quality of the team or the framework, but of the quality of the decision to allow them to proceed in that combination.
The more technically proficient you are, the easier the job can be. But the true skill is not the knowledge of the thing, but the knowledge of how to gain the knowledge of the thing - the meta-knowledge.
When you hear a term you don’t know, or want to learn how something works, what do you do? You could go to the library. You could tap up an expert in your network. You could ask a member of your team to explain it. There are lots of options, but the key is to have a pretty decent ground-game here such that you’re able to access definitive information on a subject.
I feel like I’ve barely scratched the surface, yet this is clearly a lot longer a post than I was ever going to fit into a series of tweets.
Unfortunately it’s true: I have barely scratched the surface. There are a bunch of very specific skills I think a CTO should have; everything from the basic competencies in draughtsmanship and graphic design through to the ability to read a contract. But that will have to wait for another day.
As usual, hit me up on Twitter to disagree with any of the above!