Most startups get this wrong in the same direction: they hire a strong engineering manager, call them CTO, and then wonder why nobody in the room can answer an investor's question about build-vs-buy on the core platform, or why the security questionnaire for an enterprise deal sits untouched for three weeks.
The titles get used interchangeably because, at ten engineers, one person genuinely does both jobs. The failure shows up later, when the company has grown but the org chart hasn't caught up to it.
The one-sentence version
A Head of Engineering is accountable for shipping what's already been decided. A CTO is accountable for deciding what should be built, bought, or killed, and for representing that judgment to people outside engineering: the board, investors, enterprise security reviewers, and sometimes regulators.
Delivery versus direction. Bounded risk versus unbounded risk. That's the whole split.
What each role actually owns
Head of Engineering owns:
- Sprint planning, velocity, and delivery predictability
- Hiring and managing the engineering team day to day
- On-call rotation, incident response, code review standards
- Technical execution of a roadmap someone else set the priorities for
- Internal engineering culture: how code gets reviewed, how debt gets paid down, how onboarding works
- Architecture decisions with multi-year consequences: monolith vs services, which cloud, which data model, when to take on technical debt on purpose
- Build vs buy calls, especially the expensive ones: do you build your own auth, your own billing, your own ML pipeline, or license it
- Technology risk that faces outward: what you tell a Series B investor about scalability, what you tell an enterprise buyer's security team about your architecture, what you tell the board when a vendor gets breached
- Vendor and platform bets that lock you in for years
- The technical narrative in fundraising and M&A diligence
Why companies conflate the two
At pre-seed and early seed, there's no case for two roles. One technical leader plans the quarter, writes code, hires the first few engineers, and also fields the occasional investor question about the stack. Giving that person the CTO title isn't wrong. It's accurate to what the company needs.
The conflation becomes a problem once the company crosses roughly 15-30 engineers, or once it starts selling into enterprise accounts with real security review, or once it raises a round large enough that the board expects someone to own technical strategy as a standing agenda item, not an occasional aside. At that point the job splits whether or not the org chart admits it, and one half usually loses.
The pattern I see most often: the technical leader keeps doing what they're good at and comfortable with, which is delivery, because it has visible daily feedback. Sprints ship, standups happen, the backlog moves. Direction-setting work, architecture reviews, vendor evaluation, the security questionnaire, gets deferred because it has no daily deadline and no visible cost until it does. Then a fundraise or an enterprise deal forces the question, and the gap is suddenly a fire.
How to tell which one you need right now
Ask three questions.
1. Is your near-term problem "we know what to build but we're not shipping it fast enough," or "we don't know what we should be building"? The first is a delivery problem: hire a Head of Engineering or promote your strongest lead into that role. The second is a direction problem: you need a CTO, and if you can't afford a full-time one yet, a fractional CTO closes that gap for less than a full-time hire while the direction question gets settled.
2. Does anyone outside engineering, a board member, an investor, an enterprise prospect's security team, need a credible technical answer from your company in the next two quarters? If yes, someone needs to own that conversation as a real responsibility, not a favor they do between sprints. That's a CTO function even if it's fractional.
3. Would losing your current technical lead for a month break delivery, or break direction? If the answer is delivery, you already have a de facto Head of Engineering wearing a CTO title, and you should say so out loud before a fundraise makes you say it under pressure.
The two-hire company
Above a certain size, most companies end up needing both roles filled, not one person straddling them. The CTO sets architecture, owns the technology risk conversation with the board and investors, and makes the build-vs-buy calls. The Head of Engineering (sometimes titled VP Engineering) runs delivery against that direction: hiring, sprints, on-call, code quality.
This isn't a hierarchy question so much as a division-of-attention question. A CTO who's also running daily standups for twenty engineers will let architecture decisions drift by default, not by choice, because delivery has a deadline every two weeks and architecture doesn't have one until it's too late. A Head of Engineering asked to also own the board conversation about technical risk will either under-prepare for it or let delivery slip while they prepare. Neither failure is a competence problem. It's a bandwidth problem baked into the two jobs pointing in different directions.
If you're a founder trying to figure out which one to hire first, or whether you need one person, two people, or a fractional CTO alongside a Head of Engineering you already have, that's a stage-and-risk question, not a title question. Get the stage and the risk profile right and the org chart follows.
Need help thinking this through? Book a 30-min call, no pitch.
Need help thinking this through? Book a 30-min call — no pitch. Book a Free 30-Min Strategy Call →
