These three roles get conflated constantly. Founders conflate them because the titles sound similar. Recruiters conflate them because it expands the candidate pool. Boards conflate them because they appear interchangeable on an org chart. None of them are the same job, and hiring the wrong one for your stage is one of the more expensive mistakes I see repeated across the companies I work with.
Here is my attempt at a precise separation — what each role actually does, when you need it, and how to avoid paying for capability you don't need yet.
The Definitional Problem
The confusion starts with how these titles are used in job descriptions. A "CTO" at a 12-person startup and a "CTO" at a 3,000-person enterprise are doing almost entirely different jobs. A "VP Engineering" at a Series B company and a "Chief Architect" at a post-IPO technology company have similar-sounding titles but opposite leverage points.
Let me define each role by its primary output — not its responsibilities list, which is always too long to be useful.
CTO: The primary output is technology strategy aligned to business strategy, and a leadership organisation capable of executing it.
VP Engineering: The primary output is reliable, predictable engineering delivery — teams that ship on time, at quality, within budget.
Chief Architect: The primary output is architectural coherence across systems — preventing the platform from fragmenting into a collection of disconnected, mutually-incompatible subsystems.
These are different levers on the same machine. The question is which lever your company most needs pulled right now.
The CTO: Strategy, Credibility, and People Architecture
The CTO's job is to make sure the company's technology choices serve its business ambitions — and to build the leadership layer that makes execution possible.
At an early stage, this means being the person who can explain the technical architecture to investors in the board meeting, define the hiring standard for senior engineers, decide whether to build or buy, and determine which technical debts are existential and which can wait. The CTO is the one accountable for all of these, even if they're not personally executing most of them.
A CTO who is primarily coding is not doing their job. That is a hard statement, but I believe it. At 15–40 engineers, a CTO who spends more than 20% of their week on individual technical output is almost certainly under-investing in the things only the CTO can do: recruiting, investor relations, architectural direction, and building senior leaders who can run teams without them.
When you need a CTO
- You have technical co-founders but no senior engineering leadership that can operate independently
- You're raising capital and need credible technical representation at board level
- Your technology strategy is not clearly connected to your business roadmap
- You're about to make a major architectural decision — cloud provider, platform approach, data architecture — with multi-year consequences
- Engineering hiring is stalling because there's no senior technical brand or defined engineering culture
When you don't need a full-time CTO yet
- You have fewer than 8 engineers and a capable technical co-founder who is still writing code and comfortable doing so
- You're pre-product-market-fit and execution speed matters more than strategic coherence
- A Fractional CTO can cover the strategic function at a fraction of the cost while you find your footing
The VP Engineering: Delivery, Reliability, and Management Depth
The VP Engineering's job is to make the machine run reliably. Where the CTO is pointing the direction, the VP Engineering is ensuring the organisation actually gets there — consistently, predictably, at quality.
This is primarily a delivery and people management role. The VP Engineering runs the engineering management layer, owns the delivery metrics (DORA, sprint predictability, incident rates), resolves resourcing conflicts between teams, manages the engineering budget, and builds the management pipeline.
The VP Engineering does not set technology strategy. A VP Engineering who is also doing CTO work — making architectural decisions, representing technology at the board, setting the multi-year technical roadmap — either doesn't have a real CTO above them or is doing two jobs and doing neither well.
When you need a VP Engineering
- You have more than 40–50 engineers and multiple teams with separate roadmaps that require coordination
- Delivery predictability is poor — sprints miss consistently, incidents are frequent, teams are blocked on dependencies
- Your CTO is spending too much time on management escalations and not enough on strategy
- Engineering managers need a manager — someone who coaches them, sets expectations, and holds them to delivery standards
When you don't need a VP Engineering yet
- You have fewer than 40 engineers — at this stage, the CTO can typically carry both strategy and management oversight directly or through a small number of direct reports
- You're hiring a VP Engineering to solve a culture or leadership problem that actually needs to be addressed at the CTO or co-founder level — a VP Engineering cannot fix a broken leadership culture; they inherit it
The Chief Architect: Coherence at Scale
The Chief Architect is the most misunderstood and most prematurely hired of the three.
The Chief Architect's job is to maintain technical coherence across a large, distributed engineering organisation — to ensure that teams working independently on different domains are building on compatible foundations, using shared patterns, and not creating integration debt that will cost six figures to unwind later.
This role exists because, above a certain scale, individual teams optimise locally and the platform degrades globally. Team A builds a microservice with one authentication approach. Team B builds a different microservice with a different approach. Team C needs to integrate both and discovers that neither follows the patterns established in Team D's platform layer. The Chief Architect is the person who prevents this from becoming normal.
When you need a Chief Architect
- You have more than 150–200 engineers across multiple product domains
- You have a platform team and multiple stream-aligned product teams, and architectural drift has become measurable — systems don't interoperate, shared components don't get adopted, every team reinvents authentication
- You're running a significant legacy modernisation programme where architectural direction needs dedicated ownership
- Your CTO is spending more than 30% of their time on architectural review because there is no one else trusted to do it
When you don't need a Chief Architect
- You have fewer than 100 engineers — at this stage, architectural coherence should be maintained through an Architecture Decision Record (ADR) process, a Principal or Staff Engineer, and CTO involvement. You don't need a dedicated role.
- You're thinking of creating a Chief Architect because your most senior engineer asked for a title upgrade. That is a compensation and recognition problem, not an organisational design problem.
Role Mapping by Stage
This is how I think about which roles are load-bearing at each stage:
| Stage | Engineers | Load-Bearing Role | Optional / Premature |
|---|---|---|---|
| Pre-Seed / Seed | 1–10 | Technical co-founder or Fractional CTO | VP Eng (premature), Chief Architect (premature) |
| Series A | 10–30 | CTO (fractional or full-time) | VP Eng (can wait), Chief Architect (not yet) |
| Series B | 30–70 | CTO + first engineering managers | VP Eng becoming necessary, Chief Architect premature |
| Series C / Growth | 70–150 | CTO + VP Engineering | Chief Architect still optional |
| Late Growth / Scale | 150+ | CTO + VP Engineering + Principal/Staff Eng | Chief Architect justified if drift is measurable |
| Enterprise | 300+ | All three roles, potentially separated by domain | Multiple VPs, domain CTOs |
The sequencing of load-bearing roles by stage looks like this:
The most expensive mistake is hiring ahead of the curve. A Chief Architect at 60 engineers creates work to justify their existence. A VP Engineering at 20 engineers adds bureaucracy where speed matters more. A full-time CTO at 6 engineers consumes budget better spent on engineers.
The Overlapping Failure Modes
There are three specific failure modes I see regularly that come from conflating these roles.
The Architect-CTO mismatch: A technically brilliant engineer who loves systems architecture is promoted or hired into the CTO seat. They thrive on the architectural decisions and disengage from the board-level communication, investor relations, and people architecture work. The company gets excellent architecture and no technology strategy. The board is frustrated. The CTO is confused about why.
The VP-CTO confusion: A VP Engineering is hired at Series A to "run the engineering team," but there is no CTO. The VP Engineering defaults to doing delivery management — which they're good at — without anyone doing strategy. The company ships reliably in the wrong direction.
The Chief Architect as consolation prize: A founding engineer is passed over for the VP Engineering role (the right call — they're a better technologist than people leader) and compensated with the Chief Architect title. There is no mandate, no decision authority, and no organisational design to make the role effective. It becomes advisory in the worst sense: present in every meeting, ignored in every decision.
Title inflation is a real cost
Creating a Chief Architect title to retain a valued engineer is understandable. But if the role doesn't have clear decision rights, a meaningful scope, and a defined interaction model with the VP Engineering and CTO, you're not solving a retention problem — you're deferring it. The engineer will eventually notice that the title is decorative, and you'll have the same retention problem plus a poorly-designed org structure.
The Practical Test
Before hiring for any of these roles, ask three questions.
First: what is the specific, measurable problem this role will solve in the next 90 days? If you can't answer this, you're hiring out of anxiety, not strategy.
Second: does this problem actually require a full-time senior hire, or can it be addressed by a Fractional CTO, a strong Principal Engineer, or a structural change to how existing leaders operate?
Third: if you hired this person and they were excellent, what would be different in 12 months that isn't different today? If you can't describe concrete outcomes, the role is not yet defined well enough to hire for.
The CTO, VP Engineering, and Chief Architect are three distinct roles with three distinct leverage points. Getting the sequencing right — bringing in the right role at the right stage — is one of the highest-leverage decisions a founder or board can make. Getting it wrong doesn't just waste a salary. It shapes the organisation's capability in ways that take years to correct.
The fractional option is underused at Series A
At Series A, most companies need the strategic function of a CTO — board representation, technology roadmap, senior hiring standard — but not yet the management depth of a full VP Engineering. A Fractional CTO covers the first for 20–30% of the full-time cost and leaves budget for the engineers who actually build the product. When the organisation grows to need a full-time CTO, you have a much clearer picture of what that role should look like.
If you're navigating a senior technical hire and want a second opinion on what role your stage actually needs — or if you're working through the question of whether a Fractional CTO might cover the gap at lower cost — let's talk. Book a 30-minute discovery call and we'll figure out the right structure for where you are now.