Much has been written about the importance of founder self-development in fast-growing startups. As a rule, texts on such topics are devoted to the role of the CEO. General leadership tips can be useful for other roles as well, but I haven't been able to find any material to help tech founders. After reading a bunch of S-1 forms, it became clear that it is very difficult to find CTOs from scratch who have gone from MVP to IPO (while with founders-CEOs, the situation is exactly the opposite). This fact seemed to me intriguing - I decided to dig deeper. I wanted to get to the bottom of the essence and reasons for this state of affairs. It also annoys me a little: what if I am not able to grow quickly? I should figure it out before real problems arise! I want to be the CTO that makes RevenueCat a public company! (one)
Is it harder for non-CEO founders to grow quickly? Could it be that the CEO usually has significant support? Be that as it may, everything has its own reasons. Perhaps I just put the question wrong. After talking with many CTO founders, it became clear that there is no standard definition of a CTO. The responsibilities of a person in this position can completely change depending on the company and its stage of development. The CTO will probably make a lot of personal input at first, but this could soon change. The experience of different people can be very different. Unfortunately, I have no answers for non-CEO founders. Perhaps I don't have answers for those who became CTOs for the first time either. Be that as it may, I thought it would be helpful to reflect on what I have learnedand how my responsibilities have changed in 3 years at RevenueCat.
Dilemma: CTO vs. VP of Engineering
Simply put, the CTO role is closer to architecture and code, while the VPE will be in charge of process and management. An analogy would be to compare the path of a senior / full-time engineer and an engineering manager.
Early on, you need a CTO who can gather and organize the performers who create the MVP. At this stage, the founder can be very helpful as it is necessary to define the product vision and the culture of technical processes. Ideally, a CTO should understand the problem that his startup will be solving.
What if the product is successful? What if the product takes its place in the market? In this case, you will need to hire more engineers to meet the demand from consumers. This is a wonderful challenge. Perhaps you are lucky and you will find funding, or you may already be generating profits. But the larger your staff, the higher the requirements for process excellence. The moment will inevitably come when someone has to become a VP of Engineering. The onset of this moment will become evident as soon as existing (or missing) processes stop working. In such a situation, you have several options. The CTO can take over the VP of Engineering role, or the company can hire additional employees. This decision is likely a matter of personal preference and management experience.Tackling these kinds of challenges requires a completely different set of skills, and it can be difficult to acquire these skills in an environment where you need to grow very quickly. This is why the CTO is usually outsourced.
The founder can be flexible. He may have the authority to determine the path the company will take. Perhaps you hate managing people and want to continue your skills and knowledge in order to work directly with technology. Or maybe you want to improve your management skills. The first type is generally more forgiving of the founders' managerial flaws. They joined the team because they trusted the founders, believed in their ideas and were confident that they had good intentions. At first, they may prefer to work directly with you rather than with an outside person. In any case, in the future the company will have several levels of management, so if you want to go down this path and you have no experience, then you should learn, and learn quickly.
Brian Helmig, co-founder and CTO of Zapier says you need to find what dopamine gives you. Personally, it has always been easier for me to communicate with computers than with people. I was not sure about the choice of the path of development, but I preferred to do things related to computers. I have always loved working with them and I can say that I am more efficient as an engineer than as a manager. After integrating the new feature, I feel more energized than after meeting in person.
However, as a founder, I get high doses of dopamine when the company is doing well. When buyers recommend our product. When we reach our income targets. When we hire engineers better than me. When these engineers are happy with everything and successfully solve ambitious tasks. When the code review is tiring, but it goes in an atmosphere of collaboration, not anger.
So, in the end, I decided not only to follow my preferences, but to do what is more effective for the company at different stages of its development. After all, I can solve problems. This is how I talked about my role. My qualities as a founder are more important than my position as CTO. From a long-term perspective, as a major shareholder, I must do whatever is best for the company.
Typically, a fracture occurs when you have 8 to 12 engineers on your team. However, it can occur at another moment, it all depends on the product and the environment. As a fully distributed company, we faced several tipping points as we built new time zones into our workflows. At that time, many had to take on the duties of CTO and VP of Engineering at the same time. I tried to take on work that others lacked the resources for (I did it temporarily and not very well). It helped me find pain points, establish processes, and hire someone to take on these tasks.
When I learned how other founders manage their time at different stages of work, I was able to better navigate my role. Since the very foundation of the company, I have kept a diary. Based on these notes, I will talk about the tasks I focused on and how my role has evolved.
2018: YC, MVP and first employees
When we came to YCombinator, it was just Jacob and me. Jacob worked on the SDK and frontend, and I worked on the backend. After YC, we hired the first two engineers to take over Jacob's responsibilities and work full time. We all lived in San Francisco, and we already knew these people. We had simple (and almost complete) controls. There was no overhead, we had weekly sprints, and we moved very quickly.
These days were intense but very fun. We laid the foundations for an engineering culture and saw customers come in one after another. Most of the time I spent developing the first versions of the features that clients spoke about. We fulfilled their requests as quickly as we could. Most of the requests were processed on the same day.
What I doubted most then was that we were creating a product that people really needed, and that it could develop and justify our $ 1.5 million seed round.
The main conclusions: there are too many of them, it is too difficult to generalize. We learned a lot when we went through YCombinator. Probably, it is worth highlighting communication with customers, the ability to create what makes them happy and meeting their needs. This and very fast delivery have become our core values.
2019: We keep pace with clients and develop technologies
It looks like we have taken our niche in the market. Clients came to us, requests for support began to accumulate, and the performance of our API grew every day. The first remote engineer from Taiwan joined the team. At first, the difference in time zones caused certain difficulties, it was necessary to adapt work processes. However, everything worked out. We did a good job with customer inquiries and monitoring.
The adaptation was a simple and one-time process. I did face-to-face meetings (not very often, about once a month), but managing was pretty easy. Most of the conversations were still technical. I was still contributing as an ordinary performer. I have also attended several conferences.
At that time, I had mostly technical concerns. Mostly I thought about the scalability of our systems. All of our engineers had experience with the product and we had clear points of failure. I constantly thought that nothing would break. The scale was constantly out of my comfort zone. We have coped well with the optimization of the most common scenarios, infrastructure migration and avoided critical points. We also repaid the technical debt accumulated over the past year.
In fact, until the fourth quarter, I was a call engineer. I didn’t want to disturb other team members outside of business hours and felt it was my responsibility as the founder of the technical department to ensure maximum reliability. I carried my laptop with me literally everywhere. Ultimately we secured the rotation. Looking back, I understand that it should have been done earlier.
Key Takeaways: Don't get hung up on scalability, but don't forget about monitoring. Watch for potential bottlenecks and points of failure. These issues are stressful, but dealing with them is not so bad. Hire and train call engineers as soon as possible, document solutions for known incidents. Rely on your team. There is nothing wrong with tech debt if you approach it responsibly and try to find the product that will be in demand in the market.
2020: Delegation and planning of the future organization
In 2020, our team doubled once again. We hired engineers from Europe and Latin America. By the end of the year, we had several employees in each of the teams (SDK, interface, frontend, ...). We managed to work on several projects and, finally, we took on more ambitious tasks. However, we needed to improve coordination. At this stage, work on the governance structure could not be avoided.
During the first and second quarters, I spent most of my time doing code reviews, providing architectural guidelines, and writing some code on the side. I was still the person who understands our systems. By the middle of the year, it became apparent that I was the bottleneck for releasing new features. I also held one-on-one meetings, took part in brainstorming discussions, and no longer had time to write code and implement it on time.
I have completely stopped programming. Instead, I entrusted my tasks to other engineers and began to spend more time transferring knowledge. At first it seemed like it was taking a long time, but the delegation got many projects off the ground and gave many engineers a strong sense of ownership. It was very strange not to write code at first. I felt like I was not doing my job (or that I was working unproductively). This is a completely natural feeling. I soon realized that I had freed myself from programming, and now I can see the big picture. I was able to think about the future of engineering structure.
In terms of management, I began to spend more time talking about career development and started working with engineers to grow and develop. On the product side, we lacked the resources to properly prioritize, plan and coordinate sprints. I did my best to liberate people and establish communication.
We also went through Funding Round A and started holding board meetings. I also began to spend a lot of time on recruiting.
Key takeaways: Implementing new time zones has become easier when they overlap. Decreasing the bus factor is very important for scaling the engineering team. Once you have verified your workflows and they are working, automate them as much as possible. If you don't see the forest for the trees, quit programming and delegate.
Future
Next year we plan to double our team again. It seems that going from 20 to 40 employees is more difficult than going from 10 to 20. By the end of 2021, the company will change significantly.
I think I'll concentrate on team scalability. Don't get me wrong, of course we will face serious technical problems, and we have many very ambitious tasks in our plans. Over the past few years, we have learned a lot about our customers, problems, and the technical stack that underlies our solution. Working with talented engineers who have the skills and enthusiasm for solving problems is a big part for me.
I want to continue to hire the best talent and maintain a healthy engineering culture. It won't be easy. I will have to work closely with the HR manager to streamline and automate the sourcing, hiring, onboarding and communication processes. Referrals helped accelerate team development, but it's time to focus on diversity in teams. I think we will have opportunities for hiring juniors, I would like to help them reach their full potential.
We will need to improve our engineering management to make engineers happy and empower them. In addition, if we want to tackle ambitious tasks, we will need to invest in planning processes. product development and launch.
I am very excited about what will happen next year. Of course, in addition to existing problems, new ones will come. But it never happens otherwise. It won't be easier!
I hope this text was interesting and helpful. I plan to return to this post and supplement it with new knowledge. If this is your first time as a CTO, I will be glad to help in any way I can. Feel free to tweet or email me.
Special thanks to Alex Plugar, Calvin French-Owen, Xavi Santana, Adam Houghton, Sam Lown, Saul Diez and Will Larson for their advice and taking the time to share their experiences. And, of course, to the entire RevenueCat engineering team for allowing me to experiment with them, for accepting my shortcomings and their frank feedback.
(1) Over time, I learned that anxiety and fear are mostly caused by impostor syndrome and that they are unfounded. If the company outgrows you, it is not necessarily a bad thing. In fact, this is a serious problem! The founder should face it. Focus on hiring people who are better than you, they will help you grow and make the company better. I still want to help RevenueCat go public, and if that succeeds, my responsibilities and position will be less important.
- Discussion on HackerNews
- Telegram channel "HackerNews in Russian"