Who is a CTO?
One of the pleasures of writing this newsletter is that I get to converse with my readers. Either they comment on my posts and we get into spirited discussion, or I get asked interesting questions. Last week a colleague and friend of mine forwarded me a post, The CTO's Silent Struggle and asked me about my opinion. I read the post, replied and it led to a discussion which I'll share here with you.
The post is about a CTO who's complaining that nobody listens to him (specially his CEO). He's in constant conflict with the product team. He feels he's always right and he has to always justify things to people who have no clue about technology and they’re asking silly things of him.
The article then provides advice to this (hypothetical) CTO.
One piece of advice is to listen better to your colleagues within the C-suite.
Sadly, listening on its own changes nothing.
CTOs at the C-level meetings or conversations should never talk technology. Nobody cares. Your CFO is not talking about the latest marvels of accounting. Likewise, your CMO doesn’t go on about the trends in book coloring. It is fully expected that they are fully versed in their profession and will use their top-notch skills to advance the business.
Based on my experience, at that level you have to understand every other C-level function. You have to be able to discuss strategy with your CEO. You need to be able to talk about financials with the CFO. The same goes for marketing, product, sales, legal. And don't forget customer support and operations. Technology is here to deliver based on their needs.
The CTO is at fault for not creating a framework with clearly defined inputs, which are required for his team to then deliver on it.
(If you want to know what that framework looks like, you can start simple with this Rosetta Stone for CTOs: Feature – Benefit – Value.)
As an example - let’s say a product team comes to the company’s CTO and says that they want to implement a new feature.
An inexperienced CTO would tell them that it is a stupid idea, it doesn't make sense and it is a waste of everyone's time and effort.
An experienced CTO would respond to any request with 'of course'. This way, you are not seen as an obstructionist but as a team player.
However, your initial 'of course' is followed by questions:
How does that fit into our strategy
Where is it on our roadmap
What is the expected revenue derived from this new feature
How does that affect our market position
... and so on.
You start asking them questions in their language that draw on their subject matter expertise. Then you validate their answers with your own data.
Let’s take this example further. The product team says “50% of our customers will buy.”
The CTO says “Great, show me in your CRM which customers you are talking about. Where is the market research supporting it?” You never tell them that from a technology or CTO point of view it doesn't make sense.
In this way, the CTO forces the product team to convince the CTO that everything aligns.
As a CTO, you can't do that without understanding their language and their line of business. By the way, it is also entirely possible (despite what you think) that they will be correct in what they want to do. The intent isn’t to obstruct, but to do what is best for the business. When all the data is in, you have a solid business case on which your team can execute.
Let’s say that data doesn’t really favor their case, but they keep insisting on proceeding with their plan. Now the CTO can ask them to go over a list of projects currently worked on or in the pipeline. The CTO can then ask them, “which one should we drop in favor of the new request?”
Again, it should be the business which can/should decide on priorities for the business or product. Your role as a CTO to identify any dependencies. That's why you need to establish a structured process when any request starts with proper business analysis. What is the required level of detail? It is proportional to the expected build effort. You are not going to spend 1 month on something which requires a few days of actual effort.
Then, once tech requirements are defined, you will have an accurate estimate for required resources, which then business can decide if they are willing to spend the money on.
After that, your colleagues will see you not as an obstructionist but as a partner where they have to be well prepared to have a conversation. The 'it would be nice to have this' approach won't cut it anymore.
This is who the CTO should be. The question: “What does a CTO do?” has a simple answer. The CTO aligns the technology with the business strategy. That's how the CTO delivers lasting, recurrent value.
I thank Adam for his question and am looking forward to hearing from all of you. Make your question be the recurrent pattern.