How the Startup CTO role evolves as the company grows

(this is part of a series on fCTOs and CTOs at startups, where some is similar as at established companies, but a lot is different)

As a jobtitle, “Startup CTO” is a misnomer – when a company becomes significant enough for its ‘CTO’ to be a genuine CTO, then it’s no longer a startup. But the term is a convenient label for a shifting set of roles/responsibilities common in startups that evolve into a more mainstream CTO role.

In this table the X’s mark the periods where each phase/element is critical to the company:

	Pre-seed	Seed	SeriesA	SeriesB
Founder	X	X
CTO			(partial)	X
VPEng		(partial)	X
Lead Engineer		X	X
Engineer	X	X

Are these all the same person? Sometimes! They certainly can be … and the less-experienced the founding team – or the less funded they are – the more likely it is … but usually they’re not. If your company is to grow, it has to scale, and scaling the headcount means specialising of roles, spreading of duties across more people, moving from ‘person in charge of X’ to ‘team in charge of X’ to ‘business-unit in charge of X’.

Let’s look at each element in turn and see why I’ve aligned them with the company-stages in the way I have. I’ll start with the ones for the smallest companies, and evolve our way up to the bigger companies.

“A startup is an organization formed to search for a repeatable and scalable business model.” – Steve Blank

The role: a Founder’s sole job is to Found something — to get from “pre-SeriesA” to “post-SeriesA”. All startups today are effectively tech companies (look how dependent they are on the internet), and tech startups desperately need a tech (Co-)Founder. There are plenty of counter-examples, but “Tech co-founder and Business/Commercial/Org co-founder” is the classic pairing beloved of investors and

The blanks: The individual may be hugely influential in the SeriesA/B/C journey – but their role has by then changed, they’re now (typically) a CxO first, and a Founder second. Founders had total freedom to run the company as they wished, and collectively had the controlling interest in shares – but giving your C-level execs such power is rare and counter to typical company-governance, and usually the Founders will have relinquished that power long ago in return for external investment.

The problems: a Founder mindset after SeriesA typically interferes too much from the top down, creates or sustains inefficiencies (they don’t tend to enjoy boring process, and often fight against it), and generally slows the company down.

The role: Engineers take product problems and craft solutions via technology. A small part of that is writing code – the majority is understanding the problem in enough precision that it can be explained/dictated to a (pre-AGI) dumb computer.

The blanks: When you only have 1 Engineer, or 1 in each discipline (Mobile, Front-End, Back-End, etc), then without each individual no complete, usable, product can be built. But when you’re an established company they become fungible, with turnover and replacements coming and going each quarter, teams ramping up and ramping down. Hence the fear of so many to become ‘cogs in the machine’.

The problems: If you have individual Engineers calling the shots in a post-Startup company then your company is not being run by the CEO (who’s paid a huge amount of equity and/or cash), but by someone on the ground floor who’s operating with near-zero knowledge of the business context the company operates in. Typically Engineers are logical and smart; given the full context they can make brilliant deductions and decisions – but when operating with only a fraction of the context their decisions become random, heavily biased, and often counter-productive.

The role: Traditionally someone with 3-5+ years experience as an Engineer – they’ve lived through multiple product launches, have learnt more than 1 generation of new technology, have experienced the full end-to-end product lifecycle, and seen a lot of ‘what seems critical at the time, but in the wider picture isn’t so important’. This person confidently corrects and guides a team of other Engineers, granting them extra perspective and wisdom.

The blanks: at Pre-Seed, there is no team of Engineers – there’s just 1. There’s no-one to guide, and there’s no process to adopt. There’s no-one to hear the wisdom – unless it’s the CEO?

At SeriesB and beyond, just as the influence of individuals (solo Engineers) evaporates, so too the influence of individual teams should vanish. This causes each specific Lead Engineer to become less important, even though the group of Lead Engineers as a whole is probably critical to the company’s sucecss.

The problems: this is the first role that acts as a ‘bridge’ between the pre-seed and post-seriesA worlds; the problems here are much more negotiable, and may not be problems at all. In the extremes: a Lead Engineer in a company with no other Engineers is probably over-engineering solutions and wasting time; a Lead Engineer dictating product decisions in a SeriesB company is probably abusing their (hard-won) political influence and respect for having been around since the company’s earliest days, at the cost of all the other voices in Engineering.

The role: tech companies often have very large Engineering departments (relative to the rest of the company), both in headcount and – even more so – in payroll (total wages). This is a deliberate side-effect of the empowering nature of tech and internet: delivering value via digital is almost infinitely scalable to more customers, and you want to put the largest number of your best people there, where individuals can produce 10x-100x returns on their time invested. Managing that – the people, the org-structure, the projects, the conflicts – becomes the hardest line-management/project-management related job in the company, and this is where the VPE shines.

The blanks: like the Lead Engineer, but more so, the VPE needs multiple teams to manage for them to show impact. But see below for where this gets murkier…

The problems: VPE’s often add layers of process and bureaucracy that increase productivity/efficiency but come with fixed overhead. In a small org the fixed overhead eclipses the %age saving – in a large org, the fixed-overhead becomes a rounding-error compared to the ever-scaling savings.

But a VPE is expected to be good at understanding and discovering ‘context’ – without it they have no chance of managing the significant headcounts (e.g. 50-150 people) – there’s simply not enough time in the day to speak to everyone. So there’s more room for a VPE to adapt to a smaller company, to make “now vs later” decisions on process, good practice, etc.

Finally, the meat of the problem, the one that gives the name to all the rest: the CTO. What does a CTO actually do, in a mature established company – and how much of that exists in a startup?

The role: We can debate this endlessly, but to simplify: a CTO works strategically at the intersection between ‘technology’ and ‘business’. Like all C-levels, they must be eloquent and highly effective at navigating commercial and business issues completely outside their specialism (technology/product), while tying the two together – everything at this level is symbiotic. For the decisions that take minutes or hours to make but years to prove ‘brilliant’ or ‘disastrous’ you want someone who’s been seeing the wood for the trees all along, and guided the entire tech/product part of your org to the decisions they don’t regret.

The blanks: Do you need strategy before you have a customer? A product? Maybe not. Or maybe it’s critical that you do! Twenty-five years ago when I started in the industry you definitely did – but that’s before AWS and Cloud existed, before cheap hosting and scalable data-centers, off-the-shelf cheap SaaS, etc. Back then every decision you made committed you to a 5+ years maintenance cycle – and even your seed-stage decisions could kill the company. Today? The core tech problems no longer require this – getting them wrong won’t kill the company – but getting them right can still leapfrog the company to success much quicker, or with much lower risk.

The problems: The CTO has much to offer a startup, but not everything they bring to the table is necessary or worth having … yet. Great CTO’s – even more than VPEngs – are excellent at forsight, strategy, adaptability. They live and breathe “should we build or buy?” in every possible decision, and innately understand the hidden risks, especially the long-term ones. Such a person can definitely ‘scale-down’ to a startup. But only a minority of people in any role are ‘great’, and the ones who are middle-of-the-road in a larger company often struggle with the more intense pace of small companies, the vast number of decisions that no-one has time for – they have to (learn to) let it go; when they do not, we see horrifically over-engineered solutions and slow-moving startups tripping over their own feet.

Everything above is debatable – if you’re a CTO/Tech-leader in London come along to one of the meetups and I’ll happily argue it out over beers/coffee. But hopefully you’ll find it aligns well-enough with your own experiences to be useful as a starting point in planning and conversations.