The Startup CTO’s Journey

From inception to scale, what to expect along the way

Author

Peter Bell
May 17, 2024

I am excited to have our very first Founders in the Cloud guest contributor this week! Peter Bell is the CTO of Engineer Access and the co-founder of Geeks Who Lead, the definitive global learning community for senior engineering leaders (join here)! He hosts the CTO Hour for O’Reilly and facilitates the executive summits at KubeCon. He ran engineering at General Assembly, created a remote first team of 50 for Flatiron School and taught Digital Literacy and Data Science for the MBA program at Columbia Business School.

Thanks Peter for sharing your insights into what startup CTO’s need to consider as they begin as the Coder-in-Chief and Founder in the early days to becoming a leader of hundreds and potentially an executive of a public company!

The challenge with the role of startup CTO is that the role changes so quickly as the company scales. Whether you’re looking to become a startup CTO or to hire one, here’s some advice on what “good” looks like based upon my experiences as a startup CTO.

The skills you need at the start as a CTO are not the same as you scale.

Inception

The best CTO for the inception phase is someone who is deeply focused on product and experimentation. Their goal is not to write code, but to minimize cycle time in running experiments to de-risk the big assumptions underlying the business.

It’s so tempting to just sit and code, but in the early days it’s way more valuable to “get out of the building” and focus on talking to humans. How can you validate the value proposition and people’s willingness to pay for your solution, quickly and effectively? If you haven’t read them already, it’s time to go back to the classics. The Lean Startup and Running Lean still provide a solid introduction to the mindset required to identify the quickest, cheapest and simplest experiments to validate your hypotheses.

When I founded SystemsForge back in 1999, the value proposition was “million dollar websites for a thousand bucks a month”. It was basically a sophisticated site builder, but we had validated the demand by starting as a services company and getting companies to pay us to build websites, By the time we raised our first round, the primary outstanding risk was whether we could build a tool that would reduce the cost of building web applications by orders of magnitudes and then whether we could effectively scale our sales team. We had no question that if we built it they would come, because customers were already paying us more money for less capable sites.

Seed

By the time you’re raised your seed round you probably have a growing code base and a small team of 2-6 developers. At this point, the CTO’s role is to be a player coach - driving architecture, shipping features, and supporting and aligning the rest of the team.

It really helps to have had some experience at an early stage (Series A-B) startup to know what good looks like in terms of processes and tools. You should set up basics like Continuous Integration, Continuous Delivery and Feature Flagging. You should also have a lightweight process for aligning the team with business objectives and shipping regularly. You want just enough process to keep the engineering team productive and aligned on shared objectives without becoming burdensome to getting things done.

It’s also important during the seed phase to be thoughtful about the distinction between experiments and core features. If you know something is validated and is at the heart of what you’re building, it’s probably worth thinking more carefully about architecture, test coverage and at what scale it’s going to break. If it’s an unvalidated experiment, it’s often better to prototype it. If an experiment ends up being popular, the bad news is that it’s always hard to find the time to fix it, so you’re going to be carrying technical debt for a while, but it’s generally worth it as it allows you to get more “shots on goal” to find features or capabilities that’ll move the needle for your growth or retention metrics.

I founded Wheelhouse in 2015 to “automate mentorship” for developers, creating a set of automated scripts that taught junior developers how to use GitHub and to collaborate through Pull Requests effectively. We knew that hard coding the solution for GitHub would require a lot of reworking to a more generalizable solution with Domain Specific Languages if we got any traction and wanted to generalize our offering to teach developers how to use other popular tools, but it was worth it. We were able to ship much more quickly and within just a few months had proven the idea, teaching over 25,000 developers how to work with GitHub just a few months after inception.

Growth Stage

The hardest time for most startup CTOs is after they raise their Series A. The good news is that they’re on the path towards product-market fit. The bad news is that now they need to go from running a team to building an organization. If it’s their first rodeo, it can be a bumpy ride.

This is often the time where a tech team will:

  • Migrate away from their cobbled togetehr code pipelines to build a nascent internal DevOps/Platform capacity, usually with 2-3 engineers,

  • Grow from one team of developers to multiple teams, bringing in Engineering Managers so the CTO doesn’t end up with 20 direct reports,

  • Formalize their hiring process to create a consistent, fair and predictive process across the organization,

  • Realize that the overhead for effective collaboration between teams is slowing down the pace of development.

If you haven’t done it before, this is the perfect time to hire a “rinse and repeat” Vice President of Engineering with experience scaling engineering organizations from 10 to over 50 employees who has a sense of what is going to break next and how to prioritize the various demands on the growing organization to make sure that it stays productive as it grows.

Scale Stage

By the time you reach your Series C and beyond, you should have all of your basic systems for alignment, reporting, management, and communication in place. Next, you need to start to refine them with an eye to the consistent and predictable operations required by a publicly traded company.

By this point you may not know your entire organization by name. Most of your strategies are going to be focused on providing a consistent and stable environment for your engineering team. You’re going to be spending a lot of time looking at spreadsheets, working with a communications team on external-facing messaging, and refining your internal communications processes to keep your organization aligned and on track. It’s more like steering a cruise ship than driving a jet ski, If you have the right systems in place, you’ll be able to deliver orders of magnitude more than you could when running a smaller team.

By this time, your most important focus areas are thinking about incremental and disruptive innovation, ensuring you have the systems to attract and align great team members and building a deep bench of future engineering leaders who can take on substantial initiatives to move the organization forward.

Conclusion

In addition to hiring great executives, it’s OK to ask yourself if you still want the CTO role at each stage. Once you’ve raised a Series A, there’s nothing wrong with a founding CTO who decides to take a Staff+ individual contributor role or to play an external-facing role, relying upon experienced engineering leaders to keep the organization running smoothly.

If you do want to keep the CTO role, make sure that you’re growing as a leader as quickly as your team and learning from your peers. I remember interviewing Greg Brockman in 2017 back when he was still the CTO at Stripe. Barely out of college, he’d created an amazing and substantial engineering organization. I asked how he managed to build a high functioning engineering organization when he’d never even worked for one. He said, “Oh, I just called up the CTO’s of AirBnB and other scale stage YC startups, grabbed coffee, and picked their brains”. Make sure that you accelerate your learning by connecting with and learning from other venture stage CTO’s solving similar challenges.

“Football and life are a game of inches.” These words are uttered by Coach Tony in the movie Any Given Sunday, and they could not ring truer in the world of startup fundraising.

While we wrapped up our fundraising series a couple of weeks ago, a recent tweet from Jason Lemkin got people stirring about how unfair VC ‘s are. In this case, a founder did not update the date on their pitch deck from March to May. Thus, an almost went to a not good enough.

Another VC tweet stirs the startup fundraising pot

Many would say these are merely ridiculous pet peeves of an over-privilege class. We have all seen the raging debates play out on Twitter and LinkedIn on seemingly petty preferences:

  • Cold emails vs. Warm intros

  • Pitching associates vs. Pitching partners

  • Docsend link vs. PDF attachment

  • Calendly vs. Email back-and-forth

  • Pitch deck vs. Investment memos

  • Financial model vs. No model

  • Co-founders vs. Solo founders

  • Lamar vs. Drake

But in the world of startup fundraising, the difference between an investor taking that first meeting and moving to the next pitch is inches.

You cannot control or even know ahead of time what will offend the sensibilities of an investor, but you can absolutely control the attention to detail in your approach and output. Did you spell check your introduction emails, get the investor’s name right, fix grammar and formatting in your pitch deck, and scrubbed all your pitch documents of tell-tale signs of a tough fundraise such as the document date?

These may seem insignificant compared to all the substantial work you have done to build and launch a product and to acquire customers. But remember, an investor sees hundreds of pitch decks and investment memos a month, many through trusted introductions. Investors can be as picky as they like. Your job is to stand out and not shoot yourself in the foot with mistakes.

Basil will be reporting in next week when he is back in Dubai with his thoughts on the Berlin startup scene at the AWS Summit. Meanwhile Mark has been busy preparing for SE Asia next week as he travels to Hong Kong, Bangkok, and Saigon for events and to meet startups.

You can find Mark at the following events:

Let’s meet at one of the follow events in SE Asia!

If you are in any of those areas and want to meet up, please give us a shout. There have been a lot of \interesting AWS Generative AI launches over the past few weeks, so lots to chat about if you want to learn more!