Part-time CTO UK: what changes at 10 to 50 people

Your lead developer wants six weeks and a change of database. Nobody on your payroll can tell you whether that is the right call, so the decision turns on trust rather than engineering. At 10 to 50 people a part-time CTO in the UK is not a smaller version of the full-time one.

At this size the shortage is almost never hours. In the businesses I get called into, the team ships. What is missing is a decision layer above it: someone who can say whether the senior developer’s call was right, whether the delivery date is real, and which of this year’s technical commitments the business will regret.

That work is measured in decisions, not days. It is why part-time is the right size, and why hiring the full-time version too early buys supervision rather than judgement.

What a part-time CTO in the UK does at 10 to 50 people

The starting position is nothing like a startup’s. There is a team. There are paying customers with expectations written into contracts, and a lead carrying the technical calls alone. What the CTO seat covers barely changes with headcount; how much of it is arbitration does.

Someone else can now be wrong on your behalf, at a cost that surfaces a quarter later. Technical decisions now arrive with a customer attached. And you are the only reference point for whether any of it is good, so you calibrate against yourself.

What changes when you already have a team

Here you are buying calibration rather than capacity: a second opinion that outranks the only opinion you have.

The pain never arrives as a technical complaint. A large customer’s supplier assurance pack lands, Cyber Essentials Plus and a data-processing schedule attached, and answering it stops delivery. A lender asks who owns the code and what happens if your lead leaves next month. Then a release slips a fortnight on a shrug about complexity.

What sets those off is headcount, customer load, an auditor, a lender, or the contract too big to lose.

Your diary is the cheapest evidence. Count the technical decisions that reached you last month, then mark the ones you were qualified to make. That gap is the seat you are trying to specify. Beneath it sits how to tell whether your software team is performing.

What your senior developer can and cannot decide

Give your senior developer more credit than most owners do: implementation, sequencing inside a sprint, tooling within budget, code quality standards, and the daily calls that should never reach you. Leave all of it with them.

Some calls sit outside the role, structurally, whoever holds it. The trade between technical work and commercial commitments belongs to whoever carries the P&L. So does their own performance calibration, and the hiring bar for whoever replaces them, because nobody grades their own homework.

A reversal lands differently coming from someone who did not write the plan. Your lead can change their mind; they cannot be the independent check on their own judgement.

None of this grades the person. It describes where they sit. A lead with nobody above them technically is being asked to be their own second opinion, and the role does not come with one.

When this person recommends something expensive, who in the business can disagree on the merits? If the answer is nobody, the recommendation stopped being a recommendation some time ago.

What stays on the owner’s desk

A part-time seat does not take the business off you. Decline one that offers to. Ship in six weeks with known limitations, or twelve weeks without them: the seat sizes both and says which it would pick. You decide, because you face the customer afterwards.

Hiring stays yours. I write the brief, run the loop, and give you a read on candidates that no CV carries. The engagement is designed to leave a hiring process and an onboarding checklist behind it, so a new engineer’s first week goes on shipping instead of archaeology. Who joins is still your signature.

Board and lender conversations follow the same rule: whoever holds the seat prepares the answer and sits in the room; you stay accountable. What leaves your desk is arbitration, calibration, and the technical questions that routed to you by default. In the engagements I run, the first month is mostly subtraction from the owner’s desk, not addition to the roadmap.

How is a part-time seat sized?

In practice it looks like a standing slot with the lead, a written read each month, and a phone answered when a decision cannot wait. Cadence follows the decisions, not a day count.

The seat is written to resize. It starts beside the existing lead, calibrating the calls and absorbing the arbitration. When the team needs its next person, the same seat runs the hiring loop. Once the function holds its shape, it drops to a monthly read for the board or the largest customer. One seat, resized twice, without renegotiating the engagement.

When part-time is the wrong size

When technical calls arrive every day and the team is big enough that supervising it is the job, hire full-time. A part-time seat stretched across a team that needs someone present every morning becomes the thing everyone waits on.

With no engineering function yet, part-time oversight of nothing is the wrong purchase. Someone has to design it, hire into it, and run it until it stands up. That is a build, not a decision layer.

When somebody inside already gives you a calibrated, independent read you trust, a seat above them gives you two answers to arbitrate instead of one to act on. Quarterly decisions need something lighter: a standing read for the board or the lender. Cost is not what separates these cases, though what fractional technical leadership costs in the UK is worth knowing before you size the brief.

You are not choosing between part-time and full-time. You are deciding whether to specify a technical seat at all and how big, which starts with which of the four things sold as a CTO consultant you actually need. That specification gets written from the blind spot that made it necessary. Every month it waits, you arbitrate decisions you cannot calibrate, and the team makes the rest without you.

So put the read before the hire. If your diary count is short and someone already argues with your lead on the merits, you have your answer and do not need me. When both come back ambiguous, the reading is the work.

My first pass maps the function before proposing changes: who decides what, what the lead can and cannot sign off, and which decisions reach your desk that should have stopped a level below. Two weeks is enough to draw that map. Years in the chair leave it undrawn, because you are one of the things on it. That is the Technical/Strategic Review, and how the first two weeks work sets out the sequence.

Book the exploratory call while the brief is still yours to write. We go through what your function needs, and what would have to change before you can specify that seat.