Not all CTOs are created equal

The CTO title is one of the least useful in technology, because it hides several materially different jobs behind the same three letters. I have hired CTOs, I have been a CTO, and I have watched founders make expensive mistakes at both ends of the problem: hiring too senior too early, or waiting too long and ending up inside the kind of technical chaos that is much harder to clean up afterwards.

What founders need before recruiting is not a generic picture of a CTO. It is a clear understanding of which CTO their company actually needs.

---

The problem with the title

The title means completely different things at different stages. In a startup of five to twenty people, a CTO makes architecture decisions daily, unblocks engineers who are stuck, talks to customers when needed, evaluates technology choices as they come up, connects the founders with the hardware and software teams, and makes near-continuous trade-offs across all of it.

In a five-hundred-person company, the CTO sets long-term vision, manages directors, speaks at conferences, sits in board meetings, and operates almost entirely at the strategy level.

The title is the same. The job is wildly different. When a pre-Series A founder tells me they are looking for a CTO, my first question is usually which of these jobs they think they need.

---

Three types of CTO, and when each one fits

Type 1: the systems architect CTO (1 to 15 people)

At this stage a CTO is designing system architecture across disciplines (typically electronics, mechanical, firmware, software and cloud, depending on the product), making rapid technical decisions without ever having complete information, and unblocking engineering teams when they hit something they cannot resolve themselves. They connect the dots between market needs, hardware constraints and software possibilities, select technologies and vendors as the work progresses, guide a team of two to fifteen engineers across several disciplines, and make the constant trade-offs between speed, quality and cost that an early-stage company demands.

What this CTO is not doing, whatever some founders expect, is writing production code every day (that is what the engineers are for), personally designing circuit boards and CAD models, implementing every feature, or trying to out-code the best engineer in the building. Trying to do those things is usually a sign that someone has been miscast.

People who fit this role come from varied backgrounds. Former CTOs with startup or scale-up experience are the obvious source. So are senior engineers who have worked across several disciplines, technical leads who have integrated complex systems, people who have shipped hardware-and-software products end-to-end, former consultants who have solved a wide range of technical problems for clients, and engineers who have grown into systems thinkers over time.

The red flags are consistent: a deep specialist in one area who is blind to the others, someone who cannot translate fluidly between disciplines, someone who must do all the work personally because they cannot delegate or guide, or someone who talks more about their coding prowess than their systems thinking.

Most early-stage companies need this profile. They do not yet have product-market fit, and they need someone who can see the whole system, make sensible architecture decisions across disciplines, and guide engineers without micromanaging them. What they do not need, contrary to instinct, is another engineer. They need someone who connects all the engineers into something coherent.

Type 2: the scaling CTO (20 to 100 people)

The scaling CTO has a different brief. The daily work centres on building engineering culture and the cross-functional processes it depends on; hiring and structuring teams across disciplines; balancing the persistent tension between technical debt and new features; setting consistent standards and patterns across firmware, electronics and software; guiding technical decisions without being directly involved in the details; connecting engineering with product, manufacturing and the business; and helping to inform business strategy so that the technology strategy can deliver it.

People who do well here usually come from a few places: experienced CTOs who have scaled teams before, engineering directors from mid-sized companies who have outgrown their remit, or technical leaders who have shown they can manage real complexity without losing their grip on technical reality.

The red flags are different in character but no less important. Pure managers with weak technical understanding will struggle. So will people who have been too far removed from the work for too long to evaluate technical trade-offs any more. People who only know big-company processes and will not adapt are another familiar failure mode.

Some Series A companies need this CTO precisely because they have just found product-market fit and must now scale delivery. That needs someone who can build team structure, hire across disciplines and manage growing operational complexity. But these companies are not tech giants. They still need someone who understands the underlying technical reality, not someone who has retreated entirely into management.

Type 3: the strategic CTO (100+ people)

The strategic CTO works at a different altitude: setting long-term technology vision and strategy, representing the technical perspective at board level, managing VPs and directors rather than engineers, making major build-versus-buy decisions, thinking two to three years ahead of where the company is, and partnering with the CEO on the direction of the company as a whole.

People in this role typically come from one of three backgrounds: CTOs who have scaled successful larger companies, senior leaders from substantial businesses, or strong operators who have shown strategic thinking as well as operational delivery.

The risks are distinct. They can lose touch with technical reality if they spend too long in board rooms and not enough in engineering reviews. They may struggle to engage meaningfully with engineers. They sometimes bring unnecessary complexity. And they are generally a poor fit for the chaos of an early-stage company. Most startups do not need this profile yet, and hiring one too early is likely to leave both parties frustrated and out of pocket. This hire is generally better saved for Series B and beyond.

---

The expensive mistakes I have seen founders make

Hiring a specialist when the company needs a systems integrator

A founder hires an obviously talented engineer and gives them the CTO title, assuming brilliance in engineering will translate into broader leadership. The new CTO is genuinely impressive at the engineering. But the teams underneath start making decisions that work for their own disciplines and break the overall system requirements. Nobody is connecting the disciplines, and when the product finally emerges it does not work as a coherent system, even though each piece looks fine on its own.

The cost tends to be six to twelve months of disconnected engineering, a series of expensive redesigns once the integration problems surface, and missed launch dates as the effects compound.

Expecting the CTO to be the best engineer at everything

A founder expects the CTO to out-code the software engineers, out-design the electronics engineers and out-model the mechanical engineers, all at once. The CTO either tries to do all of it and quietly burns out, or the team gradually loses respect for them because they are inevitably mediocre compared with the specialists in each domain.

A CTO's value does not come from being the best coder in the building. It comes from seeing how everything fits together. The electronics engineer should be better at electronics than the CTO. The CTO needs to be better at connecting them all, and that is a different skill, not a more advanced version of the same one.

Hiring a pure manager who cannot evaluate technical decisions

The founder hires someone whose CV says they "managed engineering teams" at a large company, assuming management capability is what is needed. The new CTO runs meetings competently, writes OKRs beautifully and produces a polished operational rhythm. What they cannot do is judge whether the firmware architecture makes sense, whether the cloud cost profile is reasonable, or whether the mechanical design will cause expensive manufacturing problems later.

The engineering team loses respect for the role and starts making its own technical decisions in parallel. Bad technical decisions compound silently. By the time anyone realises the architecture is wrong, the team has usually built so much on top of it that unwinding the original mistake is genuinely expensive.

---

What great early-stage CTOs actually look like

Some things founders obsess over are not, in my experience, what makes an early-stage CTO effective. Being the best coder on the team is not essential. Nor is being able to design a circuit board from scratch, or a CV that includes a stint at a famous tech company. What matters is a different set of characteristics, and the great ones share them even when their career paths look quite different on paper.

They have worked across disciplines. Some started in firmware, moved into software and worked on integration projects along the way. Others designed hardware in roles that demanded close software collaboration, and absorbed enough of the software perspective in the process. The path matters far less than the breadth it produces, and the pattern recognition that comes with it: an instinct of "I have seen this problem before in a slightly different context" that becomes the foundation for sound judgement under uncertainty.

They have shipped products, not just features. They have taken something from concept through manufacturing, deployment and ongoing support, and they understand the whole product lifecycle, not just the coding part. They can evaluate technology without implementing it themselves. They can look at a proposed firmware architecture and say "this will cause problems once we hit scale" without personally rewriting it. That ability to assess from the outside is what makes them useful at this level rather than at engineer level.

They make the engineers around them better. Not by doing the work for them, but by giving clear direction, unblocking them when they are stuck, and making the architectural decisions that let them execute against a coherent plan. They frame trade-offs in a way the team can use: "we could make this perfect, but it will take six months and cost two hundred thousand pounds; or we can get it good enough in six weeks for twenty thousand; here are the technical implications of each." The framing is the value, because it turns an abstract argument into a concrete decision the founder can make. They are pragmatic rather than ideological about technology, using whatever works in context rather than worshipping particular tools or stacks.

They think in systems, not components. They can see how the battery constraints affect the firmware, which affects the cloud architecture, which affects the user experience. Everything connects, and a CTO who cannot see those connections will reliably optimise one part of the system at the expense of the others.

---

The uncomfortable truth about "hands-on"

Founders often tell me they need a "hands-on CTO", and the phrase is worth being precise about. The wrong version is the founder who wants someone to write fifty per cent of the code. What they really want is an expensive senior engineer with a more prestigious title.

The right version is different. It is the CTO who dives into architecture problems when teams are stuck, reviews designs and catches issues before they become expensive, joins critical customer meetings to understand the technical requirements first-hand, evaluates vendor technology by testing it rather than reading the specifications, and sits down with marketing and sales to write objection-handling lines that reflect what the product can and cannot do. Hands-on in thinking and decision-making, not necessarily in daily implementation.

---

The alternative most founders do not consider

Most founders skip past an underused option when they start hunting for a CTO: a full-time one is not always the right answer. For many early-stage companies, part-time or fractional technical leadership works better than a permanent hire.

It tends to work in a particular set of circumstances. The business needs senior systems-level guidance, but not for forty hours a week. The company is at the £500k to £3m funding level, with somewhere between zero and fifteen employees across the engineering disciplines, and is still working towards product-market fit rather than scaling delivery. The engineers are capable individually but need someone to connect their work. And the founder wants to validate the technical direction properly before committing to a full-time hire.

The arrangement provides systems architecture across all the relevant disciplines, someone to unblock the engineering teams when they need it, strategic guidance without the full-time cost (typically two to five days a month is enough at this scale), the flexibility to scale the engagement up or move to a full-time hire later, and a perspective shaped by patterns seen across several specialisms and businesses rather than one.

What it does not provide matters just as much. There is no one in the office every day, and no one who will personally implement major features. Full-time availability for day-to-day questions is not part of the package, and trying to use a fractional CTO that way will fail quickly.

I have seen this work particularly well for hardware-and-software companies, IoT startups and robotics businesses: anywhere that is genuinely integrating several engineering disciplines and needs someone who can see the whole system, without yet being large enough to afford a full-time person in the seat.

---

Evaluating candidates in practice

Interviews on their own rarely surface what matters for this role. What works is supplementing them with a handful of practical tests that probe systems thinking directly.

The integration challenge

Give the candidate a real cross-discipline problem and watch how they think it through. For example: "The electronics team has designed a sensor array that generates 100MB per second of data. The firmware team says they can only process 10MB per second. The software team says they can handle the load in the cloud, but latency will run to two seconds. The customer needs a real-time response. What do you do?"

Watch for whether the candidate understands all the disciplines involved, asks sensible questions about the constraints and requirements before jumping to a solution, proposes responses that balance all the concerns rather than optimising for one, and knows when to bring in specialists rather than solving everything alone.

The architecture decision

Hand the candidate the company's actual product architecture (a hardware block diagram, the firmware structure, the software stack) and ask what they would change in the first three months if they joined today, and what they would deliberately keep.

Watch for whether they can understand a multi-discipline architecture from a cold start, spot real issues rather than cosmetic ones, respect what has been built while still seeing what could be improved, and make suggestions that are pragmatic and staged rather than a blanket rewrite.

The trade-off question

Pose a constraint problem: "You have three engineers (one electronics, one firmware, one software) and three months. Customers want feature X, but battery life is poor and needs optimisation. What do you do?"

Watch for whether the candidate asks the right questions about priorities and constraints before answering, frames the trade-offs clearly, thinks through the cross-discipline implications of each option, and reasons soundly even if you would have reached a different conclusion.

The "explain it simply" test

Ask the candidate to explain a complex technical concept relevant to your product (BLE, edge computing, battery management, or whatever applies). Listen for whether they can do it without retreating into jargon, use analogies and concrete examples, make it followable by a non-technical person, and adjust the explanation to the listener's evident level of understanding.

Warning signs

Across all of these tests, a few warning signs deserve heavy weight. A candidate who can only talk about one discipline will struggle in any role that requires translating between them. A candidate who dismisses the company's existing technical choices without first understanding the constraints behind them is signalling a kind of arrogance that does not age well. A candidate who insists on perfect processes before making any decisions will not survive the first month of early-stage work. And a candidate who talks about what they "managed" but cannot describe what systems they have actually architected is, more often than not, a manager who has forgotten how to do the work.

---

When each profile fits

When a full-time hire would be premature

The company is essentially pre-product, in which case it needs contractors building an MVP, not a CTO. Or there are one or two engineers executing well with clear direction who do not need a fifth wheel above them. Or the founder is technical and wants to stay hands-on in architecture. Or the company simply cannot afford a £100k-plus salary yet.

When a type 1 systems architect CTO fits

The company has three to ten engineers across several disciplines, and they are good but need someone to connect their work. Or the founder is non-technical and needs someone to own technology decisions. Or the founder is technical in one discipline but does not understand the others well enough to lead them. Or the teams are visibly making disconnected decisions that do not work as a system. Or the company is building hardware-and-software products that need deep integration across disciplines.

When a type 2 scaling CTO fits

The company has fifteen or more engineers. The existing systems architect CTO is drowning in people management that has grown beyond what they can handle alongside the technical role. The engineering processes need professionalising. And the business is at Series A or beyond, with real revenue.

When a type 3 strategic CTO becomes relevant

The company has fifty or more engineers, is at Series B or beyond, needs genuine board-level technical representation, and its technology is a competitive advantage that needs the long-term vision a strategic CTO is there to provide.

---

What I learned from watching a company hire itself into near-death

A few years ago I worked with a hardware-and-software company that had a clever product, strong early traction and a credible path to profitability within about eighteen months. It had bootstrapped its way to viability and was ready, on paper, to scale.

The founders did what seemed sensible. They hired experienced executives to take some of the operational weight: a COO from a mid-sized company, a Head of Product from a well-known brand, and a couple of senior managers described as having "done it before at scale". On paper these were good hires. In practice they nearly killed the company.

The dependency stack

The problem was not that these people were incompetent. It was that they had quietly lost the ability to function without the infrastructure they had always worked within. They were used to having a marketing team to run campaigns, an operations team to handle processes, a finance team to do the analysis, admin support for routine work, project managers to coordinate, HR to handle hiring, and IT to manage the systems. The company had effectively none of that: a handful of engineers, a couple of operational people, basic systems held together with spreadsheets and determination, and few established processes.

What happened next was, in hindsight, predictable. The senior hires could no longer do the basics themselves, because they had spent ten or more years delegating exactly those tasks. The COO needed an operations team to function. The Head of Product needed project managers and analysts. The senior managers needed coordinators. So they started hiring, not strategically but desperately, because they needed teams in place before they could do the senior parts of their own jobs.

How fast it went wrong

By the third month, headcount had doubled. None of the new hires were engineers building product. All of them were support functions, hired to backfill what the senior executives could not do themselves. By month six, the burn rate had roughly tripled, and there were still no operational foundations, because everyone senior was busy hiring their own team. By month nine, a company that should have been profitable in eighteen months was forecasting about four years to profitability. The executives had built the company they personally needed to operate in, not the company the business could afford.

The painful part was that none of them were malicious. They genuinely thought they were building a proper company and doing things right. But "right", for them, meant "the way it worked at my last company, with two hundred-plus people and a mature operational infrastructure". They could no longer write their own slide decks, analyse data in a spreadsheet, coordinate projects without a project manager, do market research without a research team, or make decisions without three layers of supporting analysis.

One senior hire told me, almost in passing, that they needed at least two analysts and a project manager to do their job properly. I asked what they had done before they had those roles reporting to them. There was a long pause. Then, with some honesty, they said they could not really remember; it had been fifteen years ago.

The cost

The board stepped in when it could see the trajectory, because the company was on course to run out of runway before reaching profitability, despite a viable product and real revenue. What followed was brutal in human terms: a major restructuring and redundancies. Several of the senior hires left, some voluntarily and some not. Headcount was cut by roughly forty per cent. The business went back to basics: a small team, lean operations, and a renewed focus on profitability rather than corporate structure. The original eighteen-month path to profitability became closer to four years because of the detour.

In total, the damage came to something like £1.5m or more burned on overhead that drove no revenue; roughly two and a half years of delayed profitability; team morale badly damaged by the hire-then-lay-off cycle; lost momentum in the market; strained relationships with the early employees who survived the cuts but watched colleagues go; and meaningful dilution of the founders' equity, because the company had to raise more money to survive the consequences of its own hiring.

The lesson

This changed how I advise companies, though it took me time to put it clearly. When a company hires senior people from big companies, it is not just hiring a person. It is inheriting their entire operational dependency stack. And the candidates may not realise they cannot function without the support they are used to.

The question is not whether they are experienced. It is whether they can operate without a big team underneath them. Some senior hires from big companies do adapt to early-stage environments. They remember what it was like to wear several hats and are excited to get back to building rather than managing. But many cannot, because they have delegated for so long that the underlying skills have atrophied. The awkward part is that they often do not realise it until they are in the role and starting to struggle.

What I now tell founders is this. Before hiring someone senior from a big company, ask them to walk you through a typical week, and to be specific about what they personally do and what their team does. Then ask: "We don't have a team for you yet, and for the first six months you would be doing all of this yourself. Are you comfortable with that?" In my experience, the reaction to that question is more revealing than most of the rest of the interview.

The better hires for early-stage companies tend to have mixed experience: some time at big companies, so they have seen how things scale, and more recent time at smaller ones, so they still remember how to operate lean. Player-coaches rather than pure managers.

The company did recover. It took about two and a half years longer than it should have, and the founders ended up with significantly less equity. The appeal of "experienced executives" is strong, especially for founders who feel out of their depth. But experienced at doing what? Managing big teams at mature companies is a completely different skill set from building foundations at early-stage ones, and confusing the two is one of the more expensive mistakes I have watched founders make. Hire for the stage the company is actually at, not the one it hopes to reach.

---

Four things worth taking seriously

For founders: before recruiting, decide which of the three CTO jobs you actually need. A systems architect, a scaling CTO and a strategic CTO are different hires, and the title alone will not tell candidates or recruiters which one you mean.

For boards and investors: when a company hires senior people from large organisations, ask what operational dependency stack comes with them. Experience at scale is not the same as the ability to build foundations.

For engineering leaders: judge a CTO by how well they connect the disciplines and frame trade-offs, not by whether they are the best engineer in any one of them.

For anyone interviewing for this role: use practical tests of systems thinking alongside interviews, and ask candidates plainly whether they are comfortable working without a team underneath them.

---

Which CTO does your company actually need right now, and is that the one you are recruiting for?