A Fractional CTO is often described as a part-time CTO, but I have never found that description particularly useful. It describes the dedicated time commitment, but can make the arrangement sound more binary than it is, as though a business has a CTO for two days of the week and not for the other three.
If I am working with a company two days a week, that defines how much of my capacity it is retaining, and therefore how involved I can be and what I can reasonably take on. It does not mean the CTO relationship switches on and off with those hours. Important decisions, problems and occasionally urgent situations do not conveniently wait for the next scheduled day.
That does not turn two days into an unbounded five-day commitment. The arrangement needs clear boundaries, but there is continuity to the relationship and responsibility that the phrase “part-time CTO” does not capture particularly well.
Within that relationship, the point of the role is to help the business make better technical decisions as it works out how to achieve what it is trying to do.
Sometimes a company already has developers, an agency, or several teams producing software. Sometimes it is about to make a substantial investment and needs technical leadership before choosing an agency, hiring a team, or committing to a plan. In both cases, deciding who will do the building is only part of it. Someone still needs to work through what should be built, how it should be built, and in what order.
The situation that creates the need
Most businesses do not wake up wanting to hire a Fractional CTO. They reach a point where technology has become important enough that decisions can no longer be made casually, but there is not necessarily forty hours of CTO work every week.
That might look like a busy development team with uncertain priorities, an agency that needs more direction than a backlog provides, a product that is taking longer and costing more than expected, or a significant new idea that needs challenging before it turns into months of commitment. The symptoms differ, but the underlying gap is similar: the business needs someone who can connect its goals to the technical choices and trade-offs in front of it.
Those are the kinds of problems I focus on in my role as a Fractional CTO. The point is to give the people doing the work enough direction to make sound decisions earlier, before uncertainty becomes delay or expense.
How the level of involvement is set
The actual level of involvement needs to fit the problem. It may be a few days a month around important decisions, several days a week through a period of change, or a focused piece of work to establish what should happen next. The precise arrangement should follow the business’s situation, rather than fitting the business into a pre-sold package.
Someone helping set the technical direction needs enough context to understand the business, the people doing the work, the constraints, and the consequences of the choices being made.
That is why I begin with the problem and then work out the right level of involvement. A small company may need an experienced sounding board for a handful of decisions. Another may need someone more embedded while a product, team or platform changes shape.
What I am responsible for
My responsibility is the technical decision-making that connects what the business is trying to achieve with what gets built. That means understanding the objective properly, questioning the assumptions behind it, and working through the technical decisions and trade-offs that follow.
WHAT TO BUILD
Some of that is deciding what to build: whether it solves the business problem, what belongs in scope, and what can wait.
HOW TO BUILD IT
Some of it is deciding how it should be built. A feature can appear to work perfectly while the choices underneath it make the next stage more expensive or restrictive than it needs to be.
Those choices are not always about using the most rigorous architecture available; a company testing an idea with a few hundred customers does not need to build for hundreds of millions of records. If it is likely to handle financial data, grow substantially or need to integrate with other systems, those implications need to be considered while there is still a practical choice.
In practice, that can include turning objectives into an engineering roadmap, clarifying priorities, challenging an architecture or vendor decision, making technical debt visible, improving delivery, helping a team communicate clearly, or deciding what level of security, resilience and data rigour the situation actually warrants.
How this differs from a developer, an agency or an external review
A good developer brings skill and judgement to the work in front of them. A good agency can bring a capable team and deliver a defined outcome. Both can be valuable. Neither role automatically owns the wider technical picture for the business.
Likewise, an external assessment can be useful when the question is narrow: is this architecture sound, where are the main risks, what should happen next? But a report is only useful if someone can carry its recommendations into the decisions that follow.
A Fractional CTO should work with the existing developers, agencies and leaders, giving their work the context and technical direction it needs to serve the business.
If you are preparing a substantial build, or have technology moving faster than your confidence in the decisions around it, tell me what’s going on. We can work out whether a Fractional CTO is the right answer.