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?
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.