“My technical co-founder just quit,” she says, “and he took all of the product code with him. Now I have to negotiate to get my product back.”
“I had to fire my CTO last week,” he says, swirling the coffee in his mug and looking around the coffee shop. “The entire engineering team quit within a few days, so now I’m just hoping nothing breaks before I can hire some people to review the code and learn how it all works.”
I hear stories like this all the time from the startups that I work with and from other startup mentors. Companies who are just starting to get traction are suddenly paralyzed by a loss of technical leadership and lose precious time, money, and reputation strength as they rebuild. The cause: hiring a CTO too early.
Every software company needs technical leadership, and it can seem especially critical in the early stages, but do you need a CTO right out of the gate? Tradition (and perhaps investors) would say so, but experience says otherwise. I couldn’t find statistics on this anywhere, which is a telling fact all by itself, but anecdotally I can say that a majority of successful startups got through two or more CTOs in their first five years of existence (otherwise known as The Investor Financial Model Horizon). Why is this, and what should you do about it?
What does a CTO do?
The CTO is the technology leader for a company. For most companies, this means that he owns all technology, not just the client-facing parts, so this includes corporate IT, infrastructure and hosting, and networking. The CTO makes sure that the product gets built, the servers stay up, and the CEO can get her email.
Being CTO means more than being the lead engineer for a company: it means that you’re the lead technologist and technology strategist.
At a higher level, the CTO’s job is to apply technology to provide competitive advantage for his business. This requires a broad understanding of both business and technology, as well as the ability to effectively apply technological solutions to business problems. Being CTO means more than being the lead engineer for a company: it means that you’re the lead technologist and technology strategist. This is where many CTOs fall short, and where startups get into trouble as they grow, and this is why you may not need a CTO as soon as you think you do.
Why startups change CTOs
To be clear here, we’re looking at changes initiated by the company, not by the CTO. People move on, they find better opportunities, they get bored. This is part of life in the technology industry, and other than making sure that you’re creating a dynamic, fun workplace, there isn’t much you can do about that. What I want to look at is the breakups, the “It’s not you, it’s me. No, actually, it’s really you” moments. Most of the time, startups break up with their CTOs for one of three reasons:
- Personality conflicts within the leadership team
- Poor performance
- The company outgrew the CTO
I’ll look at all three of these, their root causes, and what you, the new entrepreneur, can do about them.
You see them at every tech meetup: smart business people with big ideas, hunting for a technical co-founder. They walk from one nerdy target to another, sharing the same pitch over and over. “I have a great idea but no way to build it. Will you build it for me? I’ll give you equity! Please be my tech co-founder!”
Every business person thinks that they have to have a technical co-founder, but what they really want is an engineer, and often any old engineer will do. When they cruise the meetups or post on the local message boards or Slack channels, what they’re really asking is, “Are you willing to work for equity on an idea that isn’t yours?” Astonishingly, some people actually say yes to this proposal, but it’s rare that it’s a successful pairing.
Founding a company together isn’t just a transaction; it’s a commitment. If this is a full-time startup, then you’re committing to spending more waking hours with your co-founder than with your family, your dog, and your favorite Netflix series combined. If it’s a part-time startup, then you’re still going to spend hours every week online and in person solving problems, making plans, and hashing out product decisions. Would you marry someone you’d just met at a tech meetup? Then why would you decide to start a company with them?
Would you marry someone you’d just met at a tech meetup? Then why would you decide to start a company with them?
And yet, people do. The lure of free development work is strong, so rather than hiring an engineer or a development company to build the first prototype, business people decide that speed-dating engineers is the best approach for their new company. Unsurprisingly, personality fit often takes a back seat to technical competence in this process, leaving a company with a CTO whose only qualifications for the job are that he knows Python and was willing to work for free. As the company grows and the demands of the role increase, the cracks in the relationship start to appear. Soon, the CEO is saying, “Maybe it’s time we saw other people, because right now I want to punch you right in your beard.”
If you find yourself looking for a technical co-founder, treat this like the most important relationship in your life, because after your marriage, it is, at least for the next few years. Date around first. Look for personality fit, common goals, and a common outlook on life before you start asking about technology stacks. Simply by virtue of being the first employees, you will define your company’s culture through your interactions. They must be healthy. The most successful early-stage CEO/CTO partnerships that I’ve seen were built on years of friendship before ever deciding to build a company together. You need this foundation if you want the relationship to last.
Great engineers don’t always make great leaders. In fact, I’d argue that most great engineers struggle to make the transition from “smartest person in the room” to “leader of a roomful of smart people.” The skills that we value in a great engineer — strong problem-solving, deep knowledge of multiple technologies, the ability to craft elegant solutions — are very different from the skills required of a good leader. And as any engineer will tell you, engineers are some of the hardest people to manage, making it even harder to bridge the gap from individual contributor to team-builder.
If you have a great engineer on your team, don’t ruin his life by making him a CTO.
I’ve seen many great engineers become nightmarish technical leaders — in some cases taking their companies down with them — simply because didn’t understand the job or lacked the skills to do it well. The very thing that makes people the best individual contributors — pride in what they’re able to accomplish on their own — makes them the worst leaders, because they’re incapable of letting anyone do things differently than they would have done it. They have to learn to take pride in what their team accomplishes — the work they do through many hands instead of just their own — if they’re going to succeed. Many people can’t make that transition.
Engineers, in particular, also struggle with the fact that people are messy. When you’ve built your career on being logical and building complex structures that work perfectly every time, it can be frustrating dealing with people whose moods change every day, who don’t always say what they want, and who get annoyed when you rewrite their code for them. A CTO who doesn’t appreciate the people side of the job will only grow angrier as the company grows, driving away the best team members through his own bad behavior.
In these situations, the best outcome would be to move your leader back into an individual contributor role that plays to his strengths. Unfortunately, if that person is already the CTO, then any move looks like a demotion and the only viable option is often to replace him.
The best way to avoid this problem is to avoid creating it in the first place. If you have a great engineer on your team, don’t ruin his life by making him a CTO. Let him be the development lead, architect, or Chief Scientist. Let him apply his technical prowess to the company’s benefit without getting tangled up in the messiness of people management. If your leader wants the CTO title, then make it clear that hands-on development work will diminish rapidly as the company grows and confirm that this is where he wants to go with his career. If you’re clear in your expectations, then at least no one will be surprised if you have to have the difficult conversation later.
Outgrowing your CTO
Every software startup needs “the technical guy.” When you sit down with potential investors, this is often the first question they’ll ask, “Which one of you is the businessperson, and which one is the techie?” This is because, practically speaking, someone needs to build the product. But does this person need to be the CTO?
Before they even have a business, most startup teams sit down and hand out titles:
“I had the idea and I’ll be the face of the company, so I’m the CEO. Jan is the sales specialist so she’ll be our CMO. What, Jan? They call it Chief Revenue Officer now? Fine, you’re the CRO. Todd, you’re the programmer, so from now on you’re our CTO. Try to let me do most of the talking. OK, let’s go build a unicorn!”
The problem with this, similar to the speed-dating scenario above, is that Todd’s primary qualification for being CTO is that he was the first one on the team who knew how to code. Todd may be a brilliant engineer, but is he able to build a team? Can he run the technology side of a business? Does he have the faintest inkling of what the product strategy should be, or is he just a good typist?
As a company grows, writing code quickly becomes the least of the CTO’s responsibilities. In fact, if your engineering team is larger than ten people and your CTO is still writing code, you have some serious prioritization problems. Some CTOs are prepared for this change and even welcome it as the next step in their career evolution. Many, though, look at these company-building activities as a distraction from their “real job” of writing code. They either ignore the bigger responsibilities, leaving the rest of the leadership team to pick up the slack, or they do them poorly.
If your engineering team is larger than ten people and your CTO is still writing code, you have some serious prioritization problems
There are two ways to avoid this trap:
Make your CTO replaceable. Many founding teams include “the First Techie,” someone who knows how to build the MVP and convince investors that you know what you’re doing. This person may want their role to grow as the company grows, but they may also want to just keep building cool stuff. If possible, try to discuss this in the early days of your company’s existence, and if your tech leader wants to stay close to the code, have a plan for him to replace himself as soon as it makes sense. Laying this out from the beginning avoids hurt feelings or painful changes down the road, and enables your tech leader to manage expectations with a development team that could otherwise turn mutinous if they think their leader is being disrespected.
Startups that address the changing leadership needs early can create a special role for their founding techie, being with a Chief Scientist or Product Architect title as soon as the company grows to the point that it needs a true CTO.