CTO vs VP of Engineering: who does what, and who you need first

When a company has both roles, the CTO owns technology direction: architecture, the big technical bets, and the company's technical voice with investors and customers. The VP of Engineering owns the engine room: people, process, hiring and predictable delivery. At an early startup one person does both jobs, and usually carries the CTO title.

The distinction starts to matter once the team grows. Here is what each role owns, how the two work together, and the order in which most companies need them.

What does a CTO do?

The CTO answers one question: what should we build this with, and why? In practice that means:

• Technology strategy. Turning business goals into a technical roadmap, and deciding what to build, buy or skip.
• Architecture. The big structural choices: platforms, data, integrations, how the system scales and where AI fits.
• Technical risk. Security posture, reliability targets, technical debt and the decisions that are expensive to reverse.
• The outward voice. Explaining the technology to investors, leading technical due diligence, and reassuring large customers and partners.
• Setting the bar. Hiring the first senior engineers and defining what good engineering looks like at your company.

The title covers very different jobs at different companies. At a five-person startup the CTO writes code most days. At a large company the CTO may never touch production code, spending most of their time on strategy, research and customers.

What does a VP of Engineering do?

The VP of Engineering answers a different question: how do we deliver this well, predictably, with a team that wants to stay? The job usually covers:

• People. Managing engineering managers, one-on-ones, performance reviews, career ladders and pay decisions.
• Hiring. Running the recruiting machine: role specs, interview loops, onboarding and headcount planning.
• Delivery. Planning, estimation, release management and keeping the commitments engineering makes to the rest of the business.
• Process. Just enough of it: sprint rhythms, code review standards, incident response and on-call.
• Running the department. The engineering budget, tooling, vendors and metrics the leadership team can trust.

A good VP of Engineering is usually a former engineer who moved into management and has already scaled a team through the size you are heading for. They can hold their own in a technical conversation, but their main product is the team itself.

CTO vs VP of Engineering: the key differences

Treat this as a pattern, not a law. Some companies flip it, pairing a people-focused CTO with a deeply technical VP of Engineering. What matters is that both halves are covered and everyone knows who owns which.

Who should you hire first?

For almost every startup: the CTO, or at least someone doing the CTO job. Before you have a product and an architecture, there is nothing for a VP of Engineering to run. Hiring one first gets you sprint ceremonies for a product nobody has defined.

With one to five engineers, splitting the roles creates two half-jobs and a turf problem. One technical leader should set direction, make architecture calls, review code and manage the handful of engineers. If you are still deciding whether that first hire should be a senior engineer or an executive, read whether your first tech hire should be a developer or a CTO.

One trap to avoid: handing your first engineer the CTO title as a perk. When you later need a more experienced CTO, that title becomes a painful conversation, and sometimes a resignation.

The exception is a company with a strong technical founder. If the CEO or a co-founder already sets technology direction and owns the architecture, the first senior hire may well be a VP or head of engineering, who runs delivery while the founder stays on product and technology.

When to hire a VP of Engineering

There is no magic headcount, but many companies feel the need somewhere around 8 to 15 engineers. The exact point depends on how senior the team is, how many teams you run, and how much your CTO enjoys management. Watch for these signals:

• Delivery dates slip, and nobody can explain why until it is too late.
• Your CTO's calendar is mostly one-on-ones, hiring loops and status meetings.
• Architecture decisions and technical debt wait because nobody has time to think.
• You have two or more teams to coordinate, or managers who need a manager.
• Next year's hiring plan would roughly double the team.
• Good engineers leave, and exit conversations mention unclear expectations or no path to grow.

Look for someone who has already led a team through the growth you are planning, has hired managers before, and brings pragmatic process rather than big-company ceremony. For how teams usually take shape on the way there, see how to structure an engineering team from 1 to 15 engineers.

How to interview a CTO vs a VP of Engineering

The difference between the two roles shows up most clearly in hiring, because they need different interview loops. Running a CTO loop to hire a VP of Engineering, or the other way around, is how companies end up with the wrong profile.

For a CTO, test judgment about technology

• Ask them to walk through the biggest technical bet they made, the alternatives they rejected, and what they would change now.
• Have them critique your current architecture and say what they would leave alone. Knowing what not to touch is a senior skill.
• Ask them to explain a hard technical trade-off as if you were an investor, because they will need to do exactly that.
• Check how hands-on they still are, and whether that matches what your team needs this year.

For a VP of Engineering, test judgment about people and delivery

• Ask how they grew a team from roughly your size to the size you plan, and what broke along the way.
• Ask about a manager they hired who did not work out, and what they did about it.
• Ask what process they introduced at their last company, and what they removed. Good candidates remove as much as they add.
• Ask how they would tell, within a month of joining, whether delivery is healthy.

For both roles, take references from people who reported to the candidate, not only from the people they reported to.

Where a fractional CTO fits

Early on, a fractional CTO can cover the CTO half of the job part-time, and often the VP of Engineering half too while the team is small: setting direction, choosing the architecture, hiring the first engineers and running delivery. A hands-on one, which is how I work, also builds the product. Here is what a fractional CTO does in a typical week.

As the team grows, there are three common moves:

1. Hire a full-time CTO when technology is the moat and needs someone all-in. The fractional CTO helps with the search and the handover.
2. Hire a VP of Engineering and keep the fractional CTO. The VP runs people and delivery full-time; the fractional CTO keeps architecture and direction for a few days a month. This suits companies where technology supports the business rather than being the business, and it costs far less than two full-time executives.
3. Hire both over time. Usually a VP of Engineering first, because delivery problems hurt sooner, then a full-time CTO when the technical bets get bigger.

Whichever path you take, plan it deliberately. A careful handover from a fractional to a full-time leader keeps the context that took years to build.

How a CTO and a VP of Engineering should split decisions

Much of the friction between these two roles comes from overlapping, unspoken decision rights, so write them down. A simple starting point:

Add a weekly one-on-one between the two and a rule that disagreements go to the CEO quickly rather than festering. If the CTO keeps overriding the VP's process, or the VP starts making architecture calls by default because the CTO is never around, fix the split before it costs you one of them.

The bottom line

A CTO decides where the technology is going; a VP of Engineering makes sure the team gets it there. At the start one person does both, usually under the CTO title, and a fractional CTO can fill that seat until the workload justifies more. Add a VP of Engineering when people and delivery work crowd out technology, and write down who decides what before the two roles collide.