VP Engineering vs CTO: Which First?

The short version: a CTO decides what to build and on what; a VP Engineering makes sure it gets built. Most scaling businesses need the second before the first, and appoint the first because it sounds more senior.

That inversion is the commonest structural mistake in technology leadership hiring, and it is expensive — a strategist appointed into a delivery problem spends a year producing architecture documents while releases keep slipping. This article sets out where the line falls between the two roles, which appointment to make first, when the split becomes necessary, how the two work together once both are in post, and how to tell the candidates apart at interview.

What each role owns

The CTO owns technology strategy and technical direction. Architecture, build-versus-buy, platform choices, technical risk, and the relationship between what the technology can do and what the business wants to sell. In product businesses the role is externally facing too — investors, partners, occasionally customers. It is a strategic and representational role as much as a technical one, and in many businesses it carries a seat on the executive committee or the board.

The VP Engineering owns the engineering organisation and its output. Hiring, team structure, delivery cadence, process, performance management, and the health of a function that may be the largest in the business. Success is measured in shipped work, predictability and retention. The title varies — Head of Engineering, Engineering Director and Director of Engineering often describe the same job at different company sizes — but the accountability is the same: the engineering machine runs, and runs well.

The distinction is not seniority. In many businesses they are peers, and in some the VP Engineering manages more people and more budget. The distinction is what the role is accountable for — direction versus delivery.

Where either role is a statutory directorship, the holder also takes on the general duties of a director, including the duty to promote the success of the company under section 172 of the Companies Act 2006. That is more common for the CTO than the VP Engineering, and it changes the conversation: a board-level CTO is answerable for technology decisions as company decisions, not just engineering ones. The government’s guidance on being a company director is a useful starting point for anyone stepping into that position for the first time.

Side-by-side comparison

	CTO	VP Engineering
Accountable for	What gets built and on what	That it gets built, predictably
Time horizon	Twelve to thirty-six months	This sprint to this quarter
Spends time on	Architecture, vendors, board, technical risk	People, process, hiring, delivery
External facing	Frequently — investors, partners, customers	Rarely, beyond recruitment
Failure looks like	Wrong platform bets, mounting technical debt	Slipping releases, engineering attrition
Typical background	Architect, founding engineer, principal	Engineering manager, director of engineering

Read the table as a description of where each person’s attention goes, not as a hierarchy. A good CTO cares about delivery and a good VP Engineering has opinions on architecture. The question is which of the two they are accountable for when something goes wrong — and therefore which one the board should ask about when it does.

Which to appoint first

Work backwards from the symptom rather than forwards from the org chart.

Appoint a VP Engineering first where the direction is clear but delivery is not. The symptoms are recognisable: releases slipping repeatedly, estimates nobody trusts, engineers leaving, a founder or technical lead spending most of their week unblocking people rather than thinking. In our experience this is the more common situation in growing engineering teams, and it is where the appointment pays for itself fastest.

Appoint a CTO first where delivery is adequate but direction is not. Platform decisions being deferred, a technical estate nobody has a plan for, an investor or board asking questions the business cannot answer, or a product strategy that depends on technical choices nobody senior is making. Our CTO recruitment work most often starts from exactly this position: a business that can ship, but cannot say with confidence what it should be shipping on in two years’ time.

Where the founder is technical — common in early-stage businesses — the CTO function often already exists informally, and a VP Engineering is almost always the right first external appointment. Bringing in a CTO over a technical founder rarely works unless the founder has genuinely decided to step away from technical direction, which they usually have not.

A simple test helps. Ask: if every platform decision were correct tomorrow, would the problem be solved? If yes, you need a CTO. If you still could not ship reliably, you need a VP Engineering — and paying C-suite money for the wrong capability is an expensive way to find that out.

The split point

In smaller businesses one person covers both. The question is when that stops being viable. The bands below are a rule of thumb drawn from the searches we see, not a fixed threshold.

Under about fifteen engineers, one role is normal and sensible. A hands-on CTO or a Head of Engineering carries both, and splitting creates overhead the organisation cannot absorb.

Between fifteen and forty, the strain becomes visible. The individual is either neglecting strategy to manage people or neglecting people to think about architecture. Most businesses split somewhere in this band, and most wait longer than they should.

Above forty, running both is rarely workable. Businesses attempting it typically have a burnt-out technical leader and an engineering function that has quietly organised itself.

Headcount is a proxy rather than a rule. Several factors bring the split point forward:

• Multiple products or platforms. Each adds architectural decisions and delivery dependencies, and one person cannot hold both sets of detail.
• Multiple locations or time zones. Distributed teams need more deliberate management of process and communication, which pulls a combined leader towards the VP Engineering half of the job.
• A regulated environment. Financial services firms, for example, face specific expectations on operational resilience, which put technology risk and third-party dependencies in front of the board and add a governance load to the CTO role.
• A fundraise or exit in view. Investor and acquirer technical due diligence takes senior time that cannot come out of delivery without delivery suffering.

How they work together

Where both exist, three things determine whether the relationship functions.

Who the engineers report to. Almost always the VP Engineering. A CTO retaining direct reports across the engineering organisation undermines the appointment immediately and confuses everyone below.

Who owns the roadmap trade-off. When product wants a feature and the platform needs work, someone decides. Usually the CTO, in consultation — but it should be written down, because this is the recurring point of friction. Where a Chief Product Officer also exists, the three-way conversation between product, platform and delivery needs an agreed forum and an agreed tie-breaker.

Whether both report to the CEO. Peer structure works well where the two respect each other’s remit. A VP Engineering reporting into the CTO also works and is more common. What works badly is an ambiguous arrangement where both believe they own the function.

Board reporting is worth settling at the same time. Technology risk — including cyber risk — is now a standing board topic in most businesses of any size, and the NCSC Cyber Security Toolkit for Boards sets out the questions directors are expected to ask. Decide in advance whether the CTO presents on technical risk alone or whether the VP Engineering joins for delivery, so the board hears one coherent account rather than two partial ones. Professional standards for technology leadership in the UK are also published by BCS, The Chartered Institute for IT, which is a sensible reference point when defining either role.

Interim and fractional options

Not every business that needs technical direction needs a full-time CTO, and not every delivery problem needs a permanent VP Engineering on day one. Two flexible routes are worth considering before committing to a permanent hire.

A fractional CTO suits the business whose delivery is in reasonable shape but which needs senior technical judgement a few days a month: a platform decision, an investor due diligence process, a technology strategy for the board. Paired with a capable Head of Engineering running the team day to day, it often covers the gap until the business is large enough to justify a permanent CTO.

An interim CTO suits a different situation: a departure, a failed hire, a platform migration or a post-acquisition integration where someone needs to be in post full-time immediately. An interim can also stabilise delivery while the permanent search for the right long-term structure runs, which avoids making the CTO-or-VP decision under pressure.

Either route can tell you which permanent role you actually need. A fractional CTO who finds themselves spending every session on team problems is evidence that the next permanent hire should be a VP Engineering.

Assessment: distinguishing the two at interview

Candidates frequently present for both, so the questions need to separate them.

“Tell me about a delivery problem you fixed. What specifically changed?” — VP Engineering candidates describe process, structure and people decisions with dates attached. CTO candidates often describe a technical solution, which is a different answer to a different question.

“Describe a platform decision you made that turned out badly.” — the CTO question. Look for a specific bet, a specific cost and what they learned.

“How many engineers have you hired and how many have you let go?” — VP Engineering candidates answer both parts readily. Reluctance on the second is worth exploring.

“Explain a technical risk to me as though I were your board.” — relevant for both, decisive for a CTO. If technical exposure cannot be translated into commercial consequence, the board will never fund the fix.

“What would you stop doing in your first ninety days?” — a useful closing question for both. A VP Engineering candidate usually names meetings, rituals or work in progress; a CTO candidate usually names projects or technology commitments. Either answer tells you how they think about where the leverage sits.

For a fuller question set, see our guide to CTO interview questions, and use a role description written for the job you need rather than a generic one — our CTO job description shows how to frame the strategic remit.

Mistakes to avoid

• Hiring for the title. Boards default to a CTO because it is a C-suite title and feels like the more significant appointment, then describe a problem that is entirely about delivery. Start from the problem.
• Writing one brief for both. A specification that asks for a visionary architect who also runs sprint planning for forty engineers attracts candidates who are strong at one half and tolerable at the other.
• Leaving reporting lines open. If the second hire arrives without an agreed answer to who the engineers report to, the first few months are spent negotiating it.
• Promoting by default. A strong engineering manager is not automatically a CTO, and a gifted architect is not automatically a people leader. Test for the job, not the trajectory.
• Waiting too long to split. By the time a combined leader is visibly overloaded, attrition and technical debt have usually built up already. Plan the split before it becomes urgent.

Getting the sequence right matters more than getting the title right. If you are unsure which appointment comes first, a short diagnostic conversation before you brief a search is usually time well spent — and it is the starting point for every technology leadership search we run.

Frequently asked questions

Is a CTO more senior than a VP Engineering?

Usually in title, not always in practice. The CTO holds a C-suite position and owns technical direction; the VP Engineering frequently manages more people and more budget. In many businesses they are peers reporting to the CEO.

Which should a scale-up hire first?

Usually a VP Engineering, because the common problem at that stage is delivery rather than direction — particularly where a technical founder is already providing the CTO function informally. Hire a CTO first where platform decisions are being deferred and delivery is adequate.

At what team size should the roles split?

As a rule of thumb, most businesses split between fifteen and forty engineers. Below that one person can reasonably carry both; well above it, combining them rarely works. Multiple products, multiple locations or a regulated environment bring the split point earlier.

Can a VP Engineering become a CTO?

Sometimes, though the two draw on different strengths. The step requires architectural judgement and board-facing communication that running a delivery organisation does not necessarily develop. Test both before promoting rather than assuming progression.

Do the engineers report to the CTO or the VP Engineering?

To the VP Engineering, in almost all functioning structures. A CTO retaining direct reports across the engineering organisation undermines the VP’s authority and creates confusion about who sets priorities.

Is a fractional CTO a substitute for a VP Engineering?

No. A fractional CTO provides part-time direction and senior judgement; it does not provide the daily people and delivery management a growing engineering team needs. The two are often combined: a fractional CTO alongside a full-time Head of Engineering.