A 3x CTO's POV on Building 0-1

Today’s post is brought to you by Karthik S. , CTO at Forum Ventures with a remarkable 20-year journey in tech marked by successful startups, impressive funding rounds, and groundbreaking work in AI. Prior to Forum, Karthik served as the VP of Engineering and founding member at Zuva.ai, and has co-founded twice. Engineer by education, software engineer by choice.?

In the past year, I've partnered with Karthik on 6 venture studio CEO and 4 early-stage senior engineering roles to build in the 0-1. And it's been a delight. Why? Because he gets it. This is why I'm thrilled to be sharing his learned insights, and pragmatic views on startup engineering teams.

Let's get into it.

With two decades of experience under your belt, how has your approach to technology leadership evolved, especially in high-stakes startup environments?

• Innovation starts and ends with engineering and product teams; over time my primary responsibility was to provide a “psychological safety net” to product and engineering teams when things fail. This has been very effective as it has helped engineers and product owners to iterate fast and fail fast without the fear of repercussions.?

• Aside from having company values, promoting “engineering” values that make sense for startups is important. In my previous company, it was about iterating fast, we collectively agreed as an engineering team on “progress over perfection”, which was the baseline for all decisions. For example, are we incrementally progressing each decision we make?

What were some pivotal moments and key learnings from co-founding as a CTO?

• Software development is easy. Founding a company is easy. But, fundraising is hard. Sales are even harder. The silence, particularly during long sales cycles, often drove me nuts. Investor relationships can go south. Employee management? It sometimes falls by the wayside. A hard reset every now and then? Not a bad idea at all.
• Finding developers who can execute is more important than hiring developers to think. I optimized for those who could execute quickly, which were often individuals who had many years of experience under their belt. More specifically, they have worked on a variety of different types of projects.

In the future, if I were to become a founder again, I would:

• Learn to filter noise and focus on the product.
• Focus on building an engineering team akin to a "Seal Team Six" – highly focused and driven, with each member owning specific features rather than simply working on task-based assignments.
• Focus on simplicity of architecture as well as tools, and not buzzwords. Facebook, LinkedIn, Shopify, and every other large “startup” company were built with “legacy-not-so-sexy” software in the 2010’s era before the “tools-armageddon” kicked into high gear in the mid-2010's.
• Monolith is OK. Sometimes bash script is all we need.

Being part of raising $20+M is no small feat. What strategies did you find most effective in securing funding, and how did you align your technology vision with investor expectations?

• Most investors may not have deep technical expertise, but they do understand sales. Focusing on less technology-intensive architecture initially can reduce engineering costs and allow for greater investment in product development. Better product = better sales cycles.
• Engineering often represents the most significant expense in any SaaS startup. To manage these costs, a focus on automation and selecting cloud-based technologies that require less DevOps overhead can be beneficial. A prime example is the use of serverless functions, like AWS Lambda. For instance, our API could handle over 1600 requests per second at peak times without any scaling issues or significant DevOps involvement, all thanks to Lambda.
• In board meetings, I've found it effective to shift the focus towards data growth rather than just revenue growth. While revenue is undoubtedly crucial, the value of product data and customer intelligence is often even greater. Demonstrating how this data can lead to increased revenue and better product decisions has proven to be a key factor in engaging more effectively with investors.

What's your philosophy in building and nurturing a tech team, especially in the dynamic environment of a startup?

Embedding technology “values” in all aspects of the work:

• Progress over perfection - this philosophy of prioritizing progress over perfection led us to adopt the 4C’s framework: Continuous Development, Continuous Integration, Continuous Deployment, and Continuous Feedback. Most are familiar with the first three Cs, but Continuous Feedback is a unique aspect where engineers collaborate closely with customer success managers to directly integrate customer feedback into our development process.

• The KISS principle - "Keep it simple, stupid!". During the early days, the product will iterate fast and when it does, there cannot be too many moving components. The idea has always been to not have more than 2-3 external or tooling components to support the product.?
• These approaches not only improved our service delivery, but also infused business-oriented values into our engineering culture. We constantly evaluated and selected tools and services that minimized operational and support tasks for our developers, allowing them to concentrate on shipping product.
• By having our developers engage in DevOps work, automation, and efficient tooling naturally evolve from their work.

What advice would you give to aspiring tech leaders who aim to follow a path similar to yours?

"Can you build a $100K business with 2 developers, a $1M business with 3 developers, a $10M business with 5 developers, and a $100M business with 20 developers?"

Pondering this question can significantly influence the evolution of your technology choices and the composition of your development team.

Lastly - hire developers to build products, not to support.