CTOs Should Prioritize Work Using One Simple Rule

You’re likely the top technical person in the room; you’re likely networking and fundraising, and somehow you’re probably still writing code. You’re often staring at a list of 10 critical things to do —and you’ll likely only get to three of them.   

One of the things that I had to learn quickly as a CTO is how to prioritize aggressively. While prioritizing leads to tough questions and conversations, it’s made easier by following one simple guideline: 

Stay as close to the customer as possible.  

Your role as the head engineer has many facets, ranging from product to customer success to architecture and development. When deciding where to invest time, it’s easy to default to the familiar — writing code, running tight sprints, and shipping features. 

However, organizing the team to ship as much code as possible at the early stage is not always the best priority, but doing anything different is often at odds with all your instincts as a developer or technical leader. Your goal as an early-stage company should be to launch an MVP and show product-market fit so you can acquire customers. With an early-stage product, you’re building a product and getting feedback faster than your one-pizza dev team can keep up with, and there is no shortage of new ideas and features to build. 

Don’t get me started on the number of times I’ve seen startups have more microservices than people in the company. When choosing where to invest, it’s tempting to take advantage of the small codebase and excited team to start building an impressive yet complex architecture and process. But choosing to build the thing that excites the engineer inside means you’re missing out on multiple iterations of the customer, product, and, ultimately, company iterations. By not taking advantage of this rare moment to experiment with the product and customer value stories, you’ll find yourself working on things that the customer doesn’t care about or isn’t adding value at this stage.

By prioritizing customer feedback, you gain some critical advantages: 

1. You spend your time and energy moving very quickly through objections and challenges. If you don’t take the time to learn these, no technology will cover the gap. 
2. You build a foundation for how engineering services the business. You should find yourself pulled forward by customers, requests, and prototype feedback instead of pushing out features, hoping that customers will find valuable. 
   
3. You prioritize learning. Moving fast, iterating, and being agile are standard tenants of the lean startup. Still, engineers can be tenacious, and it’s easy to grab onto the first hint of value and start charging down that path. Don’t fill the roadmap too far out because you’re likely to fill it with the wrong things at this stage. Running more experiments is way more valuable than building a more stable platform iteration at this stage.

In short, as CTO in a new role drinking from a firehouse, you still have to build with confidence. Your time is not cheap, and development takes a lot of time, but ten 30-minute meetings that uncover the path to customer value can be quicker than fixing a bug – and far more likely to contribute to the long-term success of your company. 

Here is a post that outlines some of the other principles we follow here at Allstacks: A Checklist for Modern, High-Performance Engineering and Product Orgs

- Jeremy