How to Hire a Fractional CTO: the UK Guide

Six questions to ask, and what a strong answer sounds like

Every question here asks for something that happened, not something they believe. An operator who has genuinely held the seat answers from memory; one who has advised from the sidelines answers in the abstract, and the difference is audible within a minute.

1. Tell me about a rebuild you talked a company out of. What did you do instead?

Listen for: The strong answer weighs the rewrite in months and money, names what shipped instead, and shows some affection for unglamorous incremental work. Someone whose proudest story is a year-long rewrite is telling you what they will do to your codebase.

2. Walk me through the last engineer you hired. Where did they come from, what did the process actually test, and are they still there?

Listen for: You want a real pipeline, a work-sample or pairing exercise rather than puzzle questions, honesty about salary, and ideally someone who stayed. A vague answer about having a great network means the hiring, which is often the real work, will land back on you.

3. Our agency says the next feature is three months. How do you check whether that is true?

Listen for: Good answers involve reading the code, breaking the scope down, and asking for a demo cadence so slippage shows early. Taking estimates on trust is weak; assuming bad faith by reflex is a different kind of weak.

4. First week with our codebase: what do you look at, and what do you deliberately ignore?

Listen for: Listen for deployment pipeline, test coverage, security basics, and where the single points of failure are, with style debates and framework preferences explicitly parked. Wanting a full formal audit before offering any judgement suggests a consultant's pace, not an operator's.

5. When did you last choose the boring technology, and when did you last deliberately not?

Listen for: The right instinct is boring by default with one well-argued exception they can defend in business terms. A history of adopting whatever was newest, at someone else's expense, is common in this market and worth catching here.

6. What is your working policy on AI coding tools for a small team like ours?

Listen for: A considered answer is specific about where the tools speed a team up and where they generate review burden and unowned code, and includes how they would police it. Both the dismissive answer and the breathless one suggest they have not run a team with these tools in it recently.

Red flags

They recommend a rewrite before reading the code or asking what actually breaks the business today. The diagnosis arrived before the patient.
The first conversation is about their preferred stack rather than your product, your customers, and who maintains the system after they leave.
They cannot name an engineer they hired or grew who is still at a previous company. A trail of teams that dissolved on their exit means they were the system, and you will inherit the same dependency.
They angle to write the code themselves. A fractional CTO doing hands-on build at up to £1,400 a day is doing a £500-a-day contractor's work at the judgement rate, and the judgement work is not getting done.

What day ninety should look like

Agree these before they start, in writing, in the brief. A fractional engagement without a ninety-day marker drifts into a retainer nobody remembers the point of.

A written technical risk register: the three things most likely to hurt the business, each with a rough cost and either a scheduled fix or a deliberate, documented decision to accept it.
Visible delivery discipline: releases on a stated cadence, and an estimate for the roadmap item you care about with its assumptions written down, so you can hold someone to it.
The build question settled for your setup: either a hiring plan with a live candidate pipeline, or a documented review of the agency with scope and cost renegotiated. One of the two, done, not discussed.

When a fractional CTO is the wrong answer

There is no product yet and no engineers. What you need is people who write code, whether senior engineers or a good agency. A day a week of oversight with nothing to oversee is pure overhead.
You already have strong senior engineers and the real gap is deciding what to build. That is the product seat. Adding another technologist above good ones creates friction, not direction.
Production is failing daily: outages, data loss, customers leaving. That is a full-time interim engagement until the fire is out. Two days a week arrives on Tuesday to find Monday's decisions already made.

If one of those is you, say so in a brief anyway and we will tell you straight. Sometimes the honest answer is interim or full-time, and pointing that out costs us nothing because the operator never pays us either way.

What to put in the brief

Describe what exists: the stack, who builds now (agency or in-house, and how many), and the specific thing that hurts. A brief that just says need a CTO reads like a co-founder search, and experienced operators skip those.
State decision rights and days together: whether they can change suppliers, pause roadmap items and set the hiring bar, and how many days a week you expect. Architecture authority without roadmap authority is a brief good CTOs turn down.
The thing founders forget to say: whether you are quietly hoping this turns into a full-time or co-founder role, and whether equity is on the table. Operators can tell when a fractional brief is really a co-founder search, and the undisclosed version wastes everyone's time. If that is the hope, write it down.

How to hire a fractional CTO in the UK