Do You Really Want to Be CTO?

"If you could just build the product, hire the team, and prepare an investor presentation by Monday, that'd be great...."

You finally did it: after years of building software for someone else, you took the leap and joined a startup. Now you’re building software for yourself. All the risk (and a 30% stake in the rewards) is yours. Then comes the day when your co-founders ask that fateful question: “What title do you want?”

You’ll be tempted, my friend, to reach for that brass ring, to claim the right of First Techie, to confidently say, “Why, CTO, of course!”

Hold on there, Tiger.

Sure, it looks great on a business card and your mom will be impressed, just as soon as you explain to her, for the hundredth time, what you do. And it will be nice to go to the next tech meetup and tell strangers that you’re the CTO for that tech company that they haven’t heard of (yet). And for a while those will be the only changes. But wait, there’s more.

Do you like meetings? Because you’re going to be attending a lot of them (and even hosting a few yourself!). Investor meetings, strategy meetings, planning sessions, interviews – your day is going to be chock-full of talking, so go buy a notebook and prepare to sit there pretending to take notes just like all the other senior leaders.  You can try to get out of them by being cranky every time someone wants to talk to you or by claiming to be too busy writing code – and I'm sure that’s what you’d rather be doing – but it won’t work. You’re in charge of a whole chunk of the company now, so get ready to represent.

I’m sure that you love problem-solving – you wouldn’t have gone into engineering if you didn't – but how do you feel about people problems? You don’t have to worry about that too much when the development team is you and maybe one other person, but what about after that Series A round? You’re in charge now, so you get to build a team! Interviews, coding tests, career discussions, mediating personal disputes… Remember looking at your Director of Engineering at your old workplace and thinking, “I am so glad that I don’t have her job”? Guess what, now you do, plus your own!

As CTO, you’re in charge of the whole thing: people, processes, and technology! And while code might be complex, at least it’s consistent: the same command will behave the same way today and tomorrow as is did yesterday. People, on the other hand, are messy. They have moods, frustrations, and personal lives that impact how they feel when they come to work. Your best engineer today could be a hot mess tomorrow, and it’s your job to straighten them out. Forget about writing code: you’re a bio-hacker now.

Some people like this kind of thing. They even see it as the next challenge in their careers, an opportunity to step up from “just an engineer” to “an engineering leader.” They don’t mind getting messy and maybe even get excited about measuring their output in terms of the work they do through others rather than what they deliver on their own. They’re ready to stop building code and start building companies. Others, though, fall for the title and look back a year later thinking, “Dear God, what have I done?” They self-destruct.

Are you longing yet for those quiet days where you could just put on your headphones and code? It’s not too late to avoid this trap. This time, when your co-founders come around handing out titles, look at them calmly and say:

“How about Chief Scientist?”

Wanted: Someone to Make My Life Easier

Wanted: Someone to Make My Life Easier

The job posting reads:

Hands-on Director/VP of Engineering
Looking for someone to build the engineering team for our fast-growing startup. Must be able to hire and inspire a high-performing development team, build the organization, and define new processes to support a larger team and a more complex product. Must be hands-on with our chosen technology stack and able to code at least 20% of the time. Should be able to grow as we grow, taking on more leadership while remaining a technical leader. Email CTO@mystartup.com with your resume and Github address.

It’s one of many that I see in the Denver area as overwhelmed CTOs try to clone themselves to support their company’s growth. With limited budgets and unlimited demands on their time, these leaders look for a “twofer” hire: someone who can lead the engineering organization without taking a seat away from a working developer.

At lunch with some local CTOs, though, the conversation around the table tells a different story:

“It feels like I’m spending all of my time interviewing when I should be coding,” says the CTO of a predictive analytics company, shaking her head. “I know that getting new people in the door will help in the long run, but my team is bottlenecked now. And the newbies have to be set up with new equipment, trained, and brought up to speed on our product. How do you manage people and write code at the same time?”

Another CTO chimes in. “I never got the chance to figure that out, because we never grew. When I joined my company, I expected that I’d get the chance to build my management skills and move away from the code, but I still only have two developers besides me after three years. The CEO keeps saying that new funding is just around the corner, but I can’t wait any longer. I took a 40% salary cut to co-found a startup, but that just doesn’t make sense anymore.”

The third CTO just nods. His consumer marketing company shut its doors a few weeks ago, so he’s just figuring out what he wants to do next. I doubt it will be another early-stage startup, though.

---

There’s a myth in our industry that you can write code and manage people, and that every engineer should do both if they want to advance their career. While I know people who are good at both, they’re generally the rare kinds of people who can hold two opposing concepts in their minds at the same time. And they never get to straddle those two areas for long; they either become a senior people leader or a senior technologist.

Code and people sit on opposite ends of the attention spectrum. Coding requires focus and precision, while people create interruptions. Code is logical, people frequently aren’t. Technology is an ever-expanding set of tools and options that requires time and energy if you want to stay current. A growing team requires the same levels of time and energy if you want them to stay productive.

Until we come up with a way to stop time, every technology leader will have one foot in two boats, and the faster their organization grows the more rapidly those boats will separate. Eventually, each leader must choose where their attention goes: will it go to their people or to their technology?

(Photo credit: David Constantine)

As a result, any leader who can effectively grow an engineering organization and code is already a person in transition: they’ve built up enough technical skills to lead other engineers, but they’ve begun to move away from the code and toward the people side of the spectrum and they’ve decided that they like it. When you apply these filters to an already insufficient population of software engineers and add in the risk tolerance required to forgo the big salary and stability of a larger company to join a startup, the intersection becomes vanishingly small.

Startups who enter this tiny battleground are at a distinct disadvantage relative to their larger competitors, whose size both requires more managers to prop up their structure and enables them to pay large salaries to get them. If an engineer can code and manage people, then the logical choice is to take the large salary and the greater career opportunities — not to mention the free food and, well, everything else — at Google. And if someone has those skills but wants to go the startup route? Well, she’s likely to end up as a co-founder. Some startups do get lucky in this environment, but far too many end up paying too much in cash and equity for someone who isn’t ready for the job.

So why do companies keep playing this low-odds, high-stakes game? I don’t think they realize that they have a choice. Most founding CTOs — and many CEOs — started as engineers. They learned how to manage people, or at least deal with them effectively, in order to start a company. Now, when the time comes to hire, they go with what worked. They think, “I built the first version of the product and talked to investors and told one or two other engineers what to do, so that’s what success looks like in this role.” They try to clone themselves.

The problem with cloning, though, is that it breeds weakness into a population. Variety provides strength, and complementary skills build a great organization.

Recently, a CTO friend told me, “I’m wearing 5 different hats now. I need someone who can take at least two.” We talk a lot about the number of hats that a startup CxO has to wear, but in this case I prefer the metaphor of spinning plates. The startup CTO has to cover at least 5 different areas in order to keep their product moving forward:

• Product ownership
• Software development and technical leadership
• Quality assurance
• Development processes and controls
• Growing the team and people’s careers

All these plates must stay up to keep the company growing and the product selling, and any extended period of neglect in one of these areas is met with the sound of crashing china.

So how about getting some help?

Instead of fighting it out with other startups and tech behemoths on a tiny battleground, how about exploring new territory? Instead of searching for that purple unicorn developer who loves code, people, and low pay all at once, how about searching at the other intersections?

What if my CTO friend found a great engineering leader who loved people and process? Could she hand those things off and keep doing some of the development for a while? Practically speaking, most founding engineers are reluctant to let go of the code for a long time anyway, maybe it’s better to wait a little longer find the right technical leader without burdening them with the people problems. What if she found a great product leader who could also manage a development team? In my experience, those two skillsets have a much higher level of overlap than a hands-on developer and skilled people manager, so why not play better odds?

When you look beyond the specifics of software engineering to the larger problem of growing a company, your options multiply and your odds of success increase dramatically.

So what’s your goal for your next hire? Are you trying to clone your skills or complement them? Do you want to cover more ground or go deeper in one area of the company? Do you want to fight it out with other companies on the traditional battlegrounds or are you willing to discover new territory? How long can you wait and how much do you want to pay?

Next time you want to grow your leadership team, allow me to propose a new job posting:

Wanted: skilled plate-spinner with demonstrated talent and ability to lead in at least two of the following areas:

- Living at the intersection of business and technology and defining how best to apply technology to solve wicked business problems (sometimes called product ownership).

- Designing and building elegant code in our chosen technology stack, with a passion for learning new technologies and applying them in new and interesting ways.

- Building tools and processes that keep production software running with high quality and minimal downtime.

- Designing and implementing the right processes and controls to keep a growing team running at peak efficiency even as it grows and the issues become more complex.

- Finding the best people, forming them into a high-performing team, and keeping them excited about their job and their prospects year after year.

Send resume and a description of how you’d make my life easier to CTO@mystartup.com. We can’t wait for you to help us grow.