What does a VP of Engineering do?
I have been asked this question numerous times over the 6 or so years that I have been in a VP of Engineering role. When I was first new to this role, I struggled in articulating what it is that I truly do, let alone a VP of Engineering does. The job felt like a whirlwind of activities focused on “shipping product”, which made it relatively easy to list the various functions that the role does. The challenge was articulating those into a framework that truly captures what the role does. In time, perhaps stemming from experience, collaborating with peers and countless mistakes, I have come to a framework that describes what it is I do.
Before I dive into the framework, I’d like to offer a pithy statement that captures the essence of the role.
The role of the VP of Engineering is to build and maintain the system that develops the products and services a business requires
The framework that encompasses the various parts of this system, is one I call the 4Ps: people, process, product and potpourri. I will give a brief description of each part of this system. My descriptions will also cover various questions, or challenges, that each of the system’s part tries to “solve” or optimize.
People
One of the more critical responsibilities of a VP of Engineering is in building the engineering team. It’s fair to say that anywhere from 25-40% of my time is spent in recruiting activities. Team building doesn’t stop with recruiting, in fact that’s the starting point. The ultimate goal of the activities that fall under the people category is to ensure that the team is happy, motivated and growing. Growth here being a function of headcount as well as personal development. As such, a VPE will be focused on many people related activities some of which are outlined in the sections below.
Organizational design
This involves trying to define the manner in which individuals with the team are organized. Are individuals grouped into teams based on the functional area(s) of the product that they work on? Or are they organized as vertical squads? Yet another alternative is to have a hybrid approach, whereby some teams are functionally oriented whereas others are vertically oriented.
One critical aspect of organizational design arises in the early days of an engineering team’s lifetime: the addition of managers. It is not atypical for engineering teams at early stage startups to not have managers - everybody reports to the CTO/VPE. Transitioning from this modus operandi to one in which one or more managers are added can be destabilizing and alien to the team. That’s something a VPE can help the team navigate. Ultimately. the VPE needs to be thinking of how to evolve the organization to ensure that it can scale to meet the (hopefully growing) demands of the business.
Values & Culture
The VPE helps define and facilitate the emergence of the engineering team’s values and culture. These are the set of principles that acts as a north star for the organization. They are critical in decision making. Values can help with making hiring decisions, feature readiness, product quality, product design and more. This is a good read on product specific values and how they help with product related decision making. The same can be applied to decisions that impact a team or organization, the values are just at a higher level of abstraction.
Growth & Development
There are numerous activities that are concerned with the growth and development of the individuals in the engineering organization. These include setting up programs for hiring and interviewing process, onboarding new hires, compensation, promotions, mentoring,
Process
Broadly speaking, this is the software development life-cycle (SDLC). These are activities related to how software gets built and released out into the world. There are numerous process related questions that a VPE will grapple with. These include some of the below.
Goal setting and schedules
Will the team set quarterly goals, perhaps using OKRs? How are these goals aligned to the rest of the company? Do we set target dates for how we release software - date driven? Or do we try to come up with rough estimates, iterate on feature development and releases and refine our estimates over time?
Technical design
How do we design for new features? Are technical designs approved by a committee? Or perhaps by the CTO? Can teams design their own features?
Releases
What is our release cadence? Do we release hourly, daily, weekly? Do we flight releases, rolling them out gradually until every customer has access to a new feature Do we have a beta program? For which features? How do we communicate about releases and new features to the rest of the company, notably sales, marketing, customer success and support?
Planning
The next category is concerned with the products that the engineering team is responsible for building. The set of activities here are mostly owned by the product organization, but the VPE, CTO and senior engineers are typically involved as well.
Product strategy & roadmap
This effort is typically led by Product Management, but inevitably requires help from senior leadership in the engineering organization. Product Management will oftentimes want to define a roadmap outlining what might be delivered in the future, typically covering a 6-12 months horizon. Doing so requires significant input from the engineering team both for high level cost estimates for the features on the roadmap as well as resources.
Budgets
As the team grows and the company matures, budgets will come in play. The VPE is responsible for maintaining both the OpEx and if applicable a CapEx budget for the engineering organization. This budget covers things like compensation for existing and future hires, which in turn mandates the number of hires that can be made in a given year. It also covers the infrastructure that the team uses like other SaaS products or hardware like laptops/servers and so on. Depending on the nature of the products that a company builds, some of the engineering related costs will have significant impact on the company’s financial performance. For example, a company building SaaS products will care about the cost of the infrastructure that its products run on. Those impact its COGs and ultimately margins. Therefore a VPE might be also tasked to optimize the infrastructure costs, which generally speaking is a good thing to do, to drive margins and profitability for the company.
Potpourri
This is another category of activities that a VPE can get involved in, which is really a hodgepodge of miscellaneous, yet oftentime critical activities. I dubbed it Potpourri for no reason other than the framework then can be known as 4Ps.
Account management: Escalations
It’s not atypical for a VPE to be involved in various customer activities. These can range from handling escalations either by ensuring that critical software issues are quickly addressed or communicating directly with customers regarding some of their open support issues. The latter can oftetime happen with large enterprise customers, who might want to have an open line of communications with the VPE.
Account management: Selling
The VPE might be asked by the sales team to help with a sales opportunity. This can arise if the prospective customer wants to have a better understanding about the product, the overall SLDC life-cycle, the overall QA process and how the product is tested. Again, this is fairly common with enterprise customers. Another activity that is related to sales is responded to RFP
Vendor management
The VPE might be responsible for working with external vendors and contractors. These could be vendors providing critical infrastructure for the company like AWS. They could also include contractors who are an extension to the internal engineering team or are providing products or services that the team or company utilizes.
Patents
The VPE is oftentimes responsible for working with patent attorney, typically external to the company and making sure that the correct inventions are filed. Patents are expensive, both in terms of money and time to prepare them, therefore there has to be some strategy of what to file and when.
This post is a part of a series that goes into the details of the VPE position and interview structure. Other relevant posts are
To receive this newsletter in your inbox every ~2 weeks, consider subscribing 👇