CTO stands for Chief Technology Officer: the most senior technology role in a company, on the executive team, owning where the technology goes and what it costs to get there.
That definition is accurate and close to useless, which is the problem with the question. I’ve done fractional CTO work in more than 35 companies, and the job in a 12-person startup and the job in a 400-engineer organisation share a title and not much else. So the useful answer is not what a CTO is. It’s which of the four jobs the title currently means.
What does a CTO do
Four versions of the role, sorted by the size of the engineering org. Most disappointment about a CTO hire comes from a company buying one version and needing another.
The founding CTO, up to about 10 engineers. Writes code, most weeks. Picks the stack, and will live with that choice for a decade. Hires the first engineers personally. There is no engineering process to speak of, and inventing one this early usually slows the company down as opposed to helping it. The risk here is the CTO who keeps this version of the job after the company has outgrown it.
The builder, roughly 10 to 40 engineers. Stops writing production features and starts building the machine that writes them: the first real hiring loop, the first performance conversations, the first architecture too big for one person to hold in their head. This is where most founding CTOs either learn to delegate or get quietly moved sideways to a Chief Architect title.
From my experiences this is the hardest transition in the role, and the failure mode is consistent enough to name. The CTO keeps the parts of the old job they were best at, which is usually the hard technical problems, and delegates the parts they’re worst at, which is usually hiring and performance. That sounds like sensible delegation and it is exactly backwards. The hard technical problems are the ones a strong senior engineer can now take, and they grow from taking them. Hiring and performance at 30 people are the things only the CTO can set the standard for, because the first ten hires made under a delegated bar become the interviewers for the next thirty. Get that order wrong for two quarters and the org is still recoverable. Get it wrong for two years and you’re not fixing a process, you’re replacing a layer of people who were hired to a bar no one defended.
The organiser, roughly 40 to 150 engineers. Now there are managers, and a manager of managers, and the CTO’s day is budget, headcount planning, platform bets, and the board deck. The technical decisions that reach them are the expensive ones: build or buy, which of three teams owns the shared service, whether the migration everyone is dreading happens this year or next.
The executive, 150 and up. The job is mostly other executives. Technology strategy against commercial strategy, vendor negotiations, sometimes M&A diligence, sometimes the regulator. A VP of Engineering owns delivery, and the CTO owns direction and the outside world.
Companies get into trouble by writing the fourth job description and hiring for it while they have 25 engineers, or by keeping a brilliant founding CTO in the seat through all four stages and wondering why delivery keeps slipping at 60 people.
Is a CTO higher than a CEO?
No. The CEO runs the company; the CTO is one of the C-level roles reporting to them.
The confusion comes from founding teams, where a technical co-founder holds the CTO title and an equal share of the company. There the reporting line is a formality and the shareholding is the real structure. In a company the founders no longer control, the line means what it says.
What a CTO earns
I’m going to decline the average, because a single number here is a bad answer to a fair question. The bottom of the range is a technical co-founder taking below-market cash for equity in a company that might not exist in three years. The top is an executive at a scale-up with a package built mostly of long-term incentives. Averaging those tells you about the sample, not about the job.
The number I can source, and the one companies find more useful when they’re deciding what the seat is worth: a fractional CTO in Europe runs €1,000 to €2,000 a day. That’s the market price of the role bought by the day, and it’s a cleaner signal than a salary survey because few companies pay a day rate out of habit. If a company balks at the bottom of that range for two days a month, what they usually need isn’t a CTO.
The other thing worth saying about CTO pay: the step from VP of Engineering to CTO is often a smaller raise than people expect, and the compensation moves to instruments with a longer clock. Base grows modestly. Equity, bonus tied to company performance, and a vesting schedule measured in years do the rest. Which means the honest reason to take the job is that you want the decisions, because the money arrives slowly and conditionally.
How hard is it to become a CTO, and is it stressful?
The technical half is the half most candidates already have. What stops people is the commercial half: reading a P&L, holding a budget argument against a sales leader who is better at it than you are, and explaining why a two-year platform investment matters to people who do not read code.
The stress is a specific shape too, and it isn’t the technology. It’s owing an answer on delivery for work done by people three layers below you, and making calls that stay wrong for years when they’re wrong. A bad architecture decision at senior-engineer level costs a sprint. At CTO level it can cost a roadmap.
If you’re weighing the route, the two adjacent titles are worth understanding before you aim: a VP of Engineering owns delivery where the CTO owns direction, and in product-led companies the CTPO merges the technology and product halves into one seat. The decision between those tracks is one of the more common conversations in my mentoring sessions.
Which version of the role your company needs is a question about its size and its next two years, as opposed to a question about the candidate. Most CTO searches I see start at the wrong end of that.