The CTO Fork in the Road

The Breaking Point: When You Can’t Do It All Anymore

Every CTO of a successful early stage startup eventually reaches a fork in the road: do you stop being a major individual contributor and switch to the people side, or do you stay hands-on and hire someone else to take care of gardening the teams? Neither path is wrong, but having lived both of them, I can speak of the nuances that are both counter-intuitive and treacherous. Screwing up this decision can lead to years of dissatisfaction with the role.

The pivotal moment arrives around the 7-10 engineer mark, the usual team size around which line managers tend to lose contact with their team’s day-to-day. The co-founder/CTO builds the original version of the product, hires several engineers, and acts as both the main tech lead, architect, and manager for the entire team. They are pulled in all directions: fundraising support, IT, support tickets, shipping product, defining processes, hiring, firing, putting out fires, and many more. That’s a lot for one person, and the cracks start to show.

Denial is the first response. You’ll be fine, you can power through, you’re hardcore. You have a lot to prove after all if it’s your first time in this role. Except you’re human and eventually start falling apart, the sugar-free Red Bulls can only take you so far. The team isn’t getting enough of your attention. Your individual contributions are rushed. You lack bandwidth to go deep and handle complex tasks that require ample Maker Time. Everything you touch feels half-assed, and you’re just trying to keep your head above water. You reach the acceptance stage, you’re at the notorious CTO crossroads.

Stay Technical or Go People-First?

The startup CTO role has always been fluid, flexing to accommodate the unique needs of each company. The classic Five Flavors of a CTO was a model I often went back to in my up-and-coming technical co-founder days. Consumer vs B2B. Deep Tech vs shipping daily. The CTO’s strengths are also a major determinant. Do you do well in front of customers? Do you like to talk at conferences? Can you sell? Can you be the internal face of the company, acting as a pseudo-COO? Are you a deep domain expert that everything is hinging on, or a generalist who is a mile wide and can rally the right people on the right tasks? How well do you manage and lead people, and do you enjoy it at all, or is it a distraction from being deep in the product?

Why the People Path Feels So Unnatural

Unfortunately, many first time CTOs aren’t great at all of the squishy people stuff. We cut our teeth on maniacal shipping, on managing the complexity of a codebase that’s reaching Product-Market Fit, on knowing how every corner of the product works. That’s got nothing to do with being able to build repeatable, clear processes that involve humans. Little to do with understanding why someone might be struggling and how to fix it, or knowing how to take your more successful people and make them even better. Nothing with how to create a shared sense of purpose.

It’s really tempting to short-circuit having to learn all this yourself and bring in that expertise from the outside and finally stop drowning. You’ll suck for years as you figure this all out, and you want to stay in the comfortable embrace of being a technical badass. You hate the idea that you’ll let people down.

Hiring a Director to Handle It for You

You choose to hire someone to manage on your behalf. This person will likely hold a Director or VP title. Lofty titles being one of the perks of startup life.

Identifying the profile of someone ideal for this maneuver is tricky. Sometimes they’re a line manager who believes they can level up to a bigger role. Sometimes they’ve already done this exact swap and they’re eager to do it again, it’s their comfort zone, they know they’ll be good at it. At times it’s someone who came from much larger teams and believes they will be able to step down in scope and manage just a couple of teams for the foreseeable future. Both the first and the last options are the big gambles.

With the first one, you have unproven talent that you hope will pan out. But unless you have good signal that they’ll be able to do it, it is speculative at best. Often in this situation, you do not have enough experience to judge someone and evaluate if they’ll be able to move up one level of managerial abstraction, or if they’ve ever had to define complex processes for a company that needs to move at breakneck speed. They might have executed someone else’s script at a well-functioning company, but never had to test their ability to create that themselves.

For the latter, it’s frequently a seasoned manager from a larger company who got bitten by the early-stage startup bug. Unfortunately, they often romanticize the prospect, and only later realize what they signed themselves up to. It’s hard to step down to a world of duct tape and chewing gum once you’ve learned to lean on the support structures of a larger org. The headcountmaxxing type is going to struggle in a scrappy environment that expects them to accomplish miracles with what little they have. Nevertheless, strong executives who do not need a huge team to feel valued do exist, and are a real gem if you can find one. It helps if this person has had to work at early stages before, thrived in it, and knows what they’re getting themselves into. Without that validation, it’s likely a no-go.

The “done this before” option, unsurprisingly, turns out to be the most consistently reliable: usually someone who hasn’t gone too far up the career ladder, and who really loves this stage of the startup world where they thrive. The company is small enough that everybody knows each other, but not so small that managers or directors are overkill. They can make real change, shape big chunks of the company first-hand, but they don’t have to convince and coordinate for months to accomplish it. Lots of ownership and control, still not a ton of BS. We ended up with this kind of leader multiple times at Freckle, and it was a game changer for the company each time.

Great! Now you have a seasoned people leader taking care of production, making sure the staff is happy, hiring, firing, unleashing processes, very likely reporting directly to the CEO—not you— because they will want that direct access. Having an additional layer at an early-stage company makes no sense.

The Hidden Cost of Stepping Back

Here’s the problem you have: you have suddenly removed yourself from the path of the budget. You are not making hiring decisions unless you’ve disempowered the new director from owning the process. You can still veto things, and you should absolutely have a strong opinion on whether someone is a go or no-go as the founder of the company. But quality leaders will want to be treated as adults and expect autonomy to direct the future of their team. They don’t want you to make decisions on their behalf, and them to take the blame if it’s a bad one. You are the non-managing CTO who is partnering up with them to make the team successful, you end up with little say in this.

You end up not having control of the direction of the product and how engineers are allocated within it. These are not your teams to manage; these are not your decisions to make. The budget is in someone else’s hands, and the most you can do is advise and try to influence through your status. This person does not directly report to you however, you can’t really get them to do anything they don’t want to do. Some CTOs find that very frustrating and wish they had more control over the team. Others find that liberating, they never wanted to touch the people stuff.

The Skunkworks Mirage

“But wait”, you say, “what about the CTO being given a few engineers to run experimental skunkworks-like projects? That sounds like a great idea!” In practice, it’s unclear how effective this is and how often this model succeeds. The company is never swimming in excess budget. The company needs to hit aggressive metrics every single year as it’s growing, assuming a VC backing. Dedicating staff to experimental endeavors is not going to be palatable to most leaders at the company. The natural incentive is to funnel as much money as possible into the product team to ship more product in the hopes of generating more revenue. The aspirational “one day this will pay off” bets end up being sidelined and poorly resourced.

Just incentives at play.

The Identity Crisis of the Technical Founder

This isn’t a particularly fun place to be for a CTO who aspires to have control. Early on your identity as a CTO is tied to your ability to contribute technically. Your identity as a manager is both underdeveloped and unfamiliar. You have not shed the skin of a contributor since that’s what got you there, but holding on to that identity will not get you to the next stage. The transition is tough because you have to let go of the thing that got you all the brownie points for many years, and you’re also the most knowledgeable and technical on the team at that point.

Knowing what I know now, it’s possible I would’ve still made the same decision at that time. I feel very fortunate to learn from talented directors whose best practices and strategies I could then adopt myself. But nowadays I advise first time CTOs to tread these waters carefully and consider the other path.

The Case for Staying in Charge (and Learning to Manage)

I remember feeling that nobody on the team at the time had the expertise I wanted to replace me technically. Should I have hired better? But with many more years of management under the belt, I also realize that I was simply not willing to take bets on my own people when I should have. I likely overestimated my own competency and told myself that others couldn’t live up to that bar. Elaborate stories to avoid leaving the comfort zone, accepting a new role for myself.

The irony is that being a strong technical contributor and architect as the CTO is the best place from which to pass on those duties to someone else: you’re able to judge the quality of someone else’s work, coach them, intervene if necessary, as they do what you used to do before. You just need to let go of the toys you got used to. And they will also appreciate having someone with your experience and deep knowledge of the codebase oversee their development. And they may also appreciate you not trying to control everything so tightly at the cost of their own learning and the speed of progress.

I get it, all the non-people stuff makes you feel valued and respected, the work gives you joy. But is that what the company really needs from you at that point? And if control as a CTO is paramount to you, then accepting this new hat as a people leader is very possibly the better option for you.

Your transition to mostly-manager will be rickety at first, that’s to be expected. Get a coach or two to help you through this, and you’ll be surprised by how fast you can learn. Management and processes aren’t rocket science, every scaling team has had to figure this out, and the best practices are well known. Sure, not everybody gets it right, and plenty of managers are atrocious, but you can get good with the right support.

You stay in charge of the team. You stay in charge of product delivery. You can operate through your best people. Have them run experiments if you want to, it’s your call now. You are not adding any additional layers between the CEO and the engineering team, and this forces you to be that better manager that your team might want from you. As the team scales, you do your best to keep scaling with it, keep getting help and feedback.

Other Paths

And if you discover you really don’t enjoy this type of work, you can always get back to the trenches. You can find someone to replace you once you’re sure you hate it. You become a kind of distinguished engineer figure that everybody loves—seems to have worked out for Mitchell—no longer involved in day-to-day people decisions, but still happy contributing in whatever way they find most engaging.

Or you can explore some of the other flavors. You could become more publicly facing. You could do more sales. Do more speaking engagements, help build the brand to help you in hiring. Get buy-in and do special projects such as making developer onboarding better, improving dev tooling, improving documentation. You aren’t gunning for a promotion, you want to make a difference. Get creative, as long as you are honest with yourself about how much control you want over how the sausage is ultimately made.