Back to resources

The Evolution of a Startup Co-Founder

Changing A Company
Dev Processes
Company Culture
Impact
Convincing
Changing Company
Career Path

15 March, 2022

Shawn Sullivan
Shawn Sullivan

Cofounder & CTO at Phase Genomics

Shawn Sullivan, Co-founder & CTO at Phase Genomics, shares how his career has spanned from working at a tech giant to co-founding a startup in every stage of his growth.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Leaving Room to Say Things Suck — Leadership Lessons from “Ted Lasso”

17 August

A major sign of trust, comfortability, and vulnerability is for someone you lead to be able to say something sucks.

Building A Team
Company Culture
Leadership
Coaching / Training / Mentorship
John Hartley

John Hartley

Senior Engineering Manager at Curology

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord

How to Enter QA With a Non-Technical Degree

2 August

Lewis Prescott, QA Lead at Cera Care, explains his journey from a degree in psychology to learning test automation and computer programming.

Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Career Path
Lewis Prescott

Lewis Prescott

QA Lead at CeraCare

Leading A (Distributed) Team? Foster "Above the Line" Behaviors.

12 July

No online tool will address your team's ability to connect, collaborate, and deliver results if the individuals don't bring the right mindset to work.

Changing A Company
Building A Team
Company Culture
Leadership
Ownership
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

How to Navigate Your Manager Role at a New Company

1 July

Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.

Managing Up
Managing Expectations
Leadership
Collaboration
New Manager Of Manager
Changing Company
Saikrishna Desaraju

Saikrishna Desaraju

Engineering Manager at Marks and Spencer