In short
Hiring a CTO starts with deciding what the role must own that nobody currently owns. Write that down as two or three outcomes for the next twelve to eighteen months, decide whether those outcomes need technical direction or delivery leadership, then assess against evidence of having done that specific thing at your stage — not against a title, a stack list or an impressive logo. A badly defined brief makes every later part of the search harder, which is why the definition is worth more effort than the sourcing.
Key facts
- Start with
- What the role owns that nobody owns today
- Assess for
- Evidence at your stage, not seniority in general
- Expensive mistake
- Hiring the title to reassure investors
- Cheapest correction
- Writing the outcomes down before the first call
First, do you actually need a CTO?
The question is not whether a CTO would be useful. It is what would change in the next year if one started on Monday. If the honest answer is "the founders would stop making technical decisions they are not qualified to make", that is a real reason. If it is "we would look more credible", you are buying a title and the market will price it accordingly.
Three situations genuinely call for the role. The technical direction is now a company bet — a platform choice, a security posture, a build-or-buy decision — and no founder can own it credibly. Or the engineering organisation has grown past the point where a founder can run it alongside everything else. Or you are selling to buyers who require a named technical owner and will ask to meet them.
Situations that often look like a CTO need and are not: you need code shipped faster, which is usually a delivery or capacity problem; you need one hard system built, which may be a principal engineer; you need someone to manage five engineers, which is a first engineering manager.
CTO, Head of Engineering, VP Engineering, fractional
A short orientation so the brief names the right role. The choice between the first two is a decision in its own right and has its own guide.
| Shape | Owns | Usually fits when |
|---|---|---|
| CTO | Technical direction, architecture bets, the external technical voice | Direction is a company-level risk and no founder can own it |
| Head of Engineering | Delivery, people, predictability | The work is understood and shipping it reliably is the problem |
| VP Engineering | The delivery organisation at larger scale, managers as well as engineers | There are already managers to manage |
| Fractional or interim CTO | Direction-setting for a defined period, often part-time | The decisions are urgent but the permanent scope is not yet clear |
Titles are not standardised across companies. Define the scope in writing and treat the title as packaging.
Write the outcomes before you write the advert
A CTO brief that lists technologies will attract people who match technologies. Write instead the two or three things that must be true in twelve to eighteen months and that are not true now. "A platform a team of fifteen can work in without blocking each other." "A security posture that survives enterprise procurement." "A technical plan the board can be held to."
Then write the constraints honestly: the stage, the current state of the codebase, what is held together with tape, the size and shape of the team, the runway, and what the founders will not hand over. Candidates worth hiring will probe exactly these, and a brief that hides them simply moves the discovery to week three of their employment.
A search process that holds up
A four-stage structure covers the main evidence without turning the process into an endurance test. Each stage below exists to test something the others cannot.
Founder conversation
Both ways. You describe the company honestly, including the parts that are broken; they describe what they would want to understand in the first month. What you are listening for is whether their questions are about the business or only about the technology.
Technical depth, on your actual problem
Not a whiteboard puzzle. Put a real decision in front of them — a migration you are weighing, a scaling constraint, an architecture you suspect is wrong — and work through it together. You are assessing judgement under incomplete information, which is the job.
Leadership evidence
How they have built, structured and lost teams. Ask for a specific person they hired who did not work out and what they did about it. A vague answer here is worth probing: someone who has genuinely managed people has a specific story and usually a lesson from it.
Board and commercial exposure
If the role carries the external technical voice, test it. Have them explain a technical risk to whoever on your side is least technical, and watch whether the explanation survives contact.
A scorecard you can actually use
Four dimensions, each scored on evidence rather than impression, each owned by a named stage. Agree what a weak score means before you start, because the pressure to rationalise arrives with the candidate you like.
| Dimension | Evidence that satisfies it | Tested at |
|---|---|---|
| Technical judgement at your stage | A decision they made with less information than they wanted, and what it cost | Technical depth |
| Direction-setting | A plan they set that others followed, and how they handled being wrong about part of it | Founder conversation |
| Building a team | People they hired, how they structured the team, and a hire that failed | Leadership evidence |
| Communicating risk | A technical risk explained to a non-technical audience who then acted on it | Board and commercial |
Score each dimension separately and compare notes only after everyone has written theirs down. Shared scoring before independent scoring produces one person's opinion with four signatures.
Mistakes that cost a year
All of these are recoverable. None of them is cheap.
- Hiring a title to signal seniority to investors, then discovering nobody has defined the job.
- Assessing a startup CTO against a large-company CTO's experience, which is a different role with a different failure mode.
- Letting the founders stay in the technical decisions after promising they would not.
- Running eight interview stages and losing the two strongest candidates to companies that ran three.
- Treating the stack as the requirement when the real requirement is judgement in an unfamiliar domain.
- Skipping the uncomfortable conversation about what the founders will not hand over, and leaving a boundary to be discovered in the job.
References and diligence worth doing
Take references from people who reported to them, not only from people they reported to. A specific question tends to produce a specific answer: what did the team find hard about working for this person? Anyone who has led a team has something to say to that, and a reference who claims there was nothing is not telling you much.
If the role carries architecture authority, ask to talk to an engineer who disagreed with one of their decisions. How that disagreement was handled tells you more about the next two years than any technical interview.
The first ninety days, agreed in advance
Write down before the offer what the first ninety days are for, and agree it with them. Make it understanding the system and the team, forming a view, and coming back with a plan — not shipping a reorganisation in week two.
Agree how you will both know it is going well. A CTO who cannot tell whether they are succeeding will optimise for visible activity, and visible activity is not the same as the outcomes you wrote down.
When an interim or fractional route makes sense
If the technical decisions are urgent but the permanent scope is genuinely unclear, a fractional or interim CTO buys you the decisions without committing to a shape you cannot yet describe. It also surfaces what the permanent role should be, which is worth something on its own.
It is a weaker fit where the role needs to build and hold a team, or to be the durable external technical voice. Both of those ask for presence and continuity, which is the thing a part-time arrangement is least able to give.
Common questions
- Should a startup's first technical leader be a CTO or something else?
- It depends on whether the gap is direction or delivery. If the technical direction is a company-level bet nobody can own, that is a CTO. If the work is understood and shipping it reliably is the problem, a Head of Engineering or a first engineering manager is often the better fit, and the brief is easier to write.
- How many interview stages should a CTO search have?
- Four stages will usually carry the evidence you need: founder conversation, technical depth on a real problem, leadership evidence, and board or commercial exposure. Add stages only where you can name what each one tests, because every extra round is time in which a candidate with other options can accept one.
- What should a CTO be assessed on that an engineer is not?
- Judgement under incomplete information, direction-setting that others followed, building and sometimes losing a team, and explaining technical risk to people who will act on it. Depth still matters, but depth alone describes a principal engineer.
- Can a founder stay as CTO while hiring a technical leader?
- Yes, and it can work well — but write the split down. Decide which decisions move and which do not before the search starts, because a boundary discovered in the job is a much harder conversation than one agreed before the offer.
- Do you publish CTO salary or equity benchmarks?
- No. We have no sourced UK figures for startup CTO pay or equity at a given stage, and an invented benchmark is exactly the number a founder would act on. We will talk about a specific role and a specific market; we will not publish a range we cannot stand behind.
Turn this into a brief
Answer six short questions and you have a usable technical hiring brief you can keep improving, print or share internally.
Open the hiring brief builderAny percentages or figures shown in this article are illustrative examples used to explain the model. They are not quoted rates, market benchmarks or salary data.