What is a fractional CTO, and when does a company need one?
Part-time hours, full responsibility. What a fractional CTO does, what it is often confused with, and how to tell whether your company needs one.
A fractional CTO is a chief technology officer who works for a company part-time, on an agreed commitment, with real decision authority. Not an advisor who sends a memo and leaves, and not a contractor who only writes code: an executive who owns the technology direction for a defined share of the week.
The word that matters is not "fractional". It is "CTO". The time is partial; the responsibility is not.
Why the role exists
Most companies between a handful of engineers and a few dozen have a technology problem that is too big for the senior developer and too small for a full-time executive. The symptoms are familiar:
- Decisions nobody owns. Which platform, which vendor, rebuild or repair. They wait for the founder, who is not an engineer, or get made by whoever is loudest.
- A roadmap with no trade-offs. Everything is a priority, so delivery dates are guesses and the board hears a different story each quarter.
- Risk nobody has measured. One person knows how deployment works. The cloud bill grows faster than revenue. Security is "probably fine".
A full-time CTO at that stage costs a senior salary plus equity for a job that is perhaps two days a week of executive work. A fractional CTO buys those two days without the rest.
What the work actually is
In my engagements the job settles into five things. They are the same five a full-time CTO does; the difference is cadence.
- Direction. A technical strategy that follows the business strategy, written down, with the trade-offs named.
- Decisions. Architecture, platform, build-versus-buy and vendor choices, made and recorded so they do not get re-argued every month.
- Delivery. A roadmap with owners, and a working cadence that makes progress and slippage visible to the people paying for it.
- People. Who to hire next, who to promote, how the team is structured, and the mentoring that turns a good senior into a lead.
- Risk. Reliability, security, cost and single points of failure, reported to leadership in a form they can act on.
What it is not
Three things get confused with it. A technical advisor gives opinions without responsibility for outcomes. An interim CTO is full-time and temporary, holding the seat until a permanent hire. A contract developerbuilds what they are asked to. A fractional CTO may do some of each when it helps, but the engagement is judged on whether the technology function is in better shape, not on hours or features.
How to tell whether you need one
- Technology decisions are stuck or keep being reversed.
- The team needs a leader, and the senior engineers are needed as engineers.
- Leadership cannot see technical priorities, delivery or risk clearly.
- You are raising, selling or scaling, and someone will ask hard questions about the platform.
If two of those are true, the question is rarely whether you need the role. It is whether you need it five days a week yet.
What to agree before it starts
The engagements that work are the ones with the boring details fixed on day one: the time commitment, what the CTO decides alone and what goes to the founder or board, how the team reaches them between sessions, and whether writing code is part of the job or a distraction from it. The first few weeks are learning the business and the team; the plan comes after, not before. That is how I work, and it is the order every engagement I have led since 2010 has followed.
Done well, the role makes itself less necessary over time. The decisions get owned by the people you have, the leads grow into the gap, and the company either hires a full-time CTO with a clear brief or finds it no longer needs to.