Should you hire a CTO? First, show me the decisions waiting to be made

The message often arrives the same way. “I’m looking for a CTO.” I ask what they will have to decide in their first month. Silence, then a list of symptoms: deliveries slip, the developers complain, a big client asked technical questions nobody could answer. That is not a job description. It is a pile of decisions nobody has made.

Most companies that want to hire a CTO do not have a vacant position. They have trade-offs left hanging, and hiring is the most comfortable way of not looking at them. For the whole duration of a hire, nobody is responsible, and everyone finds that normal. Sometimes a CTO is the right answer. You only know once you have written the list.

A slowdown proves nothing. It can come from a lack of capacity, an organisational problem or technical friction, and none of the three is fixed with a title. What proves something is a decision that commits the company and that nobody can make: an architecture to evolve, a security constraint to enforce, a technical commitment a client is asking for.

So take a sheet of paper. Which decisions are waiting? Who should be making them today, with what mandate? How much time do they take, preparation and follow-up included? Will they outlast the current project? Four questions, and a good share of the “CTO needs” I see turn into something else: a founder who has to stop deciding alone, a lead developer who lacks a mandate, a migration to have done once.

Above all, be wary of frequency. A ten-minute daily meeting does not make a full-time job. A monthly trade-off can take up half of one. The job description has to describe that work, not copy out a title.

The founder who decides everything and the overloaded lead developer look more alike than they seem. The first owns the architecture, the roadmap and the hiring, does it properly, and is tired, not incompetent: he needs to write down what he decides and what he delegates, then actually delegate, not welcome a CTO who would come and collide with him. The second holds the team and delivery, and over the months has been handed the roadmap, hiring and leadership meetings. They lack a mandate, not a level; take off what can be taken off before adding a management layer above them. The difference between the two roles is in CTO vs lead developer.

Recurring bugs. They call for tests, reviews, incident follow-up, and an available owner organises that internally. A fragile migration justifies a bounded engagement if capacity is missing. Neither creates a permanent need.

What creates a permanent need is a technical leadership workload that fills the everyday and will last. There, you need someone. What remains is the rhythm.

Avoiding a hire can mean avoiding an employment contract, avoiding a full-time role, or simply adding nobody. Those are three different requests. I would start by writing down the decisions needed next month, then naming who prepares each one, who makes it and who follows through.

Need	Option to examine	What it requires
An internal leader can decide, but their authority is unclear	Clarify their responsibility and delegation	A written scope, time freed up and access to leadership decisions
A migration or architecture decision has a defined scope	A specialist engagement	A specific question, an expected deliverable and an internal owner for what follows
Decisions recur, with work that fits into a few days a month	A fractional CTO	A mandate, a schedule, agreed availability and a rule for urgent matters between sessions
Technical leadership needs a lasting daily presence	Prepare an internal role	A budget, a place in the leadership team and an organised handover

Agreed availability matters more than the title. If your team waits for a decision every morning, two days a month may simply create another queue. If decisions are spaced out and can be prepared, paying for a full-time role to make the organisation chart reassuring will not improve them.

Before signing, I would want three things on one page: the decisions entrusted to the role, the limits of its authority and what happens when the person is away. Who can authorise spending? Who accepts a risk? Who calls whom when an incident exceeds the mandate? The freelance CTO article describes the engagement formats; the article on outsourced CTO rates then helps you budget for the chosen schedule. The title comes after the work.

My fractional CTO rate is €550 a day excluding VAT: two days a month come to €1,100, four days to €2,200. The technical and organisational diagnostic takes five days for €3,000 excluding VAT. I invoice from Mauritius, without VAT.

For a salaried CTO, I have no benchmark of my own. In France, the Apec job profile for IT directors, which lists “Chief Technical Officer (CTO)” among its titles, states that 80% of the gross annual pay offered in job ads, fixed and variable combined, falls between €45k and €110k, with an average of €71k. Those are published offers, excluding employer contributions, and an IT director’s job does not always match a startup CTO’s.

But do not compare budget lines, compare work. A salaried CTO is there every day, carries the responsibility over time and may become a partner. Two days a month do not replace that. They are enough when leadership decisions are real without filling a week, or to prepare the hire of the person who will carry them next.

Then hire for decisions, not for technologies. The job description lists what the CTO will decide: overall architecture, technical roadmap, developer hiring, the budget for tools and contractors, security. For each line, who decides today and what changes on arrival. A description that lists frameworks attracts lead developers, and you will have hired the wrong person with the right label.

Do a technical assessment before the interviews: architecture, debt, organisation, known risks. Good candidates will ask for it. If nobody in your company can judge a candidate’s technical depth, get help defining the role and running the interviews. It is one of the engagements I take on a fractional basis, precisely so that the position is defined before it is filled.

Finally, decide their place before they arrive. A CTO kept out of product and budget decisions will do a lead developer’s job, at a CTO’s price. And they will not stay.

I would write the list first to estimate the time needed for preparation, decisions and follow-through, and the availability required. If someone internal can own that work, I would clarify their mandate and free up the time they need. If the workload recurs, fits into a few days a month and lets the team keep working between sessions, I would bring in a fractional CTO, with a written scope. If it requires a lasting daily presence, I would prepare the internal role and get help to fill it.

The “Do I need a CTO?” assessment formalises that discussion in a few minutes. The technical governance page lists the decisions a business leader needs to be able to follow, with or without a CTO.

What not writing the list costs is simple: months of hiring during which the decisions are still waiting, then a CTO who discovers they were hired to make those decisions in your place, without anyone ever having spelled them out.