Evolution of my role as a founder CTO

There is a lot written about the importance of scaling as a founder in a fast-growing startup. Most of it focused on the CEO role. The generic advice on leadership also applies to other non-CEO roles, but I could not find a lot of content targeted to technical founders. In fact, after reading a bunch of S-1 forms, it was hard to find first-time CTOs going all the way from MVP to IPO (as opposed to founding CEOs). I found this fact really intriguing, and I wanted to dig deeper to try to understand the reasons. It was also stressing me out to some degree: what if I don’t manage to scale fast enough? What does scaling even mean? I’d rather prepare before it becomes a real problem! I want to be the CTO who makes RevenueCat a public company!¹

Is it really much harder for non-CEO founders to scale quickly? Or perhaps it is that CEOs have a stronger support network. These could be the reasons. Or maybe I was asking the wrong question. After talking to a lot of founder CTOs, there was something clear: there is no standard definition for the CTO role, responsibilities will totally change depending on the company and the stage. At inception, the CTO is probably a glorified individual contributor, but this can escalate very quickly. Everyone’s experiences are different. Unfortunately, I don’t have the answers for other non-CEO founder roles, and maybe I don’t even have it for first-time CTOs either. However, I thought it would be a good self-awareness exercise to reflect on the things I’ve learned and how my responsibilities have changed during the first 3 years at RevenueCat.

The CTO vs VP of Engineering dilemma

Simplifying, we could say that the CTO role is closer to architecture and code; whereas the VPE would be in charge of processes and management. A simple analogy could be the Senior/Staff Engineer path versus the Engineering Management career path.

During the early days, you need a CTO to architect and coordinate a small group of ICs hacking the minimum viable product. At this stage, being a founder is extremely helpful to set the vision of the product and the engineering culture. Ideally, the CTO is a domain expert in the problem that the startup is trying to solve.

But what if the product becomes successful? What if you reach product-market fit? You will need to hire a lot more engineers to satisfy customer demands. That’s a great problem to have. You might get lucky and get funding, or you might even be profitable already. But a higher headcount means more polished processes. At some point, somebody will inevitably need to start wearing the VP of Engineering hat. It will happen, and it will become quite obvious as the previous (or lack of) processes start to break. You have a couple of options at this stage. The CTO can start acting as VPE, or you can hire externally. It is probably a matter of personal preference or previous management experience. But it is a totally different set of skills, which might be difficult to acquire in a hyper-growth environment. Therefore, most commonly, the VP of Engineering is hired externally.

If you are a founder you have some flexibility. You might have control to decide which way you want to go. Perhaps you hate people management and want to keep using your technical skills and problem knowledge to influence the technology directly. Or maybe you want to improve your management skills. Early employees tend to be more forgiving about founder managerial flaws. They joined because they trusted the founders, believed in the vision, and know they have good intentions. In the beginning, they might even prefer you as a direct manager than an external person. But eventually, there will be several layers of management, so you better learn fast if you want to follow this path and don’t have the experience.

Bryan Helmig, Zapier’s co-founder and CTO, says you need to figure out where you get your dopamine hits. Personally, I have always been more of a computer person than a people person. I was not sure which path I should take, but I would have bet on the one involving computers. I’ve always loved them, and I would say I am a better, more experienced engineer than I am a manager. I feel more energized after shipping a new feature than during a one-on-one meeting.

However, as a founder, I get the dopamine hits when the company is doing well. When a customer recommends our product. When we hit the revenue goal. When we hire engineers that are better than me. When these engineers are happy and successfully shipping ambitious features. When code review is exhaustive but collaborative, not adversarial.

So, ultimately, I’ve taken the approach to not simply follow my personal preference, but to do whatever is more impactful for the company at each stage. I am a problem solver after all. That is how I have been thinking about my role. My founder identity should be more important than my CTO title. In the long run, as a major shareholder, I need to do whatever is best for the company.

Typically breaking points start happening somewhere between 8 and 12 engineers. But it can be different depending on the product and the environment. In our case, as a fully distributed company, we encountered several breaking points as we were adding new time zones. During this no man’s land stage most technical founders are temporarily forced to wear both CTO and VPE hats simultaneously. Being flexible turned out to be very advantageous. I tried to step up and (poorly and temporarily) do work that nobody had the bandwidth to do. This helped me to identify the pain points and tweak the process or hire somebody to take over these tasks.

One thing that helped me a lot to navigate my role was to learn how other founders were spending their time at each stage. I have been journaling since we started the company. Based on these notes, I will briefly describe the tasks I’ve been focused on and how my role has evolved.

2018: YC, MVP, and first hires

When we did Y Combinator it was only Jacob and me. Jacob would write SDK and frontend code and I would focus on the backend and infrastructure. After YC we hired our first two engineers to take over Jacob’s coding responsibilities full time. We were all based in San Francisco and these hires were people we already knew. Easy (almost inexistent) management. There was no process overhead, we had one-week sprints and we were moving really fast.

These days were stressful but fun. We were setting the foundations of the engineering culture and seeing customers signing up one by one. Most of my time was spent architecting the initial version of features, listening to customers, and building their requests as fast as we humanly could. We would ship most requests on the same day.

My biggest concern here was making sure we were building something people wanted and the ability to keep growing to justify our $1.5M seed round.

Main learnings: Too many, impossible to summarize. We learned a lot while doing Y Combinator. The main thing would be that talking to customers, building what they want, and making them happy was paramount. We even made this and shipping fast two of our core values.

2019: Keeping up with customers and scaling the tech

It looks like we had achieved some kind of product-market fit. Customers were coming to us, support tickets started piling up and our API throughput would increase every day. We added our first remote engineer, located in Taiwan. The time zone difference was hard initially and we needed to adapt processes. But it all worked out fine. We got better coverage for customer requests and monitoring.

Onboarding was a complete, one-off manual process. I started doing one-on-ones (not very regularly, maybe once a month), but management was still pretty light. Most conversations were still very technical. I was still an individual contributor. I was also on booth duty at a couple of conferences.

My main concern at this stage was purely technical: the scalability of our systems. All of our engineers had a more product-oriented background, and we had some clear single points of failure. Not going down was constantly in my mind. The scale was outgrowing my comfort zone every single day. We did a decent job optimizing the most common scenarios, migrating infrastructure before reaching breaking points, and paying down the technical debt we took the year before.

Up until Q4, I was the de-facto on-call engineer. I did not want to disturb other team members outside working hours, and I felt reliability was my ultimate responsibility as a technical founder. I would carry my laptop literally everywhere. Eventually, we implemented an on-call rotation, and in retrospect, we should have done it earlier.

Main learnings: Do not stress over scalability, but monitor as much as possible and always look out for the next bottleneck and single point of failure. Again, these are stressful but great problems to have. Establish an on-call policy as soon as possible, train engineers, and document resolution for known incidents. Rely on your team. Technical debt is actually good if taken responsibly while trying to find product-market fit.

2020: Delegation and planning the future organization

In 2020 we doubled the team again. We added engineers in Europe and Latin America. By the end of the year, we had multiple members in every team (SDK, frontend, backend…). We were able to work on several projects at the same time, and finally tackle more ambitious features. But we needed more coordination. A little bit of management structure was unavoidable at this stage.

During Q1 and Q2 I spent most of my time reviewing code, providing architectural guidance, and coding a little bit on the side. I was still the person who had more context about our systems. By mid-year, it became very obvious that I was the bottleneck for shipping new features. I was also doing one-on-ones more regularly, pulled into more meetings, and I started to not be able to deliver my code on time.

I stopped coding completely. Instead, I assigned my tasks to other engineers and spent more time sharing knowledge. It felt slow at first, but this delegation unblocked projects and created a stronger sense of ownership for engineers. Not coding felt really weird at first. It totally felt like I was not doing my job or not being productive. That’s a totally natural feeling. I soon realized how not coding had freed me up to see the big picture again. I was able to start thinking about the future of the engineering organization.

On the people management side, I spent more time talking about career progression and worked with engineers to grow and get promoted. On the product side, we were lacking the bandwidth to properly prioritize, plan, and coordinate sprints. I stepped up as much as possible to unblock people and improve communication.

Additionally, we raised our Series A and started having board meetings. Recruiting also started to take a big chunk of my time.

Main learnings: Adding new time zones became much easier once there was enough overlap. Reducing the bus factor is extremely important to scale the engineering team. Once a manual process is tested and working, automate it as much as possible. Stop coding and delegate when you can’t see the forest for the trees.

The future

We are planning to double the team again next year. Going from 20 to 40 sounds way more challenging than going from 10 to 20. The company will look very different by the end of 2021.

I think my main focus will be team scalability. Don’t take me wrong, we will be facing big technical challenges and the roadmap is full of ambitious features. But we have learned a lot in the last few years about our customers, the problem, and the technical stack powering our solution. I am privileged to work with very talented engineers that have the skills and excitement to tackle these.

I want to keep hiring top talent and maintain improve our healthy engineering culture. That is not going to be an easy task. I will have to work closely with the Head of People to polish and automate processes around sourcing, hiring, onboarding, and communication. Referrals were a great hack to bootstrap the team, but it’s time to focus on team diversity. I think we will also be in a much better position to finally hire more junior engineers and I would love to help them grow to their fullest potential.

We will need to step up our engineering management game to empower engineers and keep them happy and growing. Additionally, we will need to also heavily invest in product planning, development, and launch processes if we want to hit our ambitious roadmap goals.

I am very excited about what is coming up next year. Sure, there is a whole new set of problems that we will be facing, in addition to the existing ones. But that’s how it is. It never gets any easier!

I hope this read was interesting and helpful. I am planning to revisit this post and update it every year with new learnings. If you are a first-time CTO, I am happy to help as much as I can. Feel free to reach out on Twitter or via email.

Some interesting reads:

• The CTO Journey at a Small Startup
• #define CTO
• What makes a bad CTO?

Special thanks to Alex Plugaru, Calvin French-Owen, Javi Santana, Adam Houghton, Sam Lown, Saul Diez, and Will Larson for their generous advice and for taking the time to share their experiences. And of course, to the entire RevenueCat engineering team for letting me experiment with them, accepting my flaws, and their constant candid feedback.

¹With time, I’ve also learned that this anxiety and fear, mostly driven by Impostor syndrome, is unfounded. If the company outgrows you, it is not necessarily bad. It’s actually another great problem to have! That is exactly what you want as a founder. Focus on hiring people better than you to help you grow and make the company better. You want to build something bigger than yourself. I still want to help RevenueCat go public, but if we manage to do it, my responsibilities or title will not be that important anymore.