• fractional-cto
  • consultancy
  • engineering-leadership

CTO consultant: four things sold under one label

6 min readSimon Piscitelli
CTO consultant, four buys under one label: a paint tin opened on a dust sheet, the colour nothing like the lid swatch.

Three proposals on the desk, all three headed CTO consultant, no two describing the same work. One offers a monthly call, one offers to hold the technical seat, the third offers four developers starting Monday.

A CTO consultant is not one purchase. Four things are sold under that label: advice for you or your board, someone who holds the CTO seat and makes the calls, someone who builds and runs the engineering function, and a team that writes software to a specification. They are scoped and staffed differently, and they fail differently. Work out which of the four you need before you compare people.

What is a CTO consultant, and what are you actually buying?

You are buying one of four things, and the label will not tell you which. The term stays wide because wide sells. A seller who defines it narrows the enquiries that reach him, so the definition falls to you, the one paying for the imprecision.

Job titles are a separate question: consultant, advisor, NED and fractional CTO, side by side settles those. What is left is the buy.

The four things sold under this label

Advice. Judgement on a decision or a board-level question, with no operating role. Right when the decision is real and execution is owned inside. It fails when the decision turns out to be a stream: advice arrives monthly, the business decides weekly.

The seat. Someone accountable for the technical calls and their consequences, part-time, inside the leadership team. That is what the CTO seat actually covers day to day. Right when decisions arrive continuously and nobody inside can arbitrate them. It fails when the calls were already good and what was missing was hands.

The department. Hiring, structure, practices and the running of the engineering function, up to standing one up from nothing. Right when there is no function yet, or the one that exists has no shape: nobody owns it, nobody can tell a good week from a bad one. It fails when it is bought as a document instead of the running of it.

Delivery. People who write software against a specification someone else has validated. Right when the judgement already sits inside the business and what is short is capacity. It fails when nobody senior validated the specification, and you have bought speed in an unexamined direction.

Those four are not a menu I read from. My engagements have run as the seat and as the build, sometimes both in one quarter.

One product I built solo, while the founder stayed in front of customers. On another I wrote code beside the team already there, not reviewing it from outside. On a third the job was the sales calls. That is where the roadmap was being decided.

How do you tell which one your problem needs?

What decision is waiting? Put it in one sentence. Rebuild or refactor. Whether the team delivers at the rate the spend implies. If it will not fit in a sentence, that is your first finding.

Who is accountable for it in six months? Not who recommends it. Who carries it when it goes wrong.

Does anyone inside the business have the standing to overrule the answer? If yes, you are buying an input. If no, you are buying a seat.

If you sit on the board rather than run the business, run the three questions against the executive’s answer, not your own. The buy is nearly always advice, worth most when it reports to the directors and nobody else.

One signal to catch in yourself: if the brief you keep repeating is “send us a developer for three months”, you are buying capacity. Nothing wrong with that. Buying it under a leadership label is what makes it disappoint.

It runs the other way too. If one real decision a month is all of it, buy an hour a month and keep the rest.

What buying the wrong one costs

Advice bought when the seat was needed produces a good document and a decision still yours to make alone. The seat bought when delivery was needed produces expensive supervision of work already specified.

Delivery bought when judgement was missing is the costly one. It produces a codebase built at speed on assumptions nobody examined, and the cost lands a year later as a rebuild proposal nobody can defend on the merits.

Cutting technical spend while output rises is what I build an engagement to do, and a mismatched purchase is where that saving goes. Buy the wrong one and you fund more of it.

Each time, the engagement gets blamed on the person hired. The person was usually fine, the purchase was not.

Hiring a CTO consultant in the UK: what changes

Much of what search returns was written for another market. In the UK the default shape is contracting. A rate, a defined term, an employment-status question in the contract.

That paperwork should not decide the purchase, though it often does: all four run through the contractor process you already have.

Supply is the other local fact. One operator can only sell the modes one person can hold, so your diagnosis comes shaped by what that person delivers: the advice comes back with nobody to carry it out, or the building starts with nobody who questioned the brief. Neither is dishonest. The diagnosis still arrives pre-filtered.

Ask any provider which of the four they cannot do. The answer tells you more than their website, and the five checks to run on any candidate covers the rest.

Where to start when the answer is unclear

Sequencing beats shopping. Name the purchase, then find the person. Do it the other way round and the impressive person you meet becomes the diagnosis.

A clear answer from the three questions is your mode. Ambiguity is a finding in itself. From outside, the mode is usually clear inside a fortnight. Inside it is harder, because the people best placed to answer are invested in one of the four being right.

Then buy the read, not the retainer. That is the Technical/Strategic Review: two weeks, one written verdict on the decision in front of you, yours to keep whether or not we speak again. It names the mode the situation needs, delivery included when leadership is not the gap. The three steps into a PIMASI engagement are on the homepage.

You are choosing which of the four to buy first. Leaving it unnamed does not stop the purchase happening: it means the enquiry decides for you, in whatever mode answers the phone. The label holds either way. A mismatch stays invisible until the engagement has spent a quarter and left a document nobody can act on, and the business concludes that outside help does not work. Name the buy yourself: book the exploratory call and we will settle which mode it is.

If the decision is live

The Technical/Strategic Review answers it in writing in two weeks: one senior technology director inside your codebase, team and roadmap, then a verdict you own outright. Fixed fee, agreed on the exploratory call, credited against the engagement that follows. How it starts

Book the exploratory call