What is a Startup CTO?

It’s 2014, a couple of years since I started as the technical co-founder and CTO at Freckle Education, and I am realizing that I have no idea what I’m doing. I’m running technology, I have a few developers reporting to me, we finish the Imagine K-12 incubator—later folded into YCombinator—and raise a seed. Not bad, it feels like I’m doing at least some of the right moves, but I’m completely improvising my way through this, and I hate that. There’s got to be “the right way” here. What is the template? Is there a blueprint for me to follow? I can’t just keep guessing my way through this, can I?

We are given lots of advice around lean startup development and how to fundraise and how to talk to customers, but I don’t remember hearing even once anybody mention what a technical co-founder and CTO of a company was supposed to do. It’s as if you are just supposed to somehow know what the best practices are, what to do. It feels like the only real requirement for the job is, “Are you a hardcore, software developer wizard who is going to be able to build the thing? Just do the Woz thing”.

I would ask the experts, but I’m fresh to the Bay Area and Silicon Valley, having put all of my belongings into a 1999 second hand beater and driven down from Seattle’s Capitol Hill to a moldy apartment complex in the thrilling town of Colma, a couple of miles south of SF. The only place that will take me as a renter with zero income and no prospects for a job, but a big dream and the willingness to grind towards greatness.

In 2025 I either personally know the right person to ask, or have direct access to countless private chat groups of founders and operators who have already figured it out, usually brought together through alumni networks like YC or a16z. Worst case I can usually get a warm intro to someone really competent and get an answer; there’s a sense of camaraderie among those who have done their time in the arena.

In 2014 I don’t know a soul, and I can hardly figure out the right questions to ask. Nobody serious wants to give you any of their time, you’re just another space cadet landing into the Bay, likely to fizzle out in a year as your startup dreams do not materialize, packing your bags and hopping on a plane back to wherever you came from. No point wasting time on you until you’ve paid your dues, until you’ve proven that you have skin in the game.

When you’re just starting out in “the scene” you can’t get too picky. The first prospective co-founder “business guy” I meet in the Bay is working on a location-based social networking app named Trumpeti, a product that lets you “toot your own trumpet” the instant you walk into a new venue where you want to connect with strangers. It’s like Grindr, but with none of the payoff, or hopes of traction for that matter. He needs a tech guy to build it for him. I respectfully move on. Every other new startup hopeful meetup for outsiders like you feels like this.

You milk whatever weak personal connections you might still have from back home. Someone’s cousin was friends with your former pothead roommate in college and might have raised a round at one point in the 2000s and might still be in the startup game and have something valuable to teach you. All of the events we have access to are chock-full of people like us who are also looking for answers, also having never done any of this before. Startup podcasts are nowhere near the monster scale they are today. YouTube isn’t filled with hundreds of YC partner videos handing out advice. No countless Startup School lectures hand-holding you through every step of company building. No ChatGPT-alikes to at least ballpark an answer. The knowledge feels held by insiders, with the rest trying to look over the wall for any hint of guidance. I’m having no luck getting real quality advice here, and the little I’m getting, I can’t assess for quality.

Sure, I can sling pretty decent code, but it turns out that doesn’t take you too far. People never mention that if you start succeeding, soon after you are supposed to grow a team, manage a bunch of people across disciplines, elect managers and directors, explain what you’re doing and why to the other verticals within the company, make sure that every other department has what they need technology-wise to be at their most effective. Somehow you are supposed to know how to prioritize all of that correctly and intuitively. And don’t forget to keep coding, while also not burning out after a few years. “It’s a marathon, not a sprint” - ok, but it sure doesn’t feel like it when you’re six months away from running out of cash and PMF is nowhere to be found. And if you’re riding a rocketship, you have the reverse problem: too much of a good thing, and you are completely unprepared to tame the beast that acquired a life of its own and is trying to throw you off.

Maybe investors assume that you will find yourself a great tactical advisor, they can only help you so much at your stage, with many companies like yours in their portfolio and your chances of kicking the bucket still ultra-high. Your ego gets in the way as well. “I’ll figure this out on my own” you tell yourself, not knowing what you don’t know, not fully realizing how much you would benefit from guidance. And a lot of coaches you would run into would talk about the philosophy of company building, not give you real actionable moment-to-moment tactical advice of how to make yourself, your team, and your company the most successful through your particular skill set. “Ok, but what do you truly want for yourself at this moment?” and not much when it came to “I have a disgruntled employee who thought they deserved a promotion, but we only had enough budget for one, and someone else was clearly more deserving, and now they’re upset, and I really need them on the team. I have a really strong hunch they’re talking to another company, and I want to turn this around before it’s too late.” I join a support group for early stage CTOs, but it’s again the blind leading the blind. At least you’re feeling like you’re in this together.

I remember stumbling around for a few years asking what others were doing, but it felt like everybody at my stage was about as clueless as I was as far as what the job entailed, also blinded by this assumption that you just had to know it if you were a serious developer. Finding someone who had been in your shoes who was willing to spend the time to help you understand what to do was a tricky. I didn’t personally know anyone in my network, and the people who were the most successful in the role were heads-down working as hard as they could on their respective companies, so they really didn’t have the time to advise me or help me on a regular basis.

Years later I finally manage to duck-tape together a small buffet of sources of information. I stumble upon the CTO Summit series of events (nowadays known as CTO Connection) organized in San Francisco for CTOs of companies of all sizes. I start meeting other people who have made it past the escape velocity of pre-Seed and Seed Round PMF-chasing and had gotten to the stage where they were building organizations and having to figure out how to run teams that were consistently winning.

I eventually found a mentor, Bill Crane of LinkedIn fame, who was willing to spend the time to explain what at the time felt complicated and scary and company-threatening, but to him were a very predictable and entirely manageable part of doing the job, which only years later I realized was a perception that I got to. Here was someone who had had to solve my problems again, and again, and came out on the other side winning. Bill was practical and pragmatic, he saw the big picture, but also knew every tactic under the sun and when to apply it. Less about “how does this make you feel” and more about “here’s how you could make this problem go away.” My kind of guy.

Beyond that, working with a great director of engineering who helped take over the people management side of things during Freckle was really instrumental for me for allowing me to see how a real professional in this area handled what I found to be really challenging and how he was able to nonchalantly navigate those difficult waters and come out winning every single time

Years later, I start my second VC-backed company, this time backed by Andreessen Horowitz’s Speedrun incubator, one of the few credible options if you want to blend venture investment with building a high-growth game studio. I get the appreciation of how much easier it all is the second time around when you weren’t facing these challenges for the first time, but everything felt like riding a bicycle. The industry was different, the scale was again back down to that initial pre-seed stage, but hiring, managing processes, culture, best practices, architecture, and working with the rest of the disciplines was pure second nature at that point. And what might have felt scary 12 years earlier was actually just another day at the office at that point.

Difficult to define

The CTO is one of those hard-to-pin-down roles in the startup world. Everybody has a version in their head of what this person is supposed to do, and often they aren’t the same thing. A few things complicate the situation.

The role has traditionally been pretty flexible based on the individual’s disposition and the company’s needs. Sometimes you’re the deep tech expert on whose ideas the company bet the farm. Sometimes you’re an amazing technical people leader, not spending too much time thinking about the tech, with a trusted lieutenant who does that for you. Sometimes you’re the face of the company selling the product to other developers like you, traveling from conference to conference, bearing good news. And many more.

The industry you’re in makes a difference too. Running technology at an aerospace startup, at a game studio, an AI lab or at a web dev shop slinging CRUD GPT-wrappers all may require something different from you.

The stage you’re at also completely changes your day to day. More on that later.

Regardless of the above though, the common theme is that you’re someone who is responsible for the technical decisions at the company, you’re ultimately accountable for things going well, or poorly, on the research and development side of the company. The proverbial buck stops at you, and if it passes you and ends up on the CEO’s desk, you have a problem.

Hired vs grown

The two most common paths for a CTO to land a gig at a “traditional” Silicon Valley-style VC-backed startup is either:

1. By co-founding it as the technical counterpart to the business co-founder
2. By joining it (usually at a slightly later stage, around YC or after) once the company has some proof of product-market fit and is looking for a technical leader who will take them from that early prototype stage to as far as the company is able to grow

Both paths are perfectly valid, although the dynamics understandably change when the CTO is the technical co-founder and has a much larger vested stake in the success of the business, when the CTO is, potentially, more mercenary about it due to a very different slice of the cap table being allocated to them at the end of the day, what they do in either situation should probably not change much, but one’s motivation and commitment to stick around for the business and make it work at all costs might be decently influenced by that allocation.

The other difference is that the technical co-founder is going to have to go through all of the stages of evolution of this particular role, starting with the very first one, when they are the first one and only technical contributor on a team, whereas the hired CTO will typically come in later when there is more management to be done.

First-time technical co-founders will typically be a lot more green and will need a lot more support to find their footing in the role. Professional CTOs being hired into their position will typically end up there because they already have solid pre-existing experience; they’re likely not on their very first rodeo in the position.

When do you actually need a CTO?

Outside of deep tech plays, a CTO is overkill for most pre-seed or seed stage companies unless they’re a cofounder doing all of the initial development on the startup’s shoestring budget. CRUD apps, GPT wrappers and other projects innovating more on workflows and distribution than on the fundamental technical bet can get away with less technical expertise right out of the gate.

Nowadays I believe that most early stage CEOs would be plenty happy with a product-minded founding engineer (effectively a lead engineer of one, at least at first) who is going to take the company from a prototype to a working product that they’re iterating on quickly in close collaboration with whoever else is on the team at that moment. You can of course deploy an experienced startup CTO into this situation, but they have to be prepared to be a full-time IC for many years in case the company never finds market pull. Given a sufficiently frothy market, you could raise a ton of VC and hire a sizable team to execute that initial search under your supervision, but premature scaling is one of those startup cardinal sins that you should commit at your own peril.

If a company doesn’t start with a core technical contributor who is going to go the distance and grow in their role concurrently with the startup—something that’s actually becoming rarer every day if you look at the more recent trends of YC batches as a proxy for the rest of the tech startup industry—then the company will benefit more from a founding engineer, not a professional technical leader who’s going to turn off most of their skillset for a few year and live inside of vim. The full package, someone who will engineer, lead, hire, manage and beyond will be too expensive for most startups and will need to come in as a co-founder, not a hired gun. The team will benefit the most from a donkey, not a unicorn, and that will usually come in the form of a founding engineer, short of the existing founders being celebrities in the technology world and being able to get a real deal on high-end talent. For most 19-year-old Stanford dropouts with a SAFE from hot incubator du jour, that’s not on the menu.

If you are considering joining an early stage startup as a hired CTO, then usually the 5-10-ish engineers stage + high-probability company growth stage is a great time to consider the gig. You get to flex most of your muscles, you don’t have to potentially be stuck in the full-time IC land for years and have the business not take off if ultimately it strikes no PMF. Unless that’s what you find motivating, in which case by all means, go for it. You can join later too, but the earlier you come on board, the less potentially dysfunctional culture you have to deprogram from the time when the inmates were running the asylum. There’s no right or wrong answer here, just trade-offs.

Stages of a CTO

The only constant of the role is that your role is going to be in constant flux; the faster the growth, the more change you can expect. The more flexible you are about your specialization, your identity, and about providing what the company needs at all times, the smoother this ride is going to be. The limiters on this will be your own personal interest in new responsibilities, your capacity to learn a new job quickly, and your willingness to let go once it’s time for someone else to pick up the torch.

Every job you do is temporary, whether the company is successful or not: you’ll either keep shedding skins, or you’ll close shop and move on to something else. You could land somewhere in between and be a low growth “startup” zombie for years, but hopefully you find an escape route and grow out of it, instead of being stuck in place waiting to run out of morale.

I like Klaas Ardinois’s framework as a starting point for the stages of a startup CTO, with a few alterations from yours truly.

The first stage is the Workhorse CTO Stage: the CTO rolls up their sleeves and gets to work, implementing as much product as possible, working close to the customer and the rest of the team, seeking signs of life for the product and the business model. You’re seeking a real customer painpoint, and you’re seeking a solution to it. You’re mostly in the Desirability and Feasibility section of the IDEO framework, which you’ll keep refining and expanding with each iteration. Most of what you’ll hypothesize and implement at this point will be throw-away, but the hope is that you find a unique insight in the idea maze before you run out of money, morale, or more probably both.

Your initial assumptions about what customers want and how to deliver it to them will likely not work, but schlepping through learnings has a chance to land you somewhere valuable. It’s unlikely you’ll nail the fit perfectly at the pre-seed stage of your company, assuming you’re raising VC, but you will do your best to get strong indicators that the pain is real, so that you can raise another round to solve it in a more productized and professional way.

You may have a few engineers working with you, whatever your initial investment (or more likely savings and friends & family round) can afford. You’ll be doing most of the work though, planting the seeds of culture, workflows, vibes, and company strategy that you’ll nurture over many years to come, at least assuming you find a problem that will sustain the business.

I agree with Dylan Field that with the advent of more and more AI-enhanced tools talented people can cover several disciplines at once and get lots of leverage out of the recent innovation coming out of the AI labs and tooling built on top of them. A CTO can be a product manager, a designer, a programmer, a QA tester and much more all at once with the right augmentation. Throw a few more hard working and self-motivated generalists onto the team and you can shred through iterations faster than ever before, you can keep the scale—and the cost of communication it comes with—under better control than in days of yore. The concept of Tiny Teams and Naval Ravikant’s philosophy around people curation are very much in line with my own thinking here. All of this to say that nowadays you can get away with a tiny team much longer than in the past, and you should take full advantage of this unique opportunity.

Nothing you do at this stage of the company is permanent and fatal in the long-term, except for not finding a sufficiently meaningful customer pain point. Your workflows, your codebase, your tooling choice, even your team are not going to stay the same past this stage, and you will have to re-do it all anyway as you gain more scale and experience. Still, creating a culture of hard work, simplicity, feedback, openness, focus on pain point validation over technical exhibitionism, and of not being married to any output of your labor is a great idea even this early.

Your first hires will need to already demonstrate or be eager to absorb these values. They will also need to be as great as you can get away with hiring, as it will be difficult to attract even better hires down the line if the first batch is “OK-at-best”. That, unfortunately, requires that you yourself are able to stand out and attract talent who sees themselves working with you, and you will have to learn how to spot great talent that everybody else has ignored due to not looking obviously great. That’s for another post though.

Then comes the Hybrid Manager CTO Stage, where the company has now raised enough funds to be able to hire a team or two worth of engineers who are now doing most of the work. The CTO still contributes here and there to stay close to the work, but beyond the 7-10 reports territory there’s only so much individual contribution that you’ll be able to do, short of a highly independent and self-motivated team—a good idea!—and perhaps a tech lead or two to help you spread some of the load.

You’re still likely the architect, you’re still a coder, but you’re also running the process, managing the growing team, working closely with product and other disciplines. It’s a gradual transition from being a full-time hands-on workhorse to doing it all at once, as you make your way towards the decision of which focus path to take longer term.

Here the hiring and cultural choices you make become progressively more irreversible as the team begins to solidify around the behaviors you choose to reward and the incentives you put in place. A relaxed and work-life-balanced environment you have supported for a few years will not suddenly transform into a maniacal Muskian sleep-under-your-desk factory hellscape anymore, everybody you have hired so far bought into a particular social contract which you have reinforced again and again. Changing direction now would require re-negotiating those expectations and likely would lose you every hire except for the most desperate ones. And staff loss at this stage would likely lead to customer churn as you finally have a product that’s working that you are trying to protect. Not that the transformation is likely anyway: companies are ultimately reflections and expressions of the founders’ personality, and if you went into it being harmonious and cuddly at all costs, becoming ultra-hardcore over night would ultimately be inauthentic and fail as you regress to your habitual wiring.

Next up comes the Fork in the Road, where the CTO will typically choose a specialization as the team scales. They will either go the technology focus route, with no or few direct reports, or the people focus route, with their entire attention on nurturing and growing the engineering organization as the company is scaling. Here the CTO is managing multiple managers and eventually directors as the team expands and specializes. The product is working, the sales flywheel is spinning, customers are retaining, the company is reaching some degree of stability. Right around this time it becomes clearer if the scaleup née startup is going to keep furiously growing or if it is hitting an asymptote and expansion will taper off, leading eventually to a very different organization that one that’s blitzscaling in a large winner-take-all-market. Some companies 10x their staff year-after-year even at this stage, while others will add maybe another 10 employees. You could be a Loopt, or you could be an OpenAI, both Sam Altman projects, wildly different outcomes.

At this stage, between those two paths you can take, you’re managing managers, directors, and VPs, whatever these titles mean in the context of startup inflation. You’re part of the executive team, worrying about strategy, leading a slower and larger company, managing budgets, roadmaps, placing bets that will take months or years to validate, and keeping middle managers from yelling at each other. You’re aligning the technology with the progressively bigger scope of the business, and you’re organizing the people around it so that the train is running full-steam in spite of all of the extra coordination that needs to happen across those human networks. You show up to work and someone new works at your company who you’ve never met before. Fresh hires have no clue who you are. You’re spread over multiple offices and geographies and it’s unclear if those have much in common, culturally speaking, with what you got used to at HQ with your watchful eye being able to direct things. You get the idea.

Beyond this point we’re talking about organizations with hundreds, or thousands of employees, and if you’re reading this there’s a good chance this won’t be a challenge you face for at least some time. Companies as large as Microsoft, Amazon, and Meta have their respective CTOs who spend most of their day doing evangelism, technical strategy, and executive-level management of the engineering verticals of their org charts. If you ever get to the stage of your career and you want to share what it’s like to operate at that scale, I would love to hear from you. I won’t speak for this stage, as it’s far outside of my personal expertise.

What separates the good ones from the mid?

It’s hard to define one simple set of criteria that will be applicable and define a great CTO across every single stage of the company, but there are general traits, at least in the early-to-mid stages of a startup.

A great startup CTO is obviously deeply technical, likely a specialist in one or more areas of technology they had a chance to spend years on, but at the same time you’re also a generalist. You’re comfortable up and down the stack, you can quickly pick up new technologies and become “good enough” at them to the point where you can ship at least a B+ grade change in them. At the same time you know your limitations, that you will not be a deep domain expert at most of what you touch, and that’s a normal and healthy part of the job. You know how to identify a great expert who will be able to pick up the baton from where you left off and go much deeper than you ever will, and you will be able to guide them towards where the business will benefit the most from their expertise, deferring to their specialization, while also knowing where to drop initiative that are not bearing fruit, and where the push the team to deliver something better they thought they could. You’re able to drop in, pick up any area of the codebase given enough time, understand the workflows, the local customs, contribute and provide advice and bounce out once you’re no longer needed. The great CTO never forgets that the business and the mission of the company come first, and the technology is there in a supporting role, not an end unto itself.

A great early-stage CTO is able to identify talent that others might have missed, phenomenal candidates that don’t have the aesthetic and the credentials that make them obviously good hires at other more pedigreed companies. The CTO identifies the market inefficiency and jumps on the opportunity to bring the undiscovered talent on board and teach them the ways of the team, giving them an opportunity to join an elite organization, while the company gets a great deal on someone who’s not yet been identified as a star. Everybody can identify a PhD from MIT with a maniacal work ethic and a stint as a founding engineer at Cursor, but that also puts them outside of the budget of most startups who would still like that caliber of employee. This is where a great CTO can build a stellar team by finding the undiscovered geniuses. Just to be clear, this is very hard to pull off and most don’t succeed at it, and it can make-or-break the company. Of course having a serious brand name and a reputation in the technology community doesn’t hurt, but that will be out of reach for most first-timers. Constantly building a network of talented product professionals—I use this term loosely here to include designers, programmers, product managers, scientists etc.—is a great idea as well, so that you always have access to a pool of great people ready to join the cause with someone they already know and perhaps even trust.

A great startup CTO is a team player who is excellent at the people stuff, regardless of whether they’re a manager and growing people, or if they’re fully technical, but still needing to explain, persuade, and bring others on board with their initiatives. Regardless of which direction they take, be that gnarly technical projects, management, sales, or evangelism, everything the CTO will be facing will be accomplished with the help and enthusiastic collaboration of others. The technology is ultimately just the flavor on top of a dish made almost entirely of human relationships and shared efforts, even though that might not appear so at first glance.

A great startup CTO communicates technology to every other discipline. They’re empathetic with the challenges of other specializations and can enhance their effectiveness with tools. They’re always looking ahead at where tech is going, where their industry is headed, what the competition might be up to, and they try to stay ahead of it all and envision where they could steer the ship to avoid playing catch-up, but instead stay ahead.