CTO/Founder
What’s my job again?
The job of a CTO is ill-understood in the general case, and moreso in the case of startups. Even at big companies, the title covers a gamut of distinct roles. Some CTOs head up software teams, some are corporate executives several layers removed, some are project managers of technical staffs, some run IT, and some are researchers.
The problem is worse in startups. In addition to the role depending heavily on the kind of company you’re building, it’s a shifting set of responsibilities that seems constantly in flux as you’re growing.
But for now, let’s just discuss what’s become a common case as software “eats the world,” the CTO of a company that primarily builds a software product. This is what my company, GameChanger, does, and so I can at least talk about what I’ve experienced, and lay out a few key stages.
Stage 1: Headphoned Hacker
Here’s some free advice for brand new companies: your CTO had better have her headphones on. The fate of the company lies squarely in shipping your software. There’s little room for ego or ambition beyond the product: it is wholly and completely and exhaustively your responsibility to build your thing and get it to your users.
Above all you’ll need a good co-founder or CEO who can deal with money, investors, and sales so that you can focus on your craft.
Stage 2: Overworked Technical Lead
Probably the hardest single stage of startup CTO ontogenisis, this one begins as you hire your 2nd or 3rd engineer. It feels as if you’re on the cusp of being freed from 24h coding responsibilities, but actually you’re more critical than ever. You now have two jobs: to manage a team, and to write just as much code as you did before. You’re still going to be the person who knows more than anyone else about the business case, the code base, and the goals. Because of these advantages, you’re hopefully still single-handedly as productive as the entire remainder of your team. Taking your hand off the tech at this point is disastrous- it’s filled with trap doors, jury rigs, and half-baked ideas that you need to fix and communicate about.
Stage 3: Firefighter
So you’re lucky enough to have built up a team of 5-6 people; maybe you even have them split into two small teams. You’re still building things, but the team is taking on more responsibility and it’s getting harder for you to move mountains by yourself. You spend your time giving direction, flitting about between projects (growth hacks, bug fixes, production catastrophes, sexy new features), chipping in wherever you’re needed and mentoring your team, while letting them take the lead most of the time.
Getting to Stage 3 is entirely a challenge in hiring people. I remember struggling mightily on the way here, with regular crises of faith in our ridiculously high hiring standards. On a number of occasions, we looked around and asked ourselves if we couldn’t hire even just one “ordinary” developer, just to get another pair of hands. My advice would be: never ever compromise on talent, no matter how slow that makes you. You won’t get to Stage 4 if your team isn’t amazing.
Stage 4: Historian and Architect
Congratulations, you can probably actually call yourself management at this point! (I hope you were looking forward to it.) You’ve got 10 or so people working for you in multiple teams, and they’re threatening to revoke your git access because when you leap to the rescue you mess up their carefully laid plans and they have to clean up after your messes. Your job now becomes explaining where all the bad code came from, what the whole system is aspiring to be, and what the big technical goals are. You probably now talk more than you code, but you’re still mostly consumed with technical problems.
I could write a whole post on hiring (and grooming) good leaders, and another on delegation, but these are the keys to making it out of the firefighting role and into the first tier of strategic management. Firstly, if you didn’t compromise on people on your way to Stage 3, then hopefully you’ve stumbled on a trustworthy leader or two along the way, and they’re naturally growing into the role. If not, you might be screwed. Other people need to be taking various burdens off of your shoulders at this point: advocating for high quality standards, setting a tone of technical rigor, or driving operational discipline, to name a few. Only once you aren’t directly responsible for any specific facet of competency in your organization will you be able to step back and lead. It’s also worth thinking through which ones you care about, and how and when to delegate their stewardship.
Stage 5: Evangelist and Product Leader
As the team grows beyond a couple of small groups, things get very complicated. Role specialization kicks in: gone are the days of the designer/developer/sysadmin generalist, and here are the days of dedicated architects, distinct UX and visual designers, devops hackers, and managers. Your job is figuring out how design, engineering, QA, and customer service interact with each other, and how each is internally structured. You have to find ways to communicate goals to groups of disparately trained and motivated people, and rally them around causes.
Above all, the CTO is the ultimate problem solver in a tech company. You’re the person people turn to when they need to solve something, build something, change something. Any preconception you have of what that means, you should check at the door. At every turn, I’ve looked around and asked myself what the organization needed, and I tried my best to be the solution.
While I’d like to say I’ve reached CTO nirvana, honestly, we’re probably somewhere in between stages 4 and 5 right now, and I’m still working my ass off. And having the time of my life.
It’s a good gig.
