The CTO Journey at a Small Startup

As startups grow, we need to make tweaks to the way we work. I’ve found this especially true in engineering. As a co-founder and CTO, my own role has changed a lot over the years. My everyday duties and challenges have shifted, and I’ve had to alter my approach multiple times to help the company reach a new level.

In the early days of Zapier, it was just three guys working nights and weekends, hacking away in the basement on what would become Zapier. We went through three or four versions of Zapier before we came to the one we eventually launched. Six years later we're doing hundreds of millions of API calls and have more than 80+ employees around the entire world, including more than two dozen engineers.

The growth stage between just the three of us and where we are today was pretty tricky. If you prefer, you can watch my takeaways above. Or, read on for the lessons I've learned—from experience and asking others along the way—as I grew as a first time CTO.

Startup Engineering Upgrade Tree

Before we go much further, what the heck is a CTO? This is the kind of question that I was asking myself when we were hiring our first couple engineers. Is it like a benevolent dictator for life, which in software communities is someone who watches over the code? Is it some sort of super manager or super hacker?

I asked a lot of people for advice. I reached out to CTOs at Buffer, Unbounce, and other startups that were a little bit bigger than us. And I got an answer: Nobody really knows. It's a fuzzy sort of role that doesn’t fit easily in a box. As I talked to people, I did discover some common patterns for how a small, tech-centric startup grows—and what a CTO needs to do at each stage.

Since I'm kind of a nerd and like playing video games, it’s made the most sense to me as an upgrade tree. As you get more experience in a game, you level up, and at certain points you can choose different branches.

Here’s how the startup CTO upgrade tree might look.

Solo Hacker (1-2 engineers)

This is the time when we were working in the basement. It’s both a very fun and very fast time. You're building a lot of stuff. You're iterating really quickly. There's really no communication or management overhead because you're all in sync. You're all just trying to figure out what is going to work.

Small Team of Hackers (2-6 engineers)

As a startup founder, you want to grow the team, so you start to hire people. Usually this is when you hire friends. Some say not to hire your friends, but I actually 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 right in. This small team is when the CTO starts to feel the pain of moving from a hacker to something else. It still feels pretty good because you only have a couple engineers. The communication overhead is pretty small. You're still pretty much in sync. Things are happening that you know about. Nothing's really a surprise.

Growing the Team (6-12 engineers)

Then it gets a little weird. You no longer are constantly talking with every single person on the team. You have to start doing this scary thing called management, which for me was totally different. This was not as natural for me as hacking. This is where communication overhead starts to blow right past the time you get to code. You may be trying to figure out how to hire people who aren't your friends. And it gets tricky because things you don’t know about are happening. Things change really quickly in this stage, and you’ll face your first branch on the upgrade tree.

Organizing the Team (12+ engineers)

With a team of this size, you likely are working on different areas. You can’t do a good job of both people and code management, so this is where you get a choice.

VP of Engineering: focus on management
CTO: focus on hacking and architecture

The VP of Engineering is usually the person who puts in place process, puts in place tools to make the team more productive, and helps the engineers work through stuff. Or, you can remain CTO, and maintain the hacker aspects of your role. This is someone who knows the system in and out, who knows where all the skeletons are in the closets.

Should You Still be CTO?

I wasn’t really prepared for this decision. I didn't even know that you had to choose between the two. I just thought the CTO would be the de facto manager. And that seems to be the case for over half of startups I talked to. Whether you go the manager or hacker route, you have to find someone who will do the opposite.

	engineers	time coding	confidence
solo hacker	1 or 2	100%	100%
small team hacker	2-6	~80%	90%
a bit of everything	6-12	< 50%	10-50%
VPE	12+	0%	90%
CTO	12+	~80%	60%

To make the decision, it’s good to think back to where you’ve come from. Where was your time spent, how confident did you feel, and which stage is one you’d like to revisit?

In the early days, it's one or two engineers. You spend all your time hacking. It feels great. Everything's wonderful. Whenever you get that small team of up to 6 people, it still feels pretty good. You're spending about 80 percent of your time hacking, maybe 20 percent communicating. And you still feel pretty good. You're feeling like 90 percent confident about this.

And then when it gets to be a bit of everything—that's where it gets much more difficult. You spend less than 50 percent of your time as you get more and more people. There are more and more people to facilitate, and it just doesn't feel as good, because you’re trying to do that while maintaining your hacking schedule. That is when you have to decide whether to go manager or hacker. So, how do you navigate that tree?

You really need to figure out where you get your dopamine hits

I got this great advice from another founder. Do you feel really good when you help someone do something that they were struggling with and they nail it? Or do you get a hit when you solve some sort of a technical problem? That should give you a little bit of guidance on which way you go.

Four Lessons from Startup CTOs

I interviewed around 15 founders and CTOs as I wrestled with my own decision of where to focus. I asked each one about the things they noticed that were difficult along their journey. Four areas kept popping up in these conversations:

1. Embrace the Breaking Points

I asked everyone for their biggest mistake–the hardest experience they had and how they fixed it. Then I asked how they would prevent it the next time around. Everybody stopped and thought a bit. Then they would say, "You know, I probably wouldn't. We needed to go through that phase to really figure out what we were trying to do. I had to learn the opposite side to learn the proper side."

To put it in CTO terms, treat this breaking point more like scaling a service. You run into the bottlenecks and then you fix them once you hit them. It's much more efficient than trying to predict them because prediction is very difficult, especially in something like a startup.

2. No Man's Land

This is the name that I gave that time between six and 12 engineers. There's a little bit of everything going on and it's kind of confusing. You notice yourself saying things like, "How come this person didn't know about this? And don't they know about what they should've done?" These sorts of questions are a hint that you're in this area where it's difficult to either go one way or the other—either hacker or manager—without having someone to pick up the slack on the other side. You're not big enough to really warrant two different roles, but you're not small enough to where you can ignore it. You're kind of stuck in the middle part.

Communication can be a bridge in this stage. When you find yourself saying things like, "Why did xyz do this?" you need to start over-communicating. Say things over and over again almost to where everybody when they hear you say it again they roll their eyes–"Oh, here we go again." But that's important because then everyone's on the same page.

3. Mimic Structure

So often I would hear these CTOs say, "Well we saw Spotify do this" or "We saw Amazon do that." Then they would emulate that sort of structure. As a tech company, if you're innovating, you should not be innovating in management. You should not be innovating in how you organize your company. You should be innovating with your technology, with your code, and with your product.

Pick out things that you think are interesting and try them in your organization. Over time your company becomes unique, with a melting pot of ideas and ways to structure your organization that no one else really has. And maybe you'll come up with a few things on your own—but that really shouldn't be your goal. You should really be trying to just pick up things other people are doing and save yourself the hassle.

4. Focus Up

This final lesson comes from personal mistakes. When we started hiring engineers, we thought more people meant we could do more things. Early on, the founders and the first couple employees were juggling so many things, as you do, that we thought it was normal for everyone to be working on two or three projects. At four engineers, that’s eight to 12 projects at a time, right? Nope. That was a bad, bad idea.

More projects means a lot more threads of communication. It gets much, much more difficult to keep track of what's going on and to keep everybody on the same page. In retrospect, when we added more teammates, the right solution was to either hold steady in terms of workload, or even pull back a little bit.

The way we did this is we picked one big project that we all focused on and made it super clear to everyone that it was our top priority. There was some secondary stuff going on, but everything was second to this number one goal.

---

I hope my own journey will be a little bit of a help to anyone out there who's trying to navigate the waters of an early startup, especially as a technical founder. It would be great if I knew all of this before I started, but then maybe I wouldn’t appreciate the lessons. Regardless, it's okay to be a little bit confused, delay some of these decisions, and figure it out as you go. That's pretty much par for the course, because it’s natural for a startup to need different things at different stages.