CTO, VP of Engineering, and Head of Product own different things. Pick one.

Failed technical leadership searches rarely fail on the candidate. They fail on a spec that quietly asked one person to hold two of these three jobs.

‍

The real problem

The confusion starts with how the search gets scoped. A board says the company needs stronger technical leadership. Someone drafts a CTO spec because CTO is the biggest title available. The spec then absorbs every technical complaint anyone has: delivery is slow, the architecture is aging, the roadmap keeps changing, nobody can tell the board what the AI strategy is.

No single person owns all of that. The spec goes to market anyway, and the slate comes back full of people who are excellent at one third of it. Whoever gets hired is then measured against the other two thirds and found wanting inside a year.

‍

What each role actually owns

Three axes separate them. Time horizon, direction of attention, and whether they own the what or the how.

The CTO owns the horizon and faces outward. Technology strategy two to five years out, the architecture bets that are expensive to reverse, the credibility of the technical story with the board, customers, and acquirers. In a portfolio company this role also carries diligence and integration for technical tuck-ins.

One caveat that gets skipped. At Series A the CTO is often the best engineer in the building, hands on the keyboard. At 300 people that same title means almost none of that. Companies scaling through the middle frequently keep the founding CTO in the seat and then wonder why the strategy work isn't happening. The person didn't change. The job did.

The VP of Engineering owns delivery and faces inward. Velocity, quality, the shape of the org chart, hiring and retention, and the operating cadence that turns a roadmap into shipped software. This is a present-tense job. The measure is whether the team ships predictably and whether good engineers stay.

The Head of Product owns the what and the why. Which problems are worth solving, in what order, and for whom. They do not own the how, and the fastest way to break the function is to let them. When engineering has no product counterpart, the team optimizes for what is technically interesting, and the roadmap becomes a list of things that were easy to build.

‍

The failure mode is collapsing two into one

Most companies do not hire the wrong person. They write a spec that fuses two of these three jobs and then hire someone strong in one half.

Fuse CTO and VP of Engineering and you get a leader running standups who never gets to the architecture, or an architect who lets delivery drift. Fuse Head of Product and VP of Engineering and priorities get set by whoever is loudest in the sprint planning meeting. Fuse CTO and Head of Product and the roadmap becomes a technology wish list with no customer attached.

The fusion is usually a budget decision dressed as an org design decision. That is fine at 40 people. It stops being fine somewhere around 100, and the cost of finding out is a failed hire plus the year it takes to notice.

‍

Four questions that tell you which role you are hiring

Ask these before the spec gets written, not after the slate comes back.

1. What broke in the last twelve months? Missed dates and attrition point to a VP of Engineering. Shipping the wrong things on time points to a Head of Product. Being unable to answer a board question about scale, security, or AI strategy points to a CTO.

2. Who does the hire talk to most in week one? If the honest answer is the board, customers, or an acquirer, you are hiring a CTO. If it is thirty engineers, you are hiring a VP of Engineering. If it is sales and support, you are hiring a Head of Product.

3. What is the longest decision they will make? A five-year platform bet and a two-week sprint priority require different people. Write down the single most consequential decision the hire will own. Its time horizon names the role.

4. Who is doing this job badly right now? Someone always is. Usually it is a founder, a first engineer, or a CEO absorbing the gap. Naming that person tells you what is actually missing, and it also tells you which internal relationship the new hire has to navigate on day one.

‍

The close

When the search fails, the post-mortem usually blames the hire. Look at the spec instead. Count the jobs in it.

If the answer is two, no candidate on that slate was going to work, and the strongest one would have failed slowest. Companies that get this right are not smarter about technology. They are just more honest about which single problem they have before they open the search.

‍

Worth a read if you are scoping a technical leadership hire, or trying to work out why the last one underdelivered. Contact us if you want to pressure test a spec before it goes to market.

‍