.png)
Complete visibility into time & dollars spent
Create meaningful reports and dashboards
Set targets and get notified of delivery risks
Track and forecast all deliverables
Create and share developer surveys
Align and track development costs
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:
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.
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