How to Tell If You Need a VP of Engineering or a CTO

Your CTO co-founded the company, wrote the first version of the product, and now spends Tuesday afternoons doing performance reviews.

Someone on the board has suggested a VP of Engineering.

Someone else thinks what you really need is a proper CTO, and that the Founder should go back to building.

Both of them sound reasonable, and you have to pick.

It is one of the harder calls a Founder makes.

Partly because the two titles get used almost interchangeably, and partly because the wrong answer is expensive in a way that only shows up about a year later, when someone good hands in their notice and tells you in the exit conversation that the job was never really theirs to do.

This is how we work through it with Clients before a search opens.

The two jobs, separated

A CTO owns technical direction. What you build on, what you buy, where the architecture is going, and how you explain all of that to an Investor or an Enterprise Security team. It is an outward-facing and forward-facing job as much as a technical one.

A VP of Engineering owns the machine that ships. How the team is structured, who you hire and in what order, how work moves from decision to production, what happens when it breaks at 2am, and whether your engineers can see a career in front of them.

Written down like that they look obviously different. In a forty-person company they overlap constantly, which is exactly why the titles blur.

Four Questions that usually settle it

What is actually broken? If the honest answer is that features take four months and nobody can tell you why, that is a delivery problem and you need a VP of Engineering. If the answer is that you keep losing enterprise deals on technical questions, or that nobody can describe the platform strategy for the next two years, that is a direction problem and it belongs to a CTO.

Where is your Founder-technologist spending their week? Get them to keep a rough log for a fortnight. If most of it is one-to-ones, interview loops, sprint planning and chasing delivery, they have quietly become a VP of Engineering and nobody has replaced the CTO work. Hiring a VP of Engineering hands that back to them. If instead they are deep in architecture and customer conversations and the team is drifting, you need someone to run the org.

Who is going to say no? Someone has to tell sales that the integration will not land this quarter, and tell an engineer that the rewrite is not happening. If nobody currently holds that line, you need a VP of Engineering with the standing to hold it, not a technical adviser.

What does the next eighteen months look like? If the plan is to double the Engineering team, the bottleneck will be hiring, onboarding and structure. If the plan is a platform rebuild or a move into a regulated market, the bottleneck is technical judgement. Hire for the bottleneck, not the org chart you would like to have.

The trap: Hiring the Title rather than the Job

The most common failure we see is not a bad hire. It is a good hire dropped into a role that was never really vacated.

A VP of Engineering joins, and discovers the Founder still approves architecture decisions, the VP of Product still sets the roadmap, and the engineering managers still take their steer from someone else. There is nothing left to own. Twelve months later they leave, and the company concludes that VPs of Engineering do not work here.

Before you open a search, write down the three decisions this person will make that nobody else gets to overrule. If you cannot fill in all three, the role is not ready. That single exercise has stopped more bad searches than any interview process we run.

What if the answer is both?

Sometimes it genuinely is. A Series B company with a founding CTO who wants to stay technical, and no one running the org, needs both jobs covered. That does not mean two hires at once.

In practice the sequence usually works better: hire the VP of Engineering first, let the founding CTO step back into technical direction, and see how much of the CTO gap closes on its own. Quite often it closes entirely, because the person you thought was missing was the one you already had, buried in calendar admin.

If it does not close, you will have a much sharper brief for the CTO search six months later, and a VP of Engineering who can help you assess candidates.

When the answer is neither, not yet

At fifteen engineers with a Founding CTO who is still enjoying the job, a VP of Engineering is usually premature. What is missing is more often one or two strong engineering managers, or a first platform hire to stop everyone tripping over infrastructure.

Senior leadership hires at that stage tend to arrive, find the scope too small, and get restless. It is a genuinely common way to waste nine months and a lot of goodwill.

How to Interview once you have decided

Founders default to a deep technical interview for Leadership roles, because it is the conversation they most enjoy having. It tells you very little about whether the person can run an org.

Bring in an engineer you trust for one session on technical depth, and spend your own time on judgement. Ask for a delivery failure they owned and what they changed afterwards. Ask about a performance conversation they got wrong. Ask how they decided what not to build last year, and who was unhappy about it. People who have really led have specific, slightly uncomfortable answers to all three. People who have sat near leadership give you frameworks.

Getting help with the Search

Engineering Leaders are not on the market. The good ones are two years into a job they are proud of, which makes a leadership search a persuasion problem long before it is a screening problem. That is why we run these as retained searches with a proper market map rather than a stack of CVs.

If you want the detail on how we approach it, our page on VP of Engineering and CTO recruitment covers the process, the timelines and the questions we ask before a search opens.

But start with the first question, honestly. What is actually broken? The title follows from the answer, not the other way round.