As a startup grows, its workflows must change. I realized that this is especially important for engineers. My role as a co-founder and CTO has changed significantly over the years. My daily responsibilities and tasks changed, and I had to change my approach to work several times to help the company reach the next level.
In the early days of the company, the team consisted of three guys who worked nights and weekends, sawing in the basement what would later become Zapier. Before launch, we made three or four versions of the product. Six years have passed since then, now we process hundreds of millions of requests to our API, and our team employs 80 specialists from all over the world (including more than two dozen engineers).
Growth from the days when there were three of us to the present time has been very difficult. If you want, you can read the conclusions that I made during this time. Otherwise, I suggest that you familiarize yourself with the lessons that came my way when I was growing up as a new CTO.
Tech management development tree in a startup
Before we get too far, let's figure it out - who the hell is a CTO anyway? This is the question I asked myself when we hired the first couple of engineers on the team. Is the CTO a benevolent eternal dictator who, in the software world, does code oversight? Or is it some kind of super manager or super hacker?
I have asked many people for advice. I reached out to CTOs at Buffer, Unbounce, and other startups that were slightly larger than us. And I got the answer: nobody really knows. This is a fuzzy role that cannot be driven into any framework. In the process of communication, I discovered a number of general patterns of growth of small technology-oriented startups and formulated what the CTO should do at each stage of development.
Since I am nerdy and love to play video games, the development tree seems to me the most obvious. As you gain experience in the game, you increase your level and at certain points you can choose different branches of development.
This is how an STO tree in a startup might look like.
Lone hacker (1-2 engineers)
This is exactly the time when we worked in the basement. It was a fun and fleeting time. You do a lot of things, there is almost no communication and communication overhead, because everyone works in sync. You are just trying to figure out what works and what doesn't.
Small team of coders (2-6 engineers)
As a startup founder, you want to grow your team, so you start hiring people. Usually everyone starts by hiring friends. Some say it's not worth hiring friends, but I think it's great at this early stage. You know you can work with them, you know how smart they are, and they just fit perfectly. The small team stage is when the CTO begins to feel the pain of moving from hacking to something else. It's still pretty good because you only have a couple of engineers. Communication overhead is fairly small. You are still pretty much in sync. You understand what's going on. Nothing surprises you.
Team growth (6-12 engineers)
Then everything gets a little strange. You stop talking to each of the team members. You will have to tackle the terrible mystery of management, for me it was something fundamentally new - in contrast to programming that was understandable and natural for me. It is at this stage that the communication overhead of writing code increases significantly. You may need to consider hiring people who are not your friends. Things get complicated because things start happening that you never knew existed. At this stage, everything happens very quickly, and you will also encounter the first branch in the development tree.
Team organization (12+ engineers)
With a team of this size, you probably work in different areas. You won't be able to cope well with people and code at the same time, so you have to make a choice:
VP of Engineering: focus on managing
CTO: focus on coding and architecture
VP of Engineering is the person who sets up processes, implements tools, that increase overall productivity and help engineers develop. If you remain CTO, you will continue to do things related to the direct coding. It is the CTO who is familiar with the entire system from and to, and also knows where the skeletons are hidden in the closets.
Should you be a CTO?
I was not ready for such a decision. I didn't even know that I would have to make a choice. I thought the CTO would be the de facto manager. This seems to be the case in over half of the startups I spoke to. Regardless of which path you go (managerial or technical), you will have to find someone who will take over the second branch.
To make a decision, it's worth remembering your origins. Where did you spend more time, how confident are you, and what would you like to return to?
At first, your team will only have one or two engineers. All your time will be spent on coding, which is great. When your team has about 6 people, everything will also be fine. About 80% of the time will be spent on coding, and 20% on communication. And the workflow will still feel good. You will be about 90% sure of everything
And then things will get much more difficult. You will be engaged in direct work in half the time, since you will be busy hiring new and new employees. There will be more and more employees who need help, and this is not so great, because you will have to do this and write code as much as before. At this stage, you need to decide what you want to do - management or development. How do you like this movement along the tree of development?
You just need to find the one that makes your dopamine.
This is great advice from a startup founder. Do you feel good if you can help someone cope with a task? Or do you enjoy solving technical problems? It is the answers to these questions that should help you understand which path you should take.
Four lessons from CTOs from different startups
I spoke to 15 founders and CTOs trying to decide what to focus on. I asked each of them what they noticed along the way and the difficulties they faced. In these conversations, four topics constantly surfaced:
1. Accept tipping points
I asked everyone about their biggest mistake - what experience they got out of it and what and how they fixed it. Then I asked them how they would try to prevent it. Everyone thought a little before answering, and then said something like, “You know, I probably wouldn't. We have to go through moments like this to really understand what we are trying to do. To learn how to do it right, you need to get acquainted with the other side. "
In CTO terms, treat inflection points as scaling the service. If you run into bottlenecks, you will have to fix them. This is much more efficient because it is very difficult to predict their occurrence - especially in startups.
2. No Man's Land
This is how I can call a team that consists of 6 to 12 engineers. In such teams, a little bit of everything happens, and it's very confusing. You will notice that you are saying phrases like “Why didn't this person know about this? And didn't he know what to do? " If you are faced with such questions, then you will no longer be able to combine responsibilities - you will need to do one thing, and transfer the other half of the tasks to someone who can cope with them. You are not genius enough to handle two roles at once, but you are not stupid enough to ignore this state of affairs. You seem to be stuck in the middle.
At this stage, communication can help build bridges. If you find yourself saying phrases like “Why did X do this?” Then you should start saying certain things more often. Repeat until people roll their eyes and say, "Same again." This is important because this way you can ensure an equal level of understanding among all employees.
3. Structural mimicry
A lot of the time I've heard CTOs say something like, "Well, we saw how they do it on Spotify or" We saw how Amazon does it. " These people adopted the structure of other companies. If you, as a technology company, innovate, then you should not invent innovative management methods. You shouldn't even come up with something new in the structure of your company. You need to innovate through your technology, code, and products.
Find what you find interesting and try to apply it in your company. Over time, your company will become unique by mixing ideas and ways of organizing that no one else has. You may be able to come up with something yourself, but this should not be your goal. You should try to understand what other people are doing and strive to save yourself the hassle.
4. Focus
The last lesson is based on my personal mistakes. When we started hiring engineers, we thought that more people would allow us to do more work. In the beginning, the founders and the first pair of hired employees literally juggled. It seemed to us that everyone could work on two or three projects - and that was fine. So four engineers can run eight to twelve projects at the same time, right? No, that was a terrible thought.
The more projects, the more communication threads. It is much more difficult to keep track of all the processes and be sure that everyone understands everything. Looking back, I think that when we hired more people, it was worth keeping the workload at the same level, or maybe even lowering it a little.
We just picked one project that everyone focused on. We made it clear to everyone that this is our top priority. There were also some secondary tasks, but they were secondary, our main goal was the main one.
Hope my experience helps those trying to navigate the murky waters of the early stages of startups, especially as a CTO. It would be great if I knew all this in advance, but then maybe I would not get all this experience. Nevertheless, it is absolutely normal to get confused, put off decisions until later and sort it out on the go. All of this is normal, because in the early stages startups have a wide variety of needs.
- Discussion on HackerNews
- Telegram channel "HackerNews in Russian"