\How technical should a CTO/VPE be? It’s a question you might think contains its own answer—aren’t Chief Technology Officers or Vice Presidents of Engineering…always technical?

You would be surprised how many CTOs/VPEs are good but not great technically. It's an oddity of the managerial class prevalent in many tech companies. Each stage of growth in the engineering team creates new management layers that abstract the person in charge away from the actual technical work. This creates selection pressure for leaders who can manage the managing, which often leads away from the most technically capable candidates.

Does that matter? Should a CTO be able to code up a storm in the face of a looming deadline? Be the 'Chief Architect' of the system? Does a VPE need to have brilliant technical insights? Or is it a mistake to overvalue exceptional technical skills in a role that is primarily about people management?

It’s not. Technical leaders at a company should be highly technical, for five primary reasons:

Exceptional technical ability is the only way for CTOs/VPEs to be true judges of quality—to know the difference between good and great (across hiring engineers, system design, etc.)
It allows them to make highly educated tradeoffs—between quality, speed, launch dates, feature inclusion etc. Making the right tradeoffs is one of the cornerstones of great leadership.
It enables them to command the respect of the entire team. It’s hard to take your leader seriously if you do not feel deep down that they could do your job if needed. That they could roll up their sleeves and fix the bug they are asking you to fix.
A somewhat more subtle reason: highly technical people very often have a deep passion for technology. They want to push the boundaries of what is possible.Those are the kind of people who are able to inspire teams to greatness. Passionate technical leaders bring a positive giddiness to otherwise mundane tasks. They don't just see technology as a means to an end—they are excited about the means. That’s the mark of a true visionary.
Finally, highly technical leaders have a much easier time attracting and recruiting other highly technical people. Great engineers don't want to work for someone who is just a great people manager. For all the above reasons, they want to work for a leader who matches their ability.

The War on Bugs

Here’s a concrete example of how deep technical ability supports an engineering leader’s role—specifically, as a general in the eternal War on Bugs.

Bugs in software are an eternal truth. There is no escape. The war can only ever be fought to a stalemate, a reprieve, but never victory. One of the key roles of your company’s engineering leadership is to balance working on new features (who doesn’t love that) versus maintaining quality and squashing bugs. Often this also means managing the competing demands of product and sales teams with very different incentives.

Let’s dig in to find out how to frame the above discussion.

You can't improve something unless you start measuring it. So step 1 in the sustainable battle plan against bugs is to start measuring how good quality is right now. But step 0 is actually to define what good looks like.

This requires answering a product question: “What are the top 2-3 things that users really care about from our app?” That’s the stuff that must always be working correctly and be high quality.

I’ll use some personal examples here: at Dropbox, this meant that your data could never be lost or get corrupted. Similarly, any inability to access your data was really bad. It would undermine the core value of the product. If Dropbox lost even one file, then it is game over in terms of trust. Everything else was important but secondary.

At Facebook, a key part of quality was ensuring lightning fast page/app loads across a large spectrum of geographies and internet speeds. If you can't browse through Facebook *quickly* you are going to lose interest and move on.

So now you have Step 0: a crisp and contextual definition of quality for your specific product.

Step 1 is to take this definition and start accurately measuring it. This doesn’t happen overnight. Yes, there are lots of good data tools out there. But in my experience, getting everything instrumented and set up properly can often take way longer than you think. There will likely be a couple of false starts (aka bad data). Don't get discouraged.

For anyone facing this issue right now, a concrete recommendation would be to do a weekly or monthly quality metrics review just to understand how things are trending. At this stage, all you are trying to do is to gain confidence in your metrics.

Once you cross the confidence chasm, then you can start setting up a Red Line that cannot be crossed in terms of quality. This is Step 2, and here we see how the technical abilities of engineering leadership are critical. The CTO/VPE needs a deep understanding of where the Red Line is, what the warning signs are that you’re approaching it, and, most importantly, what will be realistically required to move away from it.

CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality. This will cause friction—particularly with product leaders and CEOs. No one wants to see their favorite feature derailed/delayed. But this is the exact discipline that you need to enforce. And it is much easier to achieve that discipline when other leaders in the company trust the CTO’s technical assessment.

Here’s a specific example: as our engineering team at Dropbox grew and made more and more changes to the Dropbox desktop client codebase, we found that the number of bugs was growing quickly. The desktop client was the main way users accessed their files on our service. It couldn’t break. That was a Red Line.

The problem was the desktop client codebase wasn’t scaling with all the new engineers working on it. We were getting by, but a deep dive into the technical architecture revealed the Red Line was always much too close for comfort. It also made clear that rebuilding that architecture would make it much easier to fix bugs as they popped up, even as we continued to scale. But that change would take 6-9 months.

Imagine telling your CEO that you need that kind of time to make fundamental changes to the core product. Asking for all the delays that would accompany the technical rebuild. The whole company leadership needs to have a lot of trust in the engineering leadership pushing for that kind of change.

I’m a big believer in the importance of speed for startups. I cut my teeth as an engineer in Facebook’s move fast and break things era. But one of the CTO/VPE’s most critical roles is knowing when it’s necessary to first go slow to go fast. Technical ability gives engineering leadership both higher confidence for when that speed shift is needed and the moral authority to sell it to the rest of the company.

When we rebuilt the desktop client architecture, we made progress toward Step 3 in the War on Bugs: continually raising the bar for quality in every roadmap/OKR planning process. We moved the Red Line further away and made it possible to keep pushing it back over time.

The final step is to rejoice that you have a durable process that keeps your core products working.

The situation where I most often hear the value of technical ability in CTOs/VPEs questioned is when companies and founders ask about the hiring process for those roles. A shocking number underweight the coding interview.

So let me put it plainly: the CTO/VPE/Engineering Director candidate should pass your coding interview. In fact, they should excel.

Yes, you also need to vet their people management skills, their ability to work with founders and peers, and their recruiting ability. But they should fly through the coding interview and also a detailed system design question. It should be a make-or-break part of the evaluation.

Because, yes, your Chief Technology Officer should be technical.

Taking some time to figure out what to do next? Consider applying to SPC.

Your CTO Should Actually Be Technical