The Evolution of a Startup Co-Founder

The Jump From a Tech Giant to Co-founding a Startup

When I started working at one of the tech giants, it was a well-established company shipping well-established products. They had standard procedures for everything, and I was on rails in terms of my career progression. There was a strong sense of knowing what was expected of me, what succeeding looked like, and what I needed to achieve to get that next promotion. Besides that, I had many coworkers I could come to for advice or mentorship, as they had walked down the same path I had started on. That all changed when I switched to founding a company of my own. I did not realize how my role would change over time as my company grew and matured. My core problem became making sure I was doing the most important things for at every stage along the way, without a well-worn process to know what that was.

From the CTO standpoint, I’m in charge of the technology and product, and play a large role helping figure out what we are supposed to do next. The evolution of the role of a Co-founder and CTO is enormous; every time the company expands in size, the role changes in noticeable ways. I tended to see my role evolve logarithmically, changing significantly every time we ~doubled in size.

How Growth Needs to Evolve at Every Startup Stage

Right after founding, as much as we needed to get our feet on the ground as a company, find investors, start hiring and look for customers, I personally needed to start executing on building products. From a tactical standpoint, I was constantly looking for problems to solve and efficient ways to get things done. Sometimes that would mean cutting corners and implementation, as much as that hurts my inner engineer.

During the early days, it’s critical not to spend too much time trying to write perfect code. The goal is to create something good enough to bring to the customers or investors, or altogether scrap if it turns out not to be a good idea. The concept of a “minimum viable product” from “The Lean Startup” by Eric Ries is relevant here: do just enough work to test your hypothetical value proposition with customers or other stakeholders.

These early days are often crunch time, working 12, 16, even 20 hours a day to get the first draft of a promising product. After that, the next step is hiring a few other folks who can help continue building out the product. Once you have a few people reporting to you, the CTO role expands to include thinking about using their skills to make a better product. You likely still write just as much code as before, but you’re now managing 1-2 other coders too. To find and work with the right coders at this stage, ask yourself what your engineering priorities are, and hire people who will help you achieve those goals. The first priority for me in this stage was looking at features that hadn’t been built yet and finding people who could build them. The second priority was paying off some of the tech debt I created in the early army-of-one days, in order to make the products a little more robust.

However, there is not much coordination needed between the employees in these initial stages. Everybody can talk to each other and be on the same page without many processes required, and managing the team is more about facilitating prioritization and communication, rather than directing or planning. As the number of employees grows towards four or so, it becomes essential to think about how the team can operate as a unit. Standups, scrum, kanban boards, plan-build-ship, the CTO should form an opinion and lead the implementation of some kind of engineering rhythm by this stage. Even if the process is informal, it should be clear that it is informal by design, so the team knows what to expect.

When the team members reach about eight employees, team structure starts to become important. Prior to having this many employees, you likely only have one person working in a particular area, everyone has a good degree of expertise in their work, and it’s easy for everyone to be aware in detail of what everyone is working on. A pretty flat, informal team structure makes a lot of sense as long as those qualities remain true for your team. Around the point of having eight or so team members, however, a division of teams may start to be appealing. For example, perhaps you’d like one team to work on the back-end, with one of them acting as tech or team lead while the rest can work on the front-end or machine learning. You might also want more than one backlog by this point, perhaps to separate independent areas of work or because you have different customer segments or even products you need to execute on.

One key here is to decide at what point you want some help just with the people management aspects of your role leading the engineering and product organization. In my case, I was comfortable with having around eight direct reports, and after that, I added a layer of 3 leads between me and our individual contributors to ensure everyone had good management support. Practically speaking, one way to find the point at which you may want help managing the team is to think about how many hours per week per report you want to have available. For me, I like to be able to have as much as two hours per report per week for 1:1’s, one-off advice chats, attending meetings they call and preparing for all these things. With 8 reports, that means I would be setting aside 16 hours per week, nominally two workdays (even if you’re working more than 40 hours per week, these meetings with reports should almost always be during business hours, so you are spending two days’ worth of your “meeting time” with them). These thresholds will be different for every CTO so there isn’t a cut-and-dry formula for them, and you may still have some or all ICs reporting to you at this stage. Nonetheless, it’s still important to think through your responsibilities as a manager so you can be sure your team has the support it needs.

By the time you reach around 16 engineers in your company, as the CTO, your primary focus becomes be on how to steer the organization. You probably shouldn’t be writing code anymore (you’re likely busy enough you are out of touch and would do more harm than good), and instead you should spend your time communicating your product and technical vision to your team and ensuring they know what you are trying to build. You should also be thinking about whether you are investing the right amount of resources in the different parts of your product, and representing that resource allocation to the CEO, product team, and any other stakeholders who depend on you and your team to create things.

By this point, you as the Founder/CTO will likely have become a manager of managers, without any ICs as reports; instead, your reports are first-level managers. It is now your job to guide them to become better managers and support their reports. Managing managers is a substantially different kind of management because you are a bit more disconnected from the boots on the ground in your organization. Instead, you have to work with their managers to steer their team, which requires even more of your energy to go into things like communicating your vision, setting priorities, and allocating resources.

Our team currently has 24 members, so my advice for stages of growth at the next level (~32 employees) is evolving and I’ll touch on it in a future article. However, thus far, I would say one important change is beginning to push the managers to think about what should be going on at a strategic level, and gaining comfort delegating more important decisions while still trying to own the overall strategy and execution of the team. It’s a great challenge, and exciting to see how it develops.

Be Ready to Evolve Throughout the Stages

• The changes in the Founder/CTO role at a startup happen more dramatically than you expect them to be. Always predict them to be bigger and different than projected, and be flexible and ready to adjust. Recognize that your role will change, and in that regard, you have to change; otherwise, you may become the bottleneck.