Technical Titles: Are You a CTO or a VP of Engineering?

Posted on December 7th, 2020
Written by Evan Klein | Team Management

In the tech world, there’s a notion that has gained some traction in recent years: it’s that titles are meaningless, and what really matters is the job we do. While there’s a nice sentiment behind that mantra, I’ve seen it lead to confusion at the highest levels of organizations as it pertains to the division of responsibilities between different roles – and that, I would argue, really is important.

Two of the more oft-interchanged titles are CTO and VP of Engineering (VPE). The common knowledge floating around is that a CTO is the company’s technical visionary, while the VPE is more operational, focusing on executing and delivering software. In both roles, the first job is to be a leader, whether that means leading on what to build, how to work, what has value for the company, etc. But there are nuances to the differentiation between these roles and the functional areas they need to perform for the company at different stages. As you think about your strengths, which is a better fit for you?

What’s in a CTO?

In most companies, CTOs are indeed the company’s technical visionaries, and in many cases, they are founding members – fully invested in the vision of the product and how it will meet customers’ needs. But the responsibilities of the CTO do not end there. They should have a deep understanding of the market, competition, and tangential products in the space, and the latest developments in technologies that they can be used to build the next great solution. Their primary role is innovation, and often that is paired with thought leadership and evangelizing their vision both internally and externally. Thus, CTOs are not only responsible for the technical direction of the product, but also for understanding the direction and needs of the business and therefore setting priorities and fostering strategic alignment across engineering, product, and go-to-market teams.

Once a company grows to the size where they have both a CTO and VPE, the CTO is usually no longer responsible for leading teams of engineers and has handed that responsibility to the VPE. They may manage a smaller team of architects, tech leads, or engineering management, and while they usually have no or little direct line to development teams, they are often heavily influential on the culture of technical teams.

What about a VPE?

So who leads the sometimes large teams of engineers and engineering managers to actually build and deliver quality software? These are the responsibilities most often ascribed to Vice Presidents of Engineering. The job of a VPE is to make the engineering organization successful, and everything that comes with that goal. That means VPEs should be great managers, strategic builders of teams (and usually good at recruiting too), good communicators, and yes, good engineers themselves.

VPEs take the vision and business value and translate that into a technical roadmap. They must balance the constant struggle between speed and quality, working with their teams to optimize engineering processes, ensure they perform their best, fix anything getting in their way, hit their goals and KPIs, and ultimately deliver great software.

Why Size (and stage) Matters

As an early-stage startup and through initial rounds of funding, software companies usually have a CTO as one of the founders. That person performs all aforementioned functions for a time, but will eventually settle into one or the other role as the engineering team scales. Once the company enters ~stage two of its engineering team lifecycle (15-20 engineers), the ability to push the boundary on innovation and drive technical strategy, while simultaneously managing a growing team and scaling its operations to efficiently deliver code becomes untenable for most (but not all!) leaders. At that point, these responsibilities generally break down into two roles. Larger companies will often continue to divide the labor into roles with more narrow functional responsibilities as the depth of those responsibilities grows, to include roles like Chief Architect, Program Management, CIO, Technical Operations, and various levels and other flavors of Engineering Directors.

Where Do You See Yourself and Your Company’s Needs?

As you think about your strengths and aspirations, ask yourself where you see a better fit, and what is the best fit for your organization. And be careful, both when considering new roles and when hiring for roles in your own company. Many companies hire CTOs when they really need (or want) a VPE, and vice versa. But at the end of the day, I come back to: titles are meaningless. For those hiring technical leadership, define the gaps that are most urgently needed to fill. Make sure your leadership team collectively reviews, revises, and agrees on those responsibilities, and hire for those skills. For those rising to or seeking new leadership positions, don’t get wrapped up in the name of the role. Look for responsibilities that align with your strengths, and ask yourself what you really want to be doing.