Most founders ask this too late. Some ask it too early. Here's how to know the difference.
You've built product-market fit. Revenue is growing. Your VP Engineering is running the team hard and it's working-but you're starting to see cracks. Code review cycles are slowing. Technical debt is accumulating faster than you can address it. The VP Eng is good at building teams, but strategy conversations with your board are becoming awkward because no one is clearly owning the technical roadmap.
That's when the question surfaces: "Do we need a CTO?"
The honest answer is: it depends on what you actually need.
The Inflection Point
There are three distinct phases in a tech company's leadership structure:
Phase 1: Founder as CTO (0–20 engineers)
You're building the product. You're hiring engineers. You're making architecture decisions in Slack. The role is implicit-you do it because no one else is.
Phase 2: VP Engineering takes over (20–80 engineers)
You hire a VP Eng. Their job: build teams, manage delivery, own hiring, establish processes. They report to the CEO. They're brilliant at scaling people.
This works until it doesn't.
Phase 3: You need both (80+ engineers, or earlier if strategy is fractured)
The VP Eng is running the machine. But the machine is building the wrong things, or building them inefficiently, or you're losing institutional knowledge because no one is owning the long-term technical vision.
That's when you need a CTO.
The 80-engineer figure is a pattern I've seen hold across several growth-stage companies - it's the point where a VP Eng is typically fully consumed by people management and delivery operations, leaving no one to own technical direction. I've seen companies hit this at 40 engineers when technical debt accumulated early; others never hit it at all because the VP Eng had the range to hold both. Treat it as a signal to re-examine, not a threshold to act on automatically.
The inflection point isn't always about company size. Sometimes it's earlier - when your technology is a competitive moat, or when you're making bets on AI or cloud architecture that will define the next 3 years. Sometimes it's later, or never - if your business is fundamentally not technology-driven.
The right time to hire a CTO is when technical strategy becomes inseparable from business strategy. Not when it's convenient. When it's necessary.
Full-Time CTO vs Fractional vs Consultant
Here's where most founders get confused. There are three distinct options, and they solve different problems.
Full-Time CTO
- Reports to CEO
- Owns long-term technical vision and architecture
- Responsible for hiring, retention, culture of engineering org
- Accountable for delivery AND technical quality
- Usually part of board-level conversations
- Compensation: £150k–£300k + equity (depending on stage and location)
Fractional CTO (Part-Time / External)
- 10–20 hours/week, typically 3–6 month engagements
- Focuses on: architecture reviews, technical roadmap, hiring strategy, org design
- Does NOT manage day-to-day delivery or run standup
- Reports to CEO or founder (not to the VP Eng)
- Bridges the gap between "we don't have capacity to think strategically" and "we're not ready for a full-time hire"
- Cost: £8k–£20k/month depending on scope
Technical Consultant / Advisor
- 1–5 hours/week, usually ad-hoc
- Focused on: specific problems (cloud migration, scaling challenges, AI strategy)
- Does NOT own the roadmap or hiring
- Cost: £2k–£5k/month or project-based
The mistake most founders make is hiring a full-time CTO when they actually need a fractional engagement, or vice versa.
If your problem is "we need someone to own the roadmap" - fractional CTO.
If your problem is "we need someone to run the engineering function at board level" - full-time CTO.
If your problem is "we need expert input on this specific technical decision" - consultant.
What You Actually Need a CTO For
Not every company at 50 engineers needs a CTO. Some do. Some don't. Here's the diagnostic.
You probably need a full-time CTO if:
- Technical architecture is a competitive moat (you can articulate why your technical approach matters to customers)
- You're making multi-year bets on infrastructure (cloud platform, AI native stack, data infrastructure)
- Engineering team is >60 people and fragmented across multiple teams/domains
- Your VP Eng is hitting a ceiling - great at managing people, less confident on technical vision
- Board is asking about scalability, debt, or long-term technical strategy
You probably need a fractional CTO if:
- You have a solid VP Eng, but no one is owning architecture and technical roadmap
- You're 30–60 engineers and want to avoid the chaos that hits 60–80
- You're making a big architectural bet (cloud migration, AI integration) in the next 6–18 months
- You need external credibility on technical decisions (hiring security expertise, AI talent, infrastructure specialists)
When You Should NOT Hire a CTO
This question gets asked less often than it should. Hiring a CTO when you don't need one creates reporting confusion, burns equity on a role with unclear scope, and often creates a political problem between the new CTO and your existing VP Eng.
Skip the hire - full-time or fractional - if:
- Your VP Eng has the technical range. Some VP Engs are strong architects as well as people managers. If yours can credibly own both the roadmap and the org, you have a CTO in everything but the title. Adding another layer doesn't help - it creates confusion about who owns what.
- Technology is not your moat. If you're building workflow software or a vertical SaaS where differentiation lives in the domain knowledge, not the architecture, your technical needs are execution-focused. A VP Eng and good engineers is the right structure - a CTO role optimized for technical vision adds cost without value.
- A technical founder is still active. If a founder with strong technical instincts is still involved in architecture decisions, adding a CTO risks either sidelining the founder or giving the new hire a role with no real authority. Clarify which one is true before hiring.
- You're using the hire to fix a people problem. "Our VP Eng isn't working out" is not a reason to hire a CTO - it's a reason to fix or replace the VP Eng. A new CTO inserted above a struggling VP Eng creates hierarchy, not resolution.
- You're pre-product-market fit. Before PMF, the CTO title belongs to a founder or the most technical person building. Hiring a strategic CTO before the product direction is clear is premature - they'll have nothing concrete to own.
The tell: if you cannot write a one-sentence answer to "what specific problem does this person solve that isn't already covered?" - you don't need the hire yet.
Red Flags That You're Hiring Wrong
I've seen founders make these mistakes repeatedly:
Hiring a full-time CTO to fix a broken VP Eng situation
If your problem is "the VP Eng isn't scaling" - hiring a CTO doesn't solve it. You need a different VP Eng. Now you have two executives fighting for influence.
Hiring a fractional CTO as a band-aid for missing leadership
Fractional works if you have a strong foundation. It's not a substitute for functional leadership. If your team is chaotic, an external person 15 hours/week won't fix it.
Hiring for the role instead of the problem
CTO is not a job title. It's a set of responsibilities. Define what you actually need, then hire for it. Sometimes that's "technical visionary." Sometimes it's "architect who can mentor." Sometimes it's "operations expert who can put processes in place." Don't hire a CTO because you think you should-hire one because you have a specific problem a CTO solves.
What to Look For in a CTO
This is where founders usually go wrong. They hire resume credentials instead of fitting capability.
Essential signals (non-negotiable):
- Has scaled engineering teams (has been through the 20→50 and 50→100 transitions)
- Has made architectural decisions that stuck (and can articulate why)
- Understands the tradeoff between technical purity and business velocity
- Can talk to boards and investors without getting defensive about technical choices
Critical questions to ask:
- "Tell me about a technical decision you made that you now regret. What would you do differently?"
- "Describe a situation where you hired the wrong person into your engineering org. How did you handle it?"
- "What's the biggest piece of technical debt you've ever dealt with? How did you approach it?"
- "Walk me through a conflict between technical purity and shipping faster. How do you make that call?"
Red flags:
- Cannot articulate business impact of their technical decisions
- Views engineering as purely technical (misses the people/org side)
- Has only worked at large, well-resourced companies (may not understand founder constraints)
- Speaks in acronyms and frameworks instead of first-principles thinking
The First 90 Days
This matters more than most people think. A good CTO's first 90 days should follow this arc:
Days 1–30: Listen and observe
- 1-on-1s with every engineering leader (not just the VP Eng)
- Code review sessions - what are they actually debating?
- Operational check-in - incident patterns, deployment frequency, how decisions get made
- Board materials review - what's the story the company is telling about technical progress?
Do not make changes. Not yet. Listen.
Days 31–60: Diagnose and align
- Write a technical state assessment (5–10 pages, shared with CEO and VP Eng)
- Identify the 3 highest-impact technical decisions in the next 12 months
- Clarify the boundary between your role and the VP Eng's role (critical to get right)
- Start hiring (if there's hiring to do)
Days 61–90: Execute small wins
- Make one architectural recommendation that lands in the next sprint
- Unblock a hiring bottleneck (maybe bring in specialists you know)
- Address one piece of technical debt that's been haunting the team
- Present the 12-month technical roadmap to the board
The goal of Day 90 is not "have changed everything." It's "the team trusts you, understands your vision, and has seen you solve one real problem."
The Cost Reality
This is uncomfortable but necessary.
Full-time CTO (London/UK-based):
- Early stage (pre-Series B): £120k–£180k base + equity
- Series B–C: £180k–£250k base + equity
- Series C+: £250k–£300k+ base + equity (can go higher)
US comparison: Stage-equivalent US base salaries run higher — pre-Series B $150K–$200K; Series B–C $200K–$300K; Series C+ $250K–$400K. Total compensation at funded companies (base + bonus + equity) can exceed $600K, particularly in AI, fintech, and infrastructure. The UK/US base gap has been compressing for senior technical roles: London and New York increasingly compete for the same CTO candidates, and London commands a 15–25% premium over other UK cities in those sectors.
Fractional CTO (London-based, 15–20 hrs/week):
- £10k–£18k/month (£120k–£216k/year equivalent, prorated)
- Usually 3–6 month minimum engagement
What affects the range:
- Stage and funding (more certainty = lower ask)
- Industry and technical complexity (fintech, AI, infrastructure = higher end)
- Geographic location of company (London > other UK cities; remote globally shifts expectations)
- Whether equity is included (vesting schedule matters)
A note: if you're at Series A with £500k–£2M revenue, a fractional CTO often makes more sense than a full-time hire. You get strategy and credibility without the fixed cost. Once you hit £3M+ ARR and have clear 3–5 year vision, full-time usually pays for itself.
But this depends entirely on your technical complexity and competitive strategy. Don't use cost as the deciding factor.
The question isn't "do we need a CTO?" The question is "what problem are we actually trying to solve, and is a CTO the right solution?"
If your VP Eng is solid and you need architecture + vision = fractional CTO.
If your VP Eng is running the team and you need someone at board level owning technical direction = full-time CTO.
If you're just unsure and want external validation = consultant.
Make the call based on the problem, not the title.