Fractional CTO vs a Full-Time VP of Engineering

I take fractional CTO and fractional VP of Engineering engagements, so read this knowing I have a side. I am writing it anyway, because the version of this comparison that exists online is mostly written by people selling one of the two options, and it shows.

Here is what I tell founders when they ask, including the cases where the answer is that they should not hire me.

They are not the same job at different hours

Most comparisons treat this as a seniority question, or a budget question. It is neither. A CTO and a VP of Engineering are two different jobs, and the fractional-versus-full-time question cannot be answered until you know which one you are trying to fill.

A CTO owns technical direction. Architecture, build-versus-buy, which bets are reversible and which are not, and the technical face of the company to investors, key customers and partners. The output is decisions.

A VP of Engineering owns delivery. Planning, process, hiring, performance, retention — the machine that turns decisions into shipped software, and the people inside it. The output is a team that ships predictably.

At two hundred people these are two people. At twelve they are usually one person wearing both hats badly, which is exactly where the confusion starts. So the real question is not “fractional or full-time.” It is which of those two jobs is my bottleneck, and only then, how much of it do I need.

The bottleneck test

There is a reliable split, and it has little to do with company stage or headcount.

If your bottleneck is decisions, fractional works. Decisions are low-frequency and high-consequence. Whether to rewrite. What to build the platform on. Which model, at what cost, with what fallback when it is wrong or slow. When to migrate, and what to deliberately leave behind. You need judgement at the moment the decision is live, not availability in the weeks between. Paying a full-time salary for that is paying for capacity you will not consume.

If your bottleneck is people, hire full-time. People problems are the opposite shape: high-frequency and cumulative. Hiring. One-to-ones that actually surface things. Performance conversations. Career growth. Noticing quiet disengagement three weeks before the resignation rather than three weeks after. That work runs on presence and accumulated context, and neither of those compresses into two days a week.

This is the line I hold to, and it costs me work: I turn down fractional engagements where the real problem is that a team needs a manager. Any fractional leader who tells you they can run your people function part-time is selling. The engagement will look fine for a quarter, and then you will find out that nobody was actually holding the team.

What the cost comparison usually gets wrong

Per hour, fractional is more expensive. Per decision, it is much cheaper. That much is straightforward, and it is not the interesting error.

The interesting error is in the shape of the comparison. A full-time VP of Engineering search in Europe runs three to six months to a signed offer, plus a ramp before the new hire can make a call that sticks. If the decision in front of you belongs to this quarter, your real choice is not fractional versus full-time — it is fractional versus nobody until well into next year. Founders routinely compare a cost they would start paying next week against one they would start paying in two quarters, and conclude that the second one is cheaper.

The other half is that salary is not the cost. Add employer contributions, equity, a recruiter fee at twenty to twenty-five percent of first-year compensation, and then the real expense: a wrong leadership hire does not cost you one salary. It costs you the year the team spends heading in the wrong direction, plus the engineers who leave because of it.

When a full-time VP of Engineering is the right answer

Hire full-time when most of these are true:

• The team is past roughly fifteen engineers, or will be within a year.
• Hiring is the constraint, and you need someone running a pipeline continuously rather than advising on one.
• You have retention or performance problems, or a management layer that needs building.
• Technical direction is broadly settled and execution is what hurts.
• The job genuinely requires someone in every room, every day.

If that is your situation, a fractional engagement is a delaying tactic and you should skip it.

When a fractional CTO is the right answer

Go fractional when most of these are true:

• You are before your first senior technical hire, the founder is making every technical call alone, and that has become the thing slowing the company down.
• There is a specific high-consequence decision in front of you: a rewrite, a replatform, a cloud migration, or an AI prototype that has to become a product.
• You are between CTOs and need continuity rather than a caretaker.
• Your board wants technical judgement in the room at a headcount that does not justify a full-time executive.
• You do not yet know what the role should be, so hiring for it now means writing a job description out of guesswork.

That last one is underrated, and it is the most common reason I get called.

The alternatives most comparisons leave out

This gets framed as a binary and it is not one. Rule these out before choosing either.

Promote from within, with outside coaching. You often already have the person. What they lack is a peer who has done the job before, and that is a few hours a month, not a hire.

A staff or principal engineer instead of a leader. A surprising share of “we need engineering leadership” turns out to be “nobody owns technical quality.” That is an individual contributor hire. It is easier to make and it fails less expensively.

An interim CTO, which is not a fractional one. Interim means full-time hours for a fixed term, usually covering a gap. Fractional means part-time hours, ongoing. The two words get used interchangeably and they solve different problems — if you need someone in the building every day for six months, ask for interim and do not let anyone sell you fractional.

An agency or an outsourced team. A real option for scoped delivery and a poor one for direction. You will get throughput, and you will not get someone whose job is to tell you that you are building the wrong thing.

Nothing. Sometimes the honest answer is that the founder should keep making the technical calls for another two quarters and spend the money on engineers instead.

The sequence that usually works

The two options are less rivals than consecutive steps.

Fractional first: make the decisions that are blocking, get the architecture and the delivery model into a defensible state, and work out what the permanent role actually needs to be. Then hire full-time into a role that is now legible — often with the fractional leader running that search and briefing their own replacement.

A fractional leader who will not help you hire them out of the job is misaligned with you, and it is worth asking about in the first conversation. My engagements carry a three-month minimum because anything shorter cannot change how a team works — not because I want to still be there in year two.

How to decide in one sitting

Answer four questions honestly.

1. What broke most recently, and was it a decision or a person? Decisions point fractional. People point full-time.
2. If the right person started tomorrow, what would they do in week one? If you cannot answer that, you are not ready to hire full-time. You are ready for someone to help you define the role.
3. How many hours a week does that work genuinely take? Not how many hours you would like someone to be available. Founders over-estimate this consistently, and usually by a lot.
4. What happens if you do nothing for six months? If the answer is “we make three irreversible decisions badly,” that is a fractional engagement. If it is “we lose two engineers and replace neither,” that is a full-time hire.

Where this comes from

I led the API work on KLM’s airport slot management platform for a team of around six engineers — a cloud migration of a system that gets no maintenance window, where the architecture decisions and the delivery practices were the same conversation. I was project lead on the CMS and API behind the Dutch Single Digital Gateway programme, where the constraint was getting every municipality, province and water authority in the country publishing to one standard. I have built platform capability at Betty Blocks and the Dutch access layer at FlatPeak, and I have written up the multi-LLM stack that came out of taking an AI product from prototype into production.

Both halves of this comparison are jobs I have actually done, which is the only reason I think the distinction is worth writing down.

If you are working out which one you need, what I take on and how engagements are shaped is written up in full. Or describe the situation and I will tell you which of the two it is — including when it is neither.