A company reaches a certain size and someone raises the question of whether it is time to hire a CTO. The debate that follows is usually framed as a budget question. It is actually a diagnosis question, and getting the diagnosis wrong is expensive in both directions.
Two problems that look identical from the outside
A capacity problem sounds like: the roadmap is clear, but there are not enough hands to build it. Things ship late. The backlog grows. Everyone knows what to do and there is too much of it.
A leadership problem sounds like: nobody can say what the roadmap is. Three teams have solved the same problem three ways. Vendor contracts renew because nobody owns the decision to stop them. The last two technology choices were made by whoever happened to be in the room.
These feel similar day to day — both present as "technology is holding us back" — and they have opposite solutions. Hiring engineers into a leadership problem makes it worse, because you have added more people to an environment with no framework for deciding anything. Hiring a CTO into a capacity problem produces an expensive executive who spends their week writing code.
Diagnose before you hire. The question that separates them: if I doubled the engineering team tomorrow, would we ship the right things faster, or just ship more things?
What the role actually is
Setting technical direction and making sure it is followed. Owning the architecture so the organization is not accumulating hidden liabilities. Deciding what to build, what to buy, and what to stop paying for. Translating between what the business wants and what is technically real, in both directions. Being the person accountable when a technology decision turns out badly.
Notice what is not on that list: writing most of the code. A CTO who is the primary engineer is either at a company too small to need the title, or is neglecting the role they were hired for.
Where fractional fits
A fractional CTO arrangement suits a specific shape of company: enough technology complexity to need senior judgment, not enough to occupy a senior executive full time. Somewhere between "our operations depend on systems we do not fully understand" and "we have a real engineering organization."
It works when the engagement is about direction, standards, and decisions. It does not work as a discounted way to get an engineer — if what you need is someone to build, hire someone to build.
The honest version of this arrangement has an end state built in. A good fractional engagement should make itself unnecessary: establish the architecture, set the standards, make the deferred decisions, document the reasoning, and hand over to an internal hire when the company has grown into one. Anyone offering this as a permanent arrangement with no succession plan is selling a dependency.
If you are somewhere in the middle
Most companies asking this question do not need to resolve it immediately. What they need is to stop letting decisions get made by default.
A reasonable interim step: write down every technology decision facing the company in the next twelve months, name an owner for each, and put a date on it. Renewals, integrations, the platform question everyone is avoiding, the security work that keeps sliding. That list is usually shorter than expected and more urgent than expected.
If you can work through that list with the people you already have, you have a capacity problem and you should hire builders. If the list sits untouched for a quarter because nobody has the standing or context to decide, that is your answer, and it is a leadership problem. Deferring it does not make it cheaper.