If you look at all of the C-level roles out there, the only one that has no template or definition is CTO.
—Charity Majors
It’s 2014, a couple of years since I started as the technical co-founder and CTO at Freckle Education, and I realize I have no idea what I’m doing. I’m running technology, I have a couple of developers reporting to me. We’ve just finished the Imagine K-12 incubator—which would later fold into YCombinator—and have a few million of seed funding in the bank. It feels like I’m doing some of the moves right, but I’m completely improvising my way through this, and I hate that.
Every big decision is nerve-wracking; the day-to-day choices aren’t much easier. Do I ignore everything and just crank out more code? Do I hire more people? Fire someone? Do I adopt a hot new Javascript framework going viral on Hacker News? Do I switch us to holacracy, or whatever other management fad everybody is talking about? Maybe we should adopt Kanban. Oh, look, there’s a new post on how Extreme Programming will make your team even more productive. Perhaps this is all bullshit, and I should be looking for deeper fundamentals. But, if so, what do they even look like?
There’s got to be “the right way” here, some kind of a template. I can’t just keep guessing my way through this. My direct reports are starting to give me that look that says “Oh no, is he totally making it up on the fly again?”, but maybe that’s all in my head. They’re as green as I am, maybe they think this is how a team is supposed to be run.
As early-stage founders going through accelerators, we get flooded with advice: lean startup tactics, how to fundraise, how to talk to customers, how to avoid doing work that feels productive but isn’t. Find the customer pain point. Validate. Ship an MVP. Try to close a sale to get real signal. Don’t fall into tarpit ideas. Read The Lean Startup, The Startup Owner’s Manual, or Running Lean. What I don’t remember ever hearing is what a technical cofounder, a CTO, is actually supposed to do.
The implicit job description always felt like: “Be a hardcore software wizard, leave all the messy business stuff to the other guy, wear a ratty startup T-shirt from some long-forgotten hackathon, lock in, have a Red Bull, iterate, be cracked.” Back then we called them “code ninjas,” long before the arrival of the “10x engineer” and its now-illustrious descendant, the “cracked” developer. Anyways, the message was: “Just do the Woz thing. It worked out great for those guys.”
I would have loved to ask the experts, but I’m fresh to the Bay Area. I could maybe reach out to my former coworkers, but they have been in the warm embrace of a megacorp their whole lives, they’re of little help here. I put all of my belongings into a 1999 3 Series thirdhand beater—the first year they dropped cassettes and put in a CD player—and drove down from Seattle’s Capitol Hill to a moldy apartment complex in the thrilling town of Colma, a couple of miles south of SF. It’s the only place that will take me as a renter with zero income and zero job prospects. Turns out most are not reassured in my credit-worthiness by a big dream, a willingness to grind, and an academic knowledge of Paul Graham quotes.
A decade later, I will 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 groups like YC, a16z, small investor networks or former Freckle staff. Worst case I can 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, especially if you’re still in the thick of it and haven’t moved on to more common sense pursuits like VC or a big corpo gig.
But 2014 me has none of that; I don’t know a soul, nor the right questions to ask. At least it’s not as rudderless as it was just a couple of years earlier.
The origins
When you’re completely new to “the scene” and nameless, to boot, nobody serious wants to give you any of their time. I feel like just another hopeful landing in the Bay, one bad year away from packing my bags and flying back to SeaTac. Why spend time on you? The flight isn’t what scares me; it’s walking back into my old office with my tail between my legs. That little internal chorus of “So, how’d the big startup adventure go? Guess you weren’t too good for us after all?” is already playing in my head. Of course it’s all silly and myopic in retrospect, but what does the 20-something me know?
Only years later do I appreciate how unlikely it is for anyone to “make it” here, luck being the only thing missing from many smarter and harder working founders. It felt like until I showed real chops, and that I was going to stick around no matter how many rejections, no one in the Valley would bother wasting their time on me. There were a thousand other strivers they could bet on, the stream of new hopefuls was already steady back then, and it’s only gotten more intense since.
I remember 2012 as I’m trying to at least find a business partner, I think that’s step n.1? In no position to be picky, I meet my first prospective Bay Area co-founder “business guy.” He’s working on Trumpeti, a location-based social networking app, a product that lets you “toot your own trumpet” the instant you walk into a coffee shop where you want to connect with strangers. Think: Grindr meets LinkedIn, minus the payoff. He needs a tech guy to build it for him. He claims the idea will forever change how humans connect. This is the first of many “once-in-a-lifetime opportunities" I will respectfully decline as I move on to my next co-founder date.
A couple of years later I’m in a much better place, I have a co-founder, a startup, some money in the bank, now I just need to figure out the next layer of questions I’m oblivious about. No longer about “how to get started”, but now about “how to actually CTO”.
Getting help
You milk whatever weak personal connections you still have from back home, trying to get answers on what it’s like to do this gig. 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. Everybody is looking for answers, also having never done any of this before, it’s one big LARP session. Startup podcasts are in their infancy. YouTube isn’t filled with hundreds of YC partner videos handing out advice. It’s TED Talks, Ray William Johnson, Ron Paul videos and epic fail compilations. No countless Startup School lectures hand-holding you through every step of company building. No ChatGPT. A few insiders have the knowledge, with the rest trying to look over the wall for any hint of guidance. I’m having no luck getting real 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 far. People never mention that if you start succeeding, soon after you’re supposed to grow a team, figure out a process, elect managers and directors, explain what you’re doing and why to the other verticals within the company, design the org and the processes as everything changes, take long-term technical bets, and much more. Somehow you need to figure out how to prioritize all of that. And somehow you must keep coding to stay relevant. But, please don’t burn out, somehow.
Everyone says, “It’s a marathon, not a sprint.” but it sure doesn’t feel like it when you’re six months away from running out of cash and product-market fit (PMF) is nowhere to be found. This is running an ultramarathon at a 5k pace, you feel the pressure to figure this out fast before the music stops. You think that maybe your investors can help, but they know only so many specialists and domain experts, and you’re still a young company, maybe they don’t want to pull all the stops for someone with a 90% chance of cratering. The ROI on that social capital spent might not be there, who knows. Either way they’re off to the next batch, or off to finding the next firm to bring into the fold. You’re mostly on your own now.
Perhaps you could ask for even more help, but your ego keeps getting in the way. “I’ll figure this out on my own” you tell yourself, “High agency! Founder more!” still not knowing what you don’t know, not fully realizing how much you would benefit from guidance. And even if you were open to it, you’re not sure who to trust. Plenty of coaches preach about the philosophy of company building—without ever sharing tactical advice. “Ok, I’ll read High Output Management as you suggest, but I don’t think that’s helping much at my scale..”
“What do you truly want for yourself?” a guru-slash-coach invites you to reflect, exploring your feelings, your relationships, your self-perception, in search of an authentic self. But that isn’t much help when this very week, you have a disgruntled employee who thinks they deserved a missed promotion, but you only had enough budget for one, and someone else was clearly more deserving, and now they’re upset, but you really need them to not leave. You have a really strong hunch they’re already talking to another company, that’s a lot of doctor’s appointments in one week. You want to turn this around before it’s too late—and you need to know what to do next, not ponder the transcendent meaning of your founder journey. Fewer crystals and sound baths and more “this is how you get yourself out of this mess: step one…”
I join a few support groups for early stage CTOs, but it’s mostly the blind leading the blind. At least I feel like we’re in this together, commiserating about our problems. Someone has to fire someone. Someone is having a fight with their cofounder. Someone needs to quit the job, they’re clearly way too miserable for this to be worth it, but they won’t give up, torching everything in their life. Someone is on their 5th pivot and is about to lose their marbles. These are stories you end up seeing again and again in startup land if you stick around long enough.
I finally manage to duct-tape together a small resource buffet. I stumble upon the CTO Summit series of events (nowadays known as CTO Connection), organized in San Francisco for technical leaders of companies of all sizes. I’m the smallest of fries, but at least I get to listen in on others discussing problems that I will soon face myself. I start meeting other people who have made it past the escape velocity of pre-Seed and Seed Round PMF-chasing. They reached the stage where they are now building organizations and figuring out how to run winning teams. They are exactly where I aspire to be.
I eventually find a mentor, Bill Crane of LinkedIn fame through a happy accident. A one-sentence referral from a total stranger on YCombinator’s internal boards, recommending him for anyone who needed help with coaching their company’s technical leader. I manage to catch him right in between interim roles, he’s stoked to sherpa someone just starting out. Here is someone for whom management and process problems that sounded catastrophic to me are just a Tuesday at the office. Bill is practical and pragmatic; skilled at seeing the big picture, but also aware of every tactic under the sun and when to apply it. Focused less on “how does this make you feel” and more on “ how could you make this problem go away, today?” My kind of guy.
Once we hire our first serious Head of Engineering, Rafik Robeal, I end up relying on Bill a lot less; we now have an “adult in the room” who has done the serious engineering management work before. I transfer all of those duties to him, and as a bonus perk, I get to spend years watching him do his magic. He transforms the team from an ad-hoc, reactive improvisation of a first-time CTO into a well-oiled machine orchestrated by a pro. There’s clarity of purpose, consistency to the process, regular feedback cycles and tasteful delegation that make it all anti-fragile. The guy practically puts himself out of a job in a couple of years, proceeds to read books about famous chess matches at his desk. Nobody makes a peep. The trains are running and the team is ecstatic; he’s earned the right to do whatever he wants. It’s an absolute delight and I get to learn how it’s all done from the front row. Chef kiss.
It’s 2024 when I start my second VC-backed company a few years after selling and leaving Freckle. This time Andreessen Horowitz’s new Speedrun incubator is our lead investor, one of the few options out there if you want to take on VC and build a high-growth game studio. A provocative proposition, and history will tell how well that business model stands the test of time, both for investors and founders. Regardless, I get the appreciation of how much easier the job gets the second time around. It’s my first foray back in the games industry in 17 years, I’m effectively starting from scratch, but many things are exactly the same. It’s back to the familiar early stage grind, hiring, managing processes, culture, best practices, architecture, cross-disciplinary coordination. It is now all second nature. What felt completely alien in 2012 is now just another Tuesday. What once felt like guesswork is now just common sense. The climb up the competence ladder is real.
Choose your own adventure
The CTO is one of those hard-to-pin-down roles in the startup world. Ask a dozen developers what a CTO does, and you’ll get a dozen different answers. When you zoom out, it’s not hard to see why.
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 whose ideas, insights and ability to execute them the company bet the farm on. Sometimes you’re an amazing technical people leader, who spends little time thinking about the tech, because you have a trusted lieutenant to do 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.
Your specific industry influences your role and responsibilities as CTO, too. Running technology at a robotics startup, a game studio, an AI lab or a web dev shop slinging CRUD GPT-wrappers all will require something different from you.
And just to muddy the waters a little more, a CTO’s day-to-day responsibilities vary wildly depending on the stage of the company. At the beginning you’re implementing everything yourself, you then grow and manage progressively more people to do it on your behalf, and one distant day you oversee a complex human network that does that, and much more, under your guidance. At first you are the machine, then you grow the machine, and then you teach the machine to make a bigger machine without you.
No matter what, you’re ultimately responsible for the technical decisions, which means you’re responsible for the success or failure of the research and development side of the company, too. The proverbial buck stops at you, and if it passes you and ends up on the CEO’s desk, you are going to have a bad day. I aspire to have the technology side of the company be an abstracted black box for the CEO; they don’t need to know about how the sausage is made, unless they choose to: the trains are running on time and the metrics are hit, the departments have what they need to move at full speed. People are sticking around and are stoked to get to work every day. It’s one less thing for the CEO to worry about, at least in companies where the tech is enabling the product, and isn’t the product itself—think dev tools.
Hired vs grown
The two most common paths for a CTO to land a gig at a “traditional” Silicon Valley-style VC-backed startup:
- Co-found it as the technical counterpart to the business-focused co-founder
- Join it (usually at a slightly later stage, around series A or after) once the company has some proof of product-market fit and is seeking a technical leader to take them from that early prototype stage to its full potential
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. A hired CTO will always be more mercenary; their professional future isn’t resting on this one singular bet of which they own half the cap table. They can leave anytime and get another gig. As the co-founder though, not so much, the captain goes down with the ship. How they perform in either situation should not change much, but one’s motivation and commitment to stick around for the business and make it work at all costs will be decently influenced by that equity allocation.
Additionally, the technical co-founder has to adapt as the role evolves, starting when they’re the first and only technical contributor. The hired CTO typically arrives later, when more management is required. First-time technical co-founders are typically more green and need a lot more support to find their footing in the role. Professional CTOs hired into this position, on the other hand will have solid pre-existing experience; This isn’t their first rodeo. The point of hiring them is that they’ll lead the way, not demand instant hand-holding and coaching.
When do you actually need a hired 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. In that case the company gets a technical workhorse for free, doing the job of several otherwise normally-compensated developers, which is a good deal for the startup. CRUD apps, GPT-wrappers and other projects innovating more on workflows and distribution than on technology can get away with less technical expertise at first.
Most early stage CEOs would be happy with a product-minded founding engineer (effectively a lead engineer of one) who can take the company from a prototype to a working product they’ll iterate on with their team. You can, of course, bring in an experienced startup CTO 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 risky; commit this cardinal startup sin at your own peril.
If a company doesn’t start with a core technical contributor to grow alongside the firm, then it will benefit more from a founding engineer. There’s less of a fit for a professional technical leader who’s going to turn off most of their skillset for a few years and live inside of vim. Or Claude Code, who am I to judge? The full package—someone to code, lead, hire, manage and beyond—is too expensive, and frankly overkill, for most startups and will need to come in co-founder form, not as a hired gun. Coincidentally, having anybody non-technical on the founding team is becoming rare according to the more recent trends of YC batches, which you can use as a proxy for the rest of the tech startup industry.
The team will benefit the most from a hard working and relentless donkey, not a unicorn. Usually in the form of a founding engineer, unless the founders are celebrities in the technology world and are able to attract a high-end CTO from day 1 with a sizable compensation and a higher guarantee of their equity being worth something. A rare opportunity on both sides of the table. For most 19-year-old Stanford dropouts with a SAFE from hot incubator du jour, or whatever the median trendy founder profile at the time of you reading this, that’s not on the menu.
If you’re considering joining an early stage startup as a hired CTO, the best time to come on board is when the company has about five to ten engineers and is demonstrating that growth will continue. Growth fixes (almost) everything. You get to flex most of your muscles, you avoid spending years in full-time IC-land, should the business never hit PMF. Unless that’s what you find motivating, in which case, don’t let me yuck your yum.
Of course, you can join later, but the earlier you come on board, the less likely you are to encounter a dysfunctional culture you have to deprogram from the time when the inmates were running the asylum. Fewer people to let go of who should have never been on board to begin with, but management didn’t know any better. There’s no right or wrong answer here, just trade-offs.
Stages of a CTO
The only constant of the role is constant flux, and the faster your company grows, the more you have to change. The more flexible you are about your specialization, your identity, and your ability to meet the company’s changing needs, the smoother the ride. The only limits to your success in this role are your own personal interest in new responsibilities, capacity to learn a new job quickly, and willingness to let go once it’s time to pass someone else the torch.
While no two CTO’s trajectories are exactly the same, for the most part, you can expect to go through certain predictable stages as your company grows. Klaas Ardinois’s framework does a great job of outlining the evolution of a startup CTO’s role. I add a few twists of my own on top of it, based on first-hand experience.
Stage 1: The Workhorse CTO Stage
You roll up your sleeves and get 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; the only thing that matters is finding a unique insight in the idea maze before you run out of money, morale, or both.
Your initial assumptions about what customers want and how to deliver it to them will likely not work, but schlepping through validation cycles should eventually land you somewhere actually valuable. It’s unlikely you’ll nail the fit perfectly at the pre-seed stage of your company, assuming you’re raising VC. You’ll push to validate that the customer pain is real, raise another round to actually solve it, and eventually figure out how to do it at scale and at a profit.
If you can afford it, you may have a few engineers working with you. Even with a small team, you’ll do most of the work, planting the seeds of culture, workflows, and company strategy that you’ll nurture over many years to come, assuming you find a problem that will sustain the business.
I agree with Dylan Field that the progress of AI-enhanced tools will enable talented people to do far more with less. This is just more automation-enabled augmentation at play, the same as ever, only even faster. With the right tools a CTO can wear many hats, including product manager, designer, programmer, QA tester and more. Throw a few hard-working and self-motivated generalists onto the team and you can shred through iterations faster than ever before, while keeping the scale—and the associated communication costs —under better control than was possible even five years ago. 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, you can go farther and for longer with a tiny team than ever before, and you should take full advantage of this unique opportunity.
The good news is, you can make plenty of mistakes at this stage without major long-term consequences—as long as you successfully hone in on your customers’ pain point. Your “good enough” workflows, codebase, tooling choice, and maybe even team are good enough for now. They’ll naturally evolve as the company grows, so don’t worry about making them perfect right now. You’re at the messy experimentation stage, and it’s better to find PMF through a little chaos than to run out of funding with the perfect process. It’s a good idea to establish a basic foundation while you’re here, but no need to overdo it. The earlier you establish a culture that values getting things done, simplicity, feedback, and openness, the less you’ll have to undo in future stages. But ultimately all of the branch prediction at this stage will go to waste if you don’t make something people want.
Whatever values you choose to prioritize at this stage, your hires should already demonstrate them on day one. There’s not enough runway to sculpt raw putty. And while you might be strapped for cash, you won’t regret hiring the best-fitting people you can afford, as it will be difficult to attract even better hires down the line if all your staff is “okay-at-best”. Unfortunately that’s not effortless. It requires that you yourself are able to stand out among a crowd of startups all clamoring for founding engineers. And you must learn how to discover talented oddballs that everybody else has passed over. More on this in another post.
Stage 2: The Hybrid Manager CTO Stage
The company has raised enough funds to hire an engineering team or two to do most of the work. The CTO still contributes here and there to stay close to the work, but now, with more than 10 direct reports, your role has shifted dramatically. Your bandwidth to make much of a difference as an individual contributor will be severely limited unless you have an independent, self-driven team and a tech lead or two to help pre-empt requests that would have otherwise bubbled up to you.
Chances are, you’re still the architect, and a backseat contributor, 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 approach the decision point where you have to choose which long-term path to take.
The hiring and cultural choices you make become even more important at this point. As your growing team begins to solidify around the behaviors you reward, changing course is like stopping a train; sure, it’s possible, but the bigger you are and the faster you’re moving, the harder it becomes.
If you’ve created a relaxed culture of work-life-balance, generally a bad move for a pre-revenue VC-backed play that’s always a year away from hitting zero runway, a cultural overhaul is mostly out of question, short of firing everybody. The environment will not suddenly transform into a Muskian sleep-under-your-desk factory no matter what you do. By now everybody you’ve hired has bought into a particular social contract you’ve 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.
Not that the transformation is likely anyway: companies are ultimately reflections of the founders’ essence. If you started a company with the natural habit of being harmonious and cuddly at all costs, becoming ultra-hardcore overnight would ultimately be inauthentic and fail as you regress to your habitual wiring.
As you scale here, unless you have the right senior people on board already to help you spread the load, or you abandon trying to do any hands-on work, this stage will suck. Sooner or later you’ll need to make a decision.
Stage 3: The Fork in the Road
Next up comes the Fork in the Road, where the CTO typically chooses a specialization as the team scales. They 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. The dedicated post covers that pivotal moment in depth.
Stage 4: Real scale and more
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. CTOs at companies as large as Microsoft, Amazon, and Meta spend most of their day doing evangelism, technical strategy, and executive-level management. 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 first-hand expertise.
What separates the good CTOs from the mid CTOs?
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 traits they often have in common, at least in the early-to-mid stages of a startup.
A generalist able to specialize 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 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, and you don’t expect to become a deep domain expert at most of what you touch. You know how to identify a great expert who can pick up the baton and go much deeper than you ever will. You can help them determine how they leverage their skills to be most helpful to the business. At the same time, you know where to cut your losses and where to double down on your efforts and push the team to deliver something better than they thought they could. You’re able to drop in, pick up any area of the codebase, given enough time. You can understand the workflows and the local customs, so you can contribute effectively, advise, 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.
An eye for non-obvious talent
A great early-stage CTO is able to identify talent others missed. Many phenomenal hires lack the aesthetics and the eye-popping credentials that less experienced tech leaders will use as indicators of greatness. The CTO identifies the market inefficiency and jumps on the opportunity to recruit undiscovered talent 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.
Anyone can identify a PhD from MIT with a maniacal work ethic and a stint as a founding engineer at Cursor. The problem is, as a startup, you probably can’t—and likely shouldn’t—afford this type of candidate. A stellar CTO’s superpower is finding the wacky undiscovered geniuses the company can afford.
While this is a make-or-break skill, the fact is, it’s very hard to pull off. Of course, a serious personal brand name and a reputation in the technology community might bypass the need for any of this, but that will be out of reach for most first-timers. For the not-yet-celebrity-CTOs it’s a good idea to build a network of talented product professionals, including designers, programmers, product managers, and scientists etc. This way, while your company grows, you can tap into a pool of great people ready to join your cause with someone they already know.
A people-person
A great startup CTO must be excellent at the squishy 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. Irrespective of direction, be that gnarly technical projects, management, sales, or evangelism, everything the CTO accomplishes hinges on successful collaborations. The lone wolf genius coder in a cave is a myth in a cross-disciplinary team sport like technology. The technology is ultimately just the flavor on top of a dish made almost entirely of human relationships. Or “every problem is a people problem,” as the saying goes.
A great startup CTO communicates technology to every other discipline. They go out of their way to understand other specializations’ challenges and suggest the right tools to enhance each team’s effectiveness. Instead of getting caught up in the minutiae, they take a birds-eye view, looking at the future of tech, how their industry fits into that ever changing landscape, and what the competition is doing. They respond to the changing tides before they get swept up in the current, rather than reacting after the fact.
Wrapping up
The CTO role is weird in the best way. It’s endlessly interesting, full of ways to stretch yourself, and broad enough that you can steer it toward whatever keeps you curious. If what you want to learn happens to line up with what the company needs, it basically turns into a choose-your-own-adventure with a salary.
There’s always too much to do and never enough time to do it. The tech stacks never stops shifting. Management “best practices” reinvent themselves every couple of years. New frontiers pop up just when you are getting comfortable. The job is basically permanent adaptation.
And yeah, sometimes you get stuck owning something you don’t actually care about. Ops cleanup. Compliance swamps. Technical due diligence at the next fundraise. Some cross-functional initiative that feels like homework. But if you treat those detours as a chance to train muscles you’ve been ignoring, they stop feeling like distractions. Those odd corners of the job end up teaching you things you didn’t know you’d enjoy. Sometimes they’re the parts that quietly make you better, bits you’ll learn to appreciate years later, from a different perspective.
What’s there not to like?