How to be a Good Startup CTO

It starts with less code writing, and more talking to customers

This is a post about the earliest stages of startups, where things are the most uncertain. At the earliest stages, the risk is almost always in what to build to do not how to build it. Later on the CTO job is about delivering execution, but early it’s about enabling rapid experimentation to get to the truth about a customer and a market.

There are really only two jobs at the earliest stage:

Job 1: Put a Product in Their Hands

Probably the most important truth about this experimentation stage is you really only learn from a customer once you have a product in their hands. You need to measure pull or how much the customer wants the product. The only way to do this is to show it to them and see what they think. Is this thing valuable? Will I use it every day? It’s actually a really good answer when you’re missing features, because they need them.

This means you’re learning is effectively capped at how fast you can ship new products to customers. Early on the job of the CTO is essentially to be really really good at rapid prototyping. You need to get to MVPs in days, not weeks, and quickly ship new features. It’s about trying a lot of little things and seeing what sticks.

Job 2: Talk to Customers

After getting a v0 of the product out, the next most important job of the CTO is to talk to customers. As engineering people, talking to people to hear about their pain might come unnaturally, but essentially the success of everything depends on your ability to tease out whether you’re solving an important problem or whether you need to move on and pivot. You have to be willing to throw everything away and move on to the next thing if it makes sense.

Probably a majority of your time should be spent finding customer to talk to in order to learn about their pain. It is not the most fun job, but it’s what’s necessary to win.

How a Good Startup CTO Spends Their Days

I probably spend 30-40% of my time on short, very well-defined, focused building spikes to test a product hypothesis. 10% of my time is actually on calls with customers learning from them. The rest is spent sourcing new customers to talk to and helping figure out go to market. The takeaway here is actually that the minority of time is spent building and the majority is on customers.

Post PMF: Focusing on Product

The first part of this post was focused on the pre pmf stage, where things are uncertain and you’re rapidly iterating to get to the thing that will take the company from zero past one. Once you’re there, most of the focus shifts to product. This is where you can take the full weight of your engineering skills and build the best possible thing for the customer. Once you hit PMF the focus of the CTO still includes talking to customers, but a majority of it shifts to owning and managing engineering to make sure the company has the best possible product to win the market.

Your job becomes really simple: own execution and make sure the company is executing quickly and efficiently. Run a tight ship from an engineering standpoint and maintain a high quality bar. Ship the best product that wins the market.

Way Past PMF: Scaling Teams

Once you’re past a certain growth stage (very late stage). The job of the CTO becomes primarily about managing talent and owning technical vision / impact. You’re no longer the one writing the code, and instead what matters is who you get to write the code for you. The CTO, vs the EVP of engineering, is the most senior IC at a company. Their job is to do IC things; own strategy and vision, push the most impactful technical changes etc.

My models for this include Balaji at Coinbase, who was Coinbase’s first and last CTO, and who owned probably some of the most impactful technical and strategy decisions in the history of the company. Your job is to be right about strategy and execute relentlessly on that strategy with a focused team of engineers. The job becomes about managing and motivating those engineers to make impact.

Conclusion

This is actually a pretty dynamic role that changes over time. Being a good startup CTO is not a one-size-fits-all activity and changes as the company scales. Probably the most critical time is at the very beginning where most of the job comes down to derisking over just purely shipping new product. Good startup CTOs are talented at everything from rapid prototyping to shipping polished product to making the most important strategy decisions that effect a company.