The Fork in the Road

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

It’s 2016 and my company, Freckle, is finally seeing real traction with teachers. The self-serve freemium plan is bearing fruit and new classrooms are getting enrolled every day. Kids are hammering the service submitting millions of answers to math problems. We’re fighting to keep the servers running, to add more features, to keep the engineers happy in a market that’s aggressively heating up. Revenue and VC are joining forces to support all this momentum.

Growth is good, but I’m drowning; scaling is kicking my ass. I’m leading close to a dozen developers, reviewing every single pull request, running our bastardized XP-meets-SCRUM delivery process.

I’m investigating support tickets. Is this actually a bug or are the kids trolling their teacher by injecting text into the web page?

I’m the architect, I feel the need to vet every change.

I’m the IT guy. A salesperson’s laptop is choking up on 300 tabs and they need to get on video calls, I think we need to get them a machine with more RAM. Someone needs their password reset. I’m not going to waste a developer’s time on this, but we also can’t afford a person full time to handle it yet. One more thing on my plate, I guess.

I’m doing the first interview for every candidate. Actually, no, I’m doing all of them. I’m hiring, I’m firing, I’m dealing with the aftermath.

I’m blocking the team by taking too long to ship a change that’s been on my plate for days.

I’m in the “exec” Monday morning syncs. I’m regularly pulled into investor conversations for our next fundraise.

Nobody reporting to me feels seasoned enough to pick up any of my batons, and I’m trying to control everything all at once in an effort to ensure success — at least that’s what I’m telling myself. I’m not confident enough in my delegation to trust the junior or mid-level staff with what I’m doing. I have to fire the one guy who had enough experience to be in a lead role; he hasn’t shipped anything in weeks, sigh. Someone quits at the worst time possible and we have a gnarly outage. I stop all caffeine to slow down my anxiety.

I’m losing my marbles, and yet, the cavalry is not coming; I have to dig myself out of this before it gets any worse.

A well-trodden path

Denial is the first response. “You’ll be fine, you can power through, you’re hardcore, something something founder mode” you tell yourself. You have a lot to prove if it’s your first-time in this role, except, you’re human and hit the inevitable limit, 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 or are raising eyebrows. You lack bandwidth to go deep and handle complex tasks that require ample Maker Time. Everything you touch is half-assed; you’re just trying to keep your head above water in a dozen different areas that are all screaming for your attention all at once.

The situation is familiar to every first-time startup CTO who’s experiencing growth and the pull of the market. If you successfully survive the very first phase of your company’s existence—the bit where you’re flinging prototypes at the wall hoping to prove that someone wants what you have—you graduate to traction and further fundraises. You soon reach the limits of how far your team can grow with you in charge of everything. If product management, design, and other roles report to you, you hit that wall even sooner.

Much of what’s challenging for first-time, early stage CTOs here is simply their lack of reps in the realm of management and scaling organizations by adding more people, delegating, forking off teams, and many other tried-and-true techniques. Add identity conflict into the mix, and being so deeply invested in the success of the company as the technical founder and the challenge goes beyond pure management. You care more than anybody else about the company doing well, you have a lot riding on it, and it’s hard for you to let go of control, and yet you must scale.

If you are already an experienced manager and delegator, you can stretch yourself a little further here: you know which reins can be given away with little threat to the trains running properly. But either way, eventually you have to figure out how to scale yourself and the team. There are only so many hours in the day, you can’t cheat physics, and going hero-mode eventually leads to a meltdown.

This is where every early stage CTO faces the inevitable fork in the road.

Technology vs People

For many years now the industry assumed that a growing early-stage startup will divide its engineering leadership into one of the two roles: a CTO and a VP of Engineering (VPE). Years have passed since Fred Wilson wrote that article, but the fundamental principles haven’t changed much. I use the “VP”, “Director”, and “Head” of engineering titles interchangeably here; they’re fundamentally the same role at different seniority levels, at least as far as early stage startups are concerned. Tomahto, tomayto.

This is the choice: do you go all-in on ensuring your company creates and uses awesome technology, or do you choose to spend all day on having the best people and the best processes?

You can’t do both, not well at least; each direction requires full-time dedication and a completely different skill set. Neither path is wrong, but one could be a bad fit for you. Having walked down both of them at different times in my CTO career, I can speak of the nuances behind this choice and how it can impact you. Screwing up this decision can lead to years of dissatisfaction, and yet, knowing in advance which one will be best for you is perhaps not possible. You might only be able to get the answer the hard way.

The good news is that the startup CTO role has always been fluid, flexing to accommodate the unique needs of each company, and the quirks of each person in the seat. As the company approaches PMF and starts to show hints of scale, you get the opportunity to choose how you will partake in this next phase and beyond, and how you will fill the gaps in the team left by you specializing your focus.

The classic Five Flavors of a CTO was a model I often referred to in my up-and-coming technical co-founder days. Your strengths and dispositions influence this a lot. So do the needs of the company. 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 technical 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 does it feel like a distraction from being deep in the product? Would you rather create routines for computers, or for humans?

Do some soul-searching and pick a direction that feels motivating to you for the next few years.

Why the People Path Feels So Unnatural

Unfortunately, many green CTOs aren’t great at all of the squishy people stuff. You wouldn’t be in this seat if your recent career focus was on growing and managing teams; that’s not what the company needs from you the first few years of the business revving up. You cut your teeth on furious shipping iterations, on managing the complexity of a codebase that’s reaching Product-Market Fit, on knowing how every corner of the product works, on staying close to the customer and relentlessly trying to meet their needs.

That’s got nothing to do with being able to build repeatable, clear processes that involve humans working in unison on a common goal. Little to do with understanding why a direct report is struggling and how to fix it. Orthogonal to knowing how to take your more successful people and make them even better. Little in common with how to create a shared sense of purpose.

The 2016 me would have done just about anything rather than spend a whole day in one-on-ones, having career conversations, moonlighting as a therapist—at least that’s what I thought managers were supposed to be at the time. The company needed to keep moving forward. Spending days understanding people’s feelings to retain them in the frenzied meat market of peak-SaaS San Francisco felt misaligned with the short term do-or-die needs of the company running out of runway. Someone is disgruntled that they didn’t get a promotion. “Ugh, why am I spending time on this? How do I make this problem go away and get back to work?” Two employees are beefing. “Why are you pulling me into this?” Someone took offense at something another person said. “OK.. you guys can’t figure this out on your own?” In all fairness, engineers’ engineers tend to be as low on drama as they come, but even playing the game on easy mode felt like a waste of time to me at the time.

With the benefit of hindsight, many managers from that era eventually realized that coddling and worrying about every minuscule inconvenience wasn’t going to scale or lead to great teams, even in light of a really competitive market. But, that’s for a different article. Managerial maturity and expertise ultimately make a huge difference, and employees not hearing the daily siren song of a different company luring them away doesn’t hurt either when you’re trying to focus on advancing this company’s mission. Not constantly fending off incursions from another SaaS “soonicorn” two blocks down on Market St.

It’s really tempting to short-circuit having to learn all this people stuff yourself and instead bring in that expertise from the outside to finally stop drowning. If you go the people route as a first-time CTO, you know you’ll suck for years as you figure all this “managing and scaling teams” stuff out, and you want to stay in the comfortable embrace of being a technical badass. There’s just too much at stake for you to let everybody down for years before your manager and manager-of-managers skills ramp up, so bringing in a VPE feels like a light at the end of the tunnel.

Hiring a People Leader to Handle It for You

You choose to hire someone to manage on your behalf. This person will likely hold a Head, Director or VP title. Lofty titles are one of the perks of startup life even when you only have one team of engineers to manage.

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 gig and they’re eager for a repeat: it’s their comfort zone, they know they’ll be good at it. At times it’s someone who came from managing much larger organizations and believes they will be able to step down in scope and run 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. You likely do not have enough experience to properly vet them, evaluate if they’ll be able to move up one level of managerial abstraction, figure out 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 from scratch.

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 job, 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 and rails 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.

The “done this before” option, unsurprisingly, turns out to be the most consistently reliable: usually it’s 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, not a ton of BigCo 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 VPE taking care of production, making sure the staff is happy, hiring, firing, unleashing processes, likely reporting directly to the CEO—not you—because they want that direct access. Having an additional layer of indirection at an early-stage company makes little sense.

So what does this new addition to the team mean to you, as the newly-specialized technology leader of the company?

The Trade-off

You experience the delights of a clear calendar. Your counterpart is handling one-on-ones, they’re on top of hiring, they’re running delivery. Sure, you just hired them, they could still screw up, and you regularly monitor how they’re doing to make sure things are in check. You get to run tech now, great, but you realize you no longer have an important lever you were used to.

You have removed yourself from controlling the budget—and that can be a real problem. You can’t make hiring decisions unless you disempower the new people leader from owning the process, and you really don’t want to do that. You usually still have veto power if you’re a founder. You should absolutely have a strong opinion on whether someone is a go or no-go as they get towards the end of the hiring funnel. But quality leaders want to be treated as adults and expect autonomy to direct the future of their team, formerly, your team. And rightfully so. Being accountable but not responsible is a bad place for anybody to be.

Remember, you focus on the technology, they focus on people, so you need to set the expectations around your veto card from day one if you want your relationship with the VPE to last. In practice, assuming you are aligned with them on the quality bar for a new hire, you shouldn’t need to intervene often. Whe it does happen, you don’t want your veto to come as a surprise.

And later if you think someone on the team is below the bar, the VPE thinks they’re fine, you can’t do much about it. You feel the company’s bar lowering, but the best tool you have to deal with it is again influence.

Beyond hiring and firing, you end up not having control of the direction of delivery 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 influence. This person does not directly report to you, you can’t get them to do anything they don’t want to.

That means that on the technology front, which you are responsible for, you can’t get anybody to implement your vision unless the VPE and their team agree, or unless you’re doing it all yourself. This is not to to say that mandates are a lever you should be pulling often even as someone’s direct manager, now that option isn’t even on the table. You think that rewrite is mission critical and unlocks big benefits for the team long term? If the VPE thinks that’s a distraction from shipping more product, tough luck, not much you can do about it. You now operate exclusively through influence.

Some CTOs find that very frustrating and wish they had more control over the team. They’re used to the codebase being their baby, to having the final say, and losing that understandably feels disempowering. Others are more zen and accept that it’s the requisite cost of growing up as the team scales, it’s not all about what you want anymore. If you hired the right people, having to get them on board with whatever initiatives might be actually for the best, you end up with higher quality decisions. But you introduce extra coordination steps that go against your “let’s just move fast, here’s what we’re going to do” instincts.

The Skunkworks Mirage

“But wait”, you say, “what about the CTO being given a few engineers to run experimental skunkworks-like projects? They can be out there on the frontier, placing bold bets on new approaches and tooling”. In practice, it’s unclear how effective this mode is, and how often this model succeeds. The company is never swimming in excess budget. The startup needs to hit aggressive metrics every single year as it’s growing, assuming VC backing.

Dedicating staff to experimental endeavors is not going to be palatable to the management team trying to hit ambitious revenue goals mission-critical for the next fundraise. At the early stages, there’s little time for “maybe this technical project will pay off months or years from now”, there’s only time for “we need this feature shipped now so we can move upmarket and close the big customer asking for it”. The aspirational “one day this will pay off” bets end up being sidelined and poorly resourced.

Just incentives at play.

A Matter of Identity

Early on your self-image 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 hands-on contributor since that’s what got you, individually, into that seat, and it got your company to the stage that allowed you to worry about scaling. Nicely done. But holding on to that identity will not get you to the next step.

Knowing what I know now, it’s possible I would’ve still made the same decision at the time, staying on the technical track the first-time around. I feel very fortunate to have learned from talented directors whose best practices and strategies I could then adopt myself when I eventually switched course. Nowadays, however, I advise first-time CTOs to tread these waters carefully and seriously consider the people path.

It Works for Some

At the same time, it’s worth mentioning that there are CTOs out there who are seemingly happy with their choice of staying technically-focused. Greg Brockman of Stripe/OpenAI and John Wang of Assembled explain why they chose to go that route and how it turned out.

My read is that with the right personality, the right amount of company growth, the right partnership with the VPE and the right buy-in from the company, the technical path can work well. I love to see follow-up articles from them years later describing how their choice panned out, with the benefit of hindsight. Would they do it all over again the same way?

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

I remember feeling that, when the time came to pick my own CTO path, nobody on the team had the expertise to replace me technically and to take the lead. In my mind I was special and irreplaceable, nobody could make technical design decisions as well as I could. I thought those decisions were irreversible and company-ending if not done right. I thought we didn’t have time for screw-ups, and my screw-ups would be fewer than others’ screw-ups. Should I have been smarter in my hiring, having a few viable succession candidates? Or did I already have them, but didn’t trust myself to deputize them? Was I way overthinking the whole thing? With more years of management under my belt than most of my team—admittedly still far from many—I was not willing to take bets on my own people. In hindsight, this was a mistake. I overestimated my own competency, irreplaceability, and told myself that others couldn’t live up to that bar.

Only looking in the rearview mirror can I now identify these elaborate stories I created to avoid leaving my comfort zone and avoid mistakes that would have been worth an attempt.

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, impart your personal philosophies onto “the next generation” when it picks up from where you left off. You need to let go of the toys you got used to: having all the answers, having complete control, being always in the loop, sticking to what worked before. Your team will also appreciate having someone with your experience and deep knowledge of the codebase and the customer oversee their development. And they will 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, you feel competent, safe. You worry that letting go of what attracted you to the job to begin with will take all the soul out of the role. Etienne De Bruin of 7CTOs talks about the loss of joy in the work as a technical leader transitions from making to administrating. 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.

And when you get the urge to experience the joy of shipping, of learning a new tool, of feeling closer to the codebase, you have the power to make time for it. It won’t be much, but it might be just enough to bring back some of the maker’s spark.

Given enough time you will likely appreciate the people path, and the satisfaction of a well-operating team that trusts you to take care of them.

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. The VPE of your dreams is out there, I’ve found them, and so can you. You become a kind of distinguished engineer, a 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 public-facing. You could do more sales. Do more speaking engagements, help build the brand to help you hire high-quality people. Get buy-in and do special projects such as making developer onboarding better, improving dev tooling, improving documentation. Remember: 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.