A founder's guide to deciding whether a Series A or B startup needs a CTO or a VP Engineering first: the real signals, the mistake DeepTech founders make most often, and what changes at Series B.
The question "CTO or VP Engineering first?" is usually asked as a title decision when it's really a needs decision: does the company need a technical co-founder-level thinker who sets direction, or an operator who scales a team that already has one? At Perpetuate Talent, we watch founders get this wrong in both directions, almost always because they opened the wrong search instead of picking the wrong person.
Here's what each role is actually for at Series A/B, the signals that tell you which to open first, the mistake we see most often in DeepTech and HardTech searches, and what changes once you're raising a Series B and the answer becomes both.
Strip away the title and look at what the two jobs actually do at a company still finding its shape.
A CTO at this stage is still making the multi-year technical bet: which architecture, which platform, build versus buy, which frontier technology the company is willing to stake the product on. They often still code, not out of nostalgia but because the hardest problem in the company is usually still a technical one, and someone has to be close enough to it to be right. Investors and your most senior engineers need to trust that this person can say "here is where the hard problem is, and here is how we solve it" and mean it.
A VP Engineering doesn't usually invent that direction. They take a direction that already exists, set by a technical co-founder or an existing CTO, and build the machine that ships against it: the hiring plan, the delivery cadence, the on-call rotation, the promotion ladder. Their job is throughput and reliability at headcount, not invention.
Sets the direction, often still codes
Best fit: the technical roadmap is still genuinely open, and the company needs someone with the standing to make and defend the hard bet.
Runs the machine that ships
Best fit: the direction already exists, and the team has outgrown what one person can manage day to day.
Three things tell you which role to open, and none of them is the org chart you've seen at a company you admire.
Team size. Below roughly ten engineers, direction is usually still ambiguous enough that you need someone who can set it; an executor hired against a plan that doesn't exist yet just produces a confused first quarter.
Whether product-market fit is found. Pre-PMF, the technical roadmap is still being invented alongside the product itself. Post-PMF, you're mostly repeating a proven technical playbook at volume, which is an operating problem, not a direction problem.
Whether the founder is still the de facto technical lead. If a founder or co-founder is currently making every hard technical call personally and it's becoming the bottleneck, that's a CTO gap. A VP Engineering hired into that vacuum has nothing to execute against and will spend two quarters guessing.
Four Questions Before You Write The Brief
Founders hire a VP Engineering title onto someone who is really operating as CTO-lite: an operator skillset, real process discipline, but no genuine conviction about the hard technical bet, quietly making architecture calls that no one with the standing to catch a wrong one is checking. The reverse happens too. A founder hires a CTO whose real strength is vision and architecture into a company that actually needs someone spending most of the week on hiring plans and delivery cadence, and within two quarters that person is bored, underused, or re-architecting something that already worked because that's the itch they know how to scratch.
This mistake is more expensive in DeepTech and HardTech than almost anywhere else, because the technical bar is the moat itself. A generalist VP Engineering hire without real domain depth in sensor fusion, precision hardware, or frontier data systems doesn't just slow delivery down. They can quietly approve a technical approach that doesn't work at all, and nobody realises until the product is built on it.
Empowered engineers are the single most important thing you can have in a product company.
Perpetuate Talent, on what actually matters
We hold to that line as an operating principle, and it only works when the person setting technical direction and the person running the team are actually matched to the job in front of them. Put a scaler where you need a visionary, or a visionary where you need a scaler, and you get the opposite of empowered engineers: a team executing against a plan nobody fully believes in.
That first mismatch also outlives its own tenure. Every early technical hire is an act of company design as much as a staffing decision: the standard set at CTO or VP Engineering is the standard the next ten engineering hires get measured against, and a compromise made once at the top is far more expensive to undo once a team has already been built underneath it.
Somewhere around Series B, most DeepTech and HardTech companies scaling toward that $10M to $50M ARR range stop being able to ask one person to do both jobs. The technical direction keeps evolving, new frontier bets, new scale requirements on data and compute, at the same time the team has grown past what one person can run day to day. That's the point where vision and operations split formally: a CTO focused on where the next eighteen months of hard technical work goes, and a VP Engineering running the org that ships it.
Companies that resist this split past Series B tend to fail in one of two directions. Either the CTO is still trying to run standups and the technical roadmap stalls because there's no time left to think about it, or the VP Engineering is quietly making architecture-scale calls with no technical air cover for decisions that size.
Searching for a CTO looks nothing like searching for a VP Engineering, and treating them as the same search with a different title is how founders end up interviewing the wrong shortlist. A CTO search pattern-matches on vision: has this person made a genuinely hard multi-year technical bet before, were they right, and can they hold their own with your board and your most technical hires? A VP Engineering search pattern-matches on scaling: have they taken an engineering org through a real headcount inflection without the wheels coming off, and are they comfortable executing someone else's vision rather than needing to own it?
It's why we run these as genuinely separate searches, not one job spec with two acceptable answers. For DeepTech and HardTech specifically, the pool of people who can credibly set direction in a narrow technical domain is much smaller than the pool of strong engineering operators. That gap is exactly what off-market, concentric-circle sourcing is built to close.
Yes, up to a real ceiling. Below roughly ten to fifteen engineers, and before the technical roadmap has hardened, a strong technical co-founder or early CTO can set direction and still run day-to-day delivery personally. Past that headcount, or once the technical bet is proven and the job shifts to execution, the two jobs compete for the same hours, and delivery is usually what gets starved.
Once you're running multiple engineering teams, you've passed product-market fit, and hard technical calls, new architecture, a new frontier bet, scaling data or compute, are still competing for time with running the org day to day. For the DeepTech and HardTech companies we work with, that's typically around Series B. Hire both roles then, rather than stretching one person across both jobs indefinitely.
Not sure which side of this line you're on? That's worth talking through before you write a brief for either role. Stephen Tung runs both kinds of search off-market through the Talent System™ as part of our Technical Leadership Search practice. Message Stephen on LinkedIn → and talk through your stage and team.