Sixteen years ago I asked whether companies really knew what they were getting when they advertised for "rock star programmers". It turns out the same question applies elsewhere in the org chart, it just took me a while to get there.
The question I never answered
When I left my last role as VP of Engineering, one of the team (followed by a few) asked me a question on the way out: "How do I become a CTO?"
I never answered it. There was a presentation I was meaning to give and didn't, and while regret isn't the right word for something that never happened, the question has been quietly following me around ever since.
The honest reason I didn't answer it straight away is that I couldn't. Not because the path is a secret, but because the question hides a bigger one underneath it: become what, exactly?
Over the years I've met CTOs who ran hundreds of engineers, CTOs who ran nobody, CTOs who could still commit code, and CTOs who I'm fairly sure couldn't explain what a load balancer does. All with the same three letters next to their name. Calling them all "CTO" is like saying every drink that isn't wine or spirits is beer, and that all beer is the same. It's obviously absurd, but it's exactly how the industry talks about the role.
So before anyone can answer "how do I become a CTO", we need to work out what the word even means. Helpfully, someone did the research.
What the research says
The canonical work here is Tom Berray and Raj Sampath's 2002 white paper, The Role of the CTO: Four Models for Success. It was built from three years of research and discussions with hundreds of CIOs and CTOs, and 24 years later it's still the paper everyone cites, including Werner Vogels, Amazon's CTO. I haven't found anything that has displaced it, tells you how little the industry has converged on a definition since.
Berray found four distinct models hiding under the one title:
The Infrastructure Manager runs the "line" side of IT: data centres, networks, operations, security. Usually reports to a CIO who keeps the strategy. Focused on keeping the machine running efficiently.
The Big Thinker evaluates how technology can create new business models and preempt competitors. Small elite team or works alone, operates through influence rather than control, and often has no direct say in the final decision.
The Technology Visionary and Operations Manager is the classic tech company CTO, often a co-founder. Sets the technology strategy and builds the organisation to deliver it. The noted failure mode: vision outrunning the organisation's capacity to absorb change.
The External-facing Technologist points outward, using technology to improve what customers actually receive. Common in consulting and product companies, part technologist, part spokesperson.
He then mapped these against two forces: how much business change the organisation is going through, and how much of the product is information rather than physical stuff.
It's a genuinely useful framework, and if you're hiring a CTO or trying to become one, it's the right first question: which of these does the company actually need?
But notice what it doesn't cover. Berray's axes describe what the organisation needs. They say nothing about the human who turns up. And two people can sit in exactly the same quadrant and be utterly different animals.
I know, because I met one.
A CTO I met during interviews
During a recent round of interviews I spent an hour with a CTO who left me reeling, and not in a good way. Two exchanges stuck.
First, he asked me how I lead. I gave the honest answer: mostly by context. I describe the outcomes we're after, ideally something measurable, then leave the team to come up with the way to achieve it and bring it back to me before we agree it together.
His response: "I never allow bottom-up strategy. There is no way that someone new to the industry or the company is going to know all the nuances or what can and can't be done."
The second was unprompted. "When I joined, everything was broken. They didn't even have real DR, I had to set that up for them." This about a large, profitable, long-established company.
My immediate reactions in the room were not printable. But later, I realised what had actually bothered me, and it wasn't personality. Personality is how someone behaves at dinner. What those two answers exposed was something deeper: his working theory of how organisations actually function.
Pull the two answers apart and they reveal two separate beliefs.
Where does intelligence live? "I never allow bottom-up strategy" is a claim that valid knowledge lives in one head: his. My answer is a claim that intelligence is distributed, and the leader's job is to set intent and constraints, then get out of the way. This is an old, well-studied divide. The military have argued about it for two centuries as mission command versus detailed command. McGregor approached a related divide through Theory X and Theory Y back in 1960. David Marquet built Turn the Ship Around on it. Ron Westrum's research on organisational cultures, later picked up by the DORA / Accelerate research, sorts organisations into pathological, bureaucratic and generative along much the same line.
With my systems hat on, it also looks like Ashby's Law of Requisite Variety: a controller needs enough variety in its responses to match the variety of the disturbances it must regulate. In a complex organisation, you either push decision rights out to where the information is, or you become the bottleneck and cap the whole organisation at the size of your own attention. "I never allow bottom-up strategy" is a man volunteering to be the cap.
Who is the hero of the story? "Everything was broken until I arrived" places him as the protagonist and everyone who came before as incompetent scenery. I can't verify the claim about DR, but I can observe the framing. A steward telling the same story says "the team had gaps in resilience, we built out DR together in my first year". Same facts, opposite theory of credit. And here's the trap: heroes need broken things. If your identity depends on rescuing, you have an incentive to find things broken, describe them as broken, or quietly keep them broken. Nobody else in the hero's story has an inner life or any prior competence, which if you've read my older posts, is the exact opposite of everything I believe about teams.
The missing axis
So on top of Berray's organisational quadrant, I'd offer a second one for the human being. This is a synthesis rather than one person's research: the horizontal axis comes from the mission command / Theory Y / Westrum line of work, the vertical from the hero versus steward distinction that turns up in leadership writing from Robert Greenleaf's servant leadership onwards.
One axis: where you believe intelligence lives, from one head to many heads. The other: where you place yourself in the story, from hero to steward.
Cross them and four animals fall out:
The Saviour (hero, one head). Everything was broken until they arrived. Strategy comes from the top because nobody else could possibly understand. My interviewer. The rock star, promoted.
The Bottleneck (steward, one head). Genuinely cares, gives credit generously, and still can't let a decision leave their desk. The benevolent micromanager. Lovely to work for right up until you need anything approved.
The Evangelist (hero, many heads). Says all the right things about empowerment, mostly on stage. Delegates the work but keeps the narrative. Great at conferences, thin behind the curtain.
The Gardener (steward, many heads). Sets context, grows capability, and is mostly invisible when things go well, because the team did it. The rock solid engineer, promoted.
If Rock Star vs Rock Solid was about individual contributors, this is the same coin at C-level, and my conclusion hasn't moved in sixteen years: a little from column A, a hell of a lot more from Solid.
One fairness note, because absolutes are exactly the disease I'm describing. Centralised command is sometimes right. In a genuine crisis, or in a heavily regulated domain, temporarily pulling decisions to the centre is legitimate and necessary. The tell in my interview wasn't the centralisation, it was the word "never". The failure isn't the mode, it's being welded to one mode regardless of context.
So, how do you become a CTO?
Which brings me back to the question from the virtual corridor, and I can finally answer it. Sort of.
The title is the easy part. Titles are cheap, and as we've established, this one barely means anything on its own. The real work is two acts of matching.
First, Berray's question: which quadrant is the company in, and which of the four models does it actually need? Getting this wrong is how visionaries end up miserable running infrastructure, and how infrastructure managers end up drowning in a startup.
Second, and this one comes first in practice: self awareness. Where do you naturally sit on the human quadrant? Not where you'd like to think you sit, where you actually go under pressure, because pressure is when the real answer shows up. Then the harder question: how far can you stretch toward another corner when the context demands it, and what does that stretch cost you? I can act more directive in a crisis, but holding it for months would burn me out, because it's a stretch, not home. Someone welded to the Saviour corner has the same problem in reverse, they just rarely admit it.
Know your home corner, know your stretch range, know the price of the stretch. That's the actual preparation for the job, and none of it appears in the job spec.
For what it's worth, I know where my home is. Forty-odd years of being hands on, and the times I've been proudest are the ones where I could barely point at what I did, because the team did it. Make of that what you will.
“When his work is done, his aim fulfilled, they will all say, ‘We did this ourselves.’”
~ Lao Tzu, Tao Te Ching, Chapter 17, trans. Witter Bynner