What does a CTO do?

The last few years have been good to me, I’ve enjoyed giving advice to teams and companies and helping people get started with better ways of working, ways of working which usually go by the name of “agile” but the name is the least important thing. But…

I’ve been questioning if I want to keep doing this. Like most of us do from time to time I’ve wonder if I need new challenge, if I should join something big, more continuity and… as you might guess from my posts on Mimas I’ve kind of missed being closer to building something.

From time-to-time people have suggested I take on a CTO role - and certainly my ego likes the idea, it sounds important! - but, seriously, I think I’d like to give it a go. But that leads me to a question of my own:

Just what does a CTO do?

This is something I’ve pondered before because while I’ve met a good few CTOs in my time I can’t really see a consistent pattern to describe what they do. Everyone knows what a CFO does, they look after the money so a CTO should “look after” the technology but… how do you do that?

Before I come up with even more questions lets try some answers.

First up, lets be clear, not all CTOs are code-centric. I know organization where the primary role of the CTO is to understand the technology domain and code - software - is secondary. Take telecoms for example, the CTO in a telecoms company may actually be an expert in telecoms technology. Software may well be something someone else looks after, although the two need to work closely.

Such examples seem to becoming less and less common, perhaps that is just another example of software eating the world. CTOs are increasingly about the code…

Some CTOs are programmers, some CTOs are the only programmer.

This view seems common with non-technical entrepreneurs and in job-adverts for start-up companies. Maybe it is because these companies can’t afford to pay senior salaries that they hand out grand job titles instead. Or maybe it is because the founders really don’t understand technology and anyone who can code looks like a god to them.

I worry about these companies because the attributes which make the first “CTO” attractive (code god willing to work for peanuts and therefore young and mortgage free) are most definitely not the attributes you want a CTO as the company grows.

CTOs should most definitely be able to code - even if this was sometime in the past. And many CTOs I know, and have know, do continue to code. That is good when they are part of a team.

A CTO is also in part an architect role - and hence they should code from time to time. The CTO may well be the Chief Architect or Chief Engineer although such a role is more about building shared understanding not mandating plans.

And since software design is a copy of organizational design the CTO needs to understand Conway’s Law and organizational form and structure. Organizational architecture is as important as software architecture, they are symbiotic.

Some CTOs have a lot of say in organizational structure. Many CTOs run the technology development group - all the programmers and testers, and possibly analysts and project managers, report to the CTO. As such the CTO is the Chief Technology Manager.

But not all CTOs do this. Some CTOs are actually further down the organization. And some CTOs leave the running of the technology group to someone else - the Vice President of Engineering or Director of Development. Again the CTO may work closely with this person but the CTO fills more of an advisor or expert role rather than a management role.

Such expert CTOs may well be on the board, they may well have the ear of the CEO but they leave the day-to-day operation of development to someone else. And some don’t, some are deep in the detail.

Perhaps as more businesses become truly digital, and technology and business become truly one, then CTOs running development operations will become less common and CTOs as experts will become the norm.

CTOs need to keep their finger firmly on the pulse of technology - what is happening, whats new, what is taking off, what is going down, what are Apple planning? And Amazon? And Microsoft?

But actually understanding the latest technology may well be less important than understanding how that technology changes business, changes competition, changes organization and structure. Manager-CTOs may well put that understanding directly into action but Expert-CTOs will educate others in the organization, from new recruits all the way up to the board.

CTOs also have a role in recruitment and forming the development culture. If CTOs think quality is important the engineering staff will take quality seriously. And if the CTO says, like one I knew once, “I’d rather it was on time with bugs than late and working” then every engineer will know within about 5 minutes.

While CTOs may not interview every candidate for a role they will certainly interview some of the key roles. More importantly the CTOs needs to work as a cheer-leader for the companies recruitment campaigns. Finding good engineers is hard, a CTO who gives the company a profile and makes it a place people want to work will help a lot.

CTOs often have a role to play too in sales. They are wheeled out to meet potential customers, talk technology and show the company takes the client seriously. When a company is R&D heavy the CTO doesn’t do much pre-sales but then the company makes a living selling products or services to other companies CTO as pre-sales is very important.

And it is perhaps at the highest levels, the board, the other CxOs, that the CTO role is unique. Almost by definition each CxO (Chief something Officer) is a specialist in their own field: the CFO knows about finance and the CMO knows about marketing. Although the CEO should be more of a generalist they come from another function so once upon a time where specialists. The COO (operations) may be another exception although this is often post held by the soon-to-be-CEO so it is a training post. (In my experience, the CSO role (chief strategy officer), when it exists is used to sideline someone before helping them leave).

In the CTO the other CxOs have a peer they can talk about the technology implications for their business. It is here that the CTO has the opportunity to influence the rest of the company and help them maximise the benefit of technology.

The common theme in all of this is the CTO leads the thinking of others. To use a rather over-used, and perhaps equally vague term, the CTO is a thought leader around technology. The CTO helps others in the organization understand not so much the technology itself as the implications of technology for the business. (And that implies the CTO needs to be a good communicator.)

That of course is provided the CTO has those opportunities, that they are at meetings and senior meetings, if “CTO” is simply a grand title for a programmer then they have little influence.

Summary

• The title CTO should be reserved for roles which are more than just programming
• A CTO should be able to code
• A CTO should understand software architecture and will be one of the architects but probably not the only architect
• The CTO needs a firm understanding of Conway’s Law
• The CTO needs to understand organizational structure and play a role in designing the organization
• Some CTOs are technology experts while some or powerful managers with their own department
• CTOs need to keep abreast of the latest technology development
• The CTO may well be the most senior pre-sales consultant in the business
• More importantly the CTO need to understand the implications of technology and how business is changed by technology
• A CTO helps to guide other company executives in their use and understanding of technology
• Ultimately the CTO is a “thought leader” - they guide the thinking of others.

Given that it is pretty obvious that very few, if any, individuals can fill the role. Any CTO will inevitably be good at some things and not so good at others, as humans they will inevitably flawed.

And me?

Do I still want to be an CTO? - well yes but actually, I’m not concerned about the title, call me what you will - Chief Engineer is a title I’d love too - but what I’d love is a role which allows me span boundaries: as someone who understands technology, can code, can architect, knows how to align business with business structure and technology architecture; as someone who knows the importance of knowing what is being build will meet customer needs.

If you know of such a role I can always be tempted, until then, I’ll stick to consulting.