Skip to content
Ido on GitHubIdo on Twitter

The Journey of Becoming a CTO

The path to becoming a CTO can be a bit like navigating through uncharted waters. The role is a bit vague, often described as the chief architect or head of engineering, and it tends to evolve along with the company's growth. In this article, I share my journey and some lessons learned, hopefully you'll find it insightful.

Early Days

In the early stages of a company, titles can be a bit fluid. When you're one of the founders, you might find yourself with the fancy title of CTO, but your main job is to code, shipping as fast as possible. You'll join your partner, the CEO, to meetings with investors, convincing them that you know what you're doing, even if it feels like you're still figuring things out. But again most of your time will go to coding and doing some product work perhaps.

Hiring the First Engineers

You've secured some funding, and now it's time to build your team. Congratulations, you're now a team lead! At this stage, you're still getting your hands dirty with coding, but you've got to start scouting for engineers who can handle the reins on their own. You have to find sourcing agencies to help with the hiring process, plan the hiring pipeline, and design different interviews.

You're beginning to think about scaling your organization, so it's essential to start creating some documentation, processes, and guidelines. Nothing too heavy, just enough to work smoothly with a few engineers. Code reviews and your role as the chief architect become increasingly important because you've got the broader context.

As a manager, you need to conduct 1-on-1s with your new team members, focusing on their professional growth. It's your job now, and it's a crucial aspect of your role. Additionally, you need to provide them with a solid understanding of the business context and teach them how to collaborate effectively with other stakeholders, such as those from the product and design teams.

But don't worry, you're still mostly coding at this stage.

Multiple Teams

When your company is expanding, and you're tasked with growing the engineering org, things take a different turn. A significant portion of your time now revolves around management, and hiring becomes a top priority. All of a sudden, you are managing team leads. You've got to ensure that everyone is on the same page, and you genuinely care about keeping your members content and retained.

You find yourself as the linchpin for everything. You're the bottleneck, and it's essential to learn the art of delegation, offloading tasks, and sometimes saying no. Coding becomes a luxury because your primary focus is on managing the teams. Instead of taking on coding tasks that could hinder the company's progress, you can focus on refactors, optimizations, and other supportive tasks.

A substantial part of your role involves bridging the gap between the business side and the engineering teams. Tensions can arise, and you're the one responsible for communicating delays, trade-offs, explaining why certain things might be deemed "impossible," and more. If you still want to get your hands dirty with code at this stage, you'll need to schedule dedicated time for it.

Cruising Altitude

As you've successfully brought in enough talented individuals, it's time to fine-tune your operations and ensure they're running smoothly. You'll need to tweak your processes to match the new scale and be open to making organizational changes if they're necessary. It's time to change gears and focus on delivering results.

With this newfound equilibrium, you'll have a bit more breathing room for coding, but you'll mainly be handling tasks that don't obstruct the team's progress. Use this extra time wisely by contemplating the future. Consider the future of your product, the future of your company, and beyond. It's a chance to be innovative and challenge existing conceptions. But remember, you have to allocate time for these visionary pursuits, otherwise, you'll always have something more important to do.

Lessons Learned

  • As your company expands, shift your focus from linear to exponential impact. Teaching your engineers how to tackle tasks can be a better use of your time than doing the work yourself.
  • If you're a coding enthusiast, set aside dedicated time for it. Enjoying the ride is important to keep yourself motivated.
  • Prototypes are your secret weapon for aligning with various stakeholders. Don't underestimate their power – use them!
  • When it comes to taking on blocking tasks, be absolutely certain you won't hinder your team's progress. Otherwise, you'll find yourself under immense pressure.
  • Hiring isn't easy, but it's essential. Hire slowly and be quick to let go of those who don't fit the team. In a startup, speed is of the essence, and you ideally want proactive and independent engineers on your side.
  • The key to scaling is documentation. Document everything, from your architecture to your processes and onboarding.
  • Encourage engineers to take ownership of their work. Give them the reins for processes, deployment, monitoring, and essentialy everything.
  • Manage your time wisely, or someone else will do it for you. Time is a precious resource.
  • Learn the art of saying no. It's a powerful skill that can help you maintain focus and manage your workload effectively.

Work in Progress

Even as you've come a long way, it can still feel weird to call yourself a CTO. "Chief" is a hefty word. The role is constantly evolving, requiring you to adapt every few months to stay in step with your company's rapid growth.

Sometimes, you'll find yourself in the shoes of an engineer, other times you'll wear the hats of a product specialist or a marketing wiz. Being adaptable and tailoring your role to meet the company's needs is the secret to succeed. Flexibility is the name of the game, and continuous learning is your ally.

My journey is still a work in progress, and I'll be sharing more about it in future posts. Stay tuned for updates.

Let's keep the discussion goingJoin my squad