What does a VP of Engineering do? – Dan DeMeyere – Medium
When people ask me what a VP of Engineering does, I like to reference the analogy Mark Suster used in a blog post clarifying the difference between a CTO and VPE:
VP’s of Engineering are essential to making sure the trains run on time.
Having been in this role for a while now, I’d expand that by saying:
VP’s of Engineering are essential to making sure the trains run on time and identifying the best way to lay down tracks.
If the CTO knows the destination, the VPE is identifying the route to get there.
Driving the Trains
Before we unpack what a VPE does, it is essential to understand the different roles within engineering leadership.
When I was a Lead Engineer, it was my goal to tackle challenges by thoughtfully driving collaborative efforts based on everyone’s strengths. While I impacted our processes and culture, my primary focus was influencing outcomes for our team’s projects, moving our tech stack in the right direction, and mentoring engineers.
Once I transitioned into Director of Engineering, my sphere of influence on the team needed to grow. I was no longer measured by individual contributor heroics or by how successful a string of projects were. I was measured by my ability to build high-performing teams and consistently deliver results for the business. In other words, getting out of the driver’s seat of the train to enable multiple trains to run concurrently.
Professional development during this time was straightforward: I aspired to become a better manager. I focused a lot on team culture and hiring, which go hand-in-hand because you have to know what you stand for as a team before you know what you’re looking for. I also worked on our organization, communication, and transparency. After working on these for multiple years, I was offered the VPE opportunity.
Timing the Trains
While the scope of a VPE’s responsibilities are well defined, the role is more abstract than a director or lead. For example, if a project doesn’t go well or stakeholders don’t believe a certain team is moving fast enough, a lead or director will work to understand why. Maybe the planning wasn’t sufficient or certain members of the team aren’t performing at the level they need to. This root cause analysis is important, but a VPE should be the person weighing in on the 40,000 ft view. Can the engineering leader responsible for this team identify the right path to correct the situation or do they need guidance? Is this failure an exception or is this a trend across multiple teams? If it’s a trend, do the teams have the required context, resources, or cross-functional support? The VPE needs to focus on identifying trends like these to help orchestrate the harmony of the engineering trains.
This type of tactical orchestration is a prerequisite for the role. It doesn’t matter how strong you are technically, how great you are at hiring, or how well you partner with the business — if the trains aren’t arriving on time, then you’re failing to deliver on the core responsibility of a VPE. Full stop.
Once this prerequisite is met, a VPE can work to expand the influence of their role to empower their teams to deliver bigger outcomes for the business. In other words–strategically laying new tracks or thoughtfully relaying existing tracks. In my experience, the best way for a VPE to create or improve tracks is through the use of leverage, context, and loosely coupled, highly aligned teams.
Leverage
Leverage within the context of my role is analogous to a physical lever where the output force greatly exceeds the input force due to strategic application. For example, if I were to spend time offloading my domain knowledge or experience during a 1:1 code review, the input/output would be linear. If instead I worked with engineering leaders across teams to set up cross-domain technical mentorship relationships, there should be an outsized outcome relative to my input force.
Said differently — with time being your most valuable resource, a VPE should seek the greatest return on time investment to maximize their sphere of influence over the engineering organization.
Since it’s our bread and butter, the most obvious opportunities will be technical. While architecture and technology opportunities are valuable, there are many other dimensions in which to identify leverage. Are our hiring priorities and plan right? How will our engineering structure scale with our hiring plan? Is our culture evolving in a healthy direction as we grow? Are all of our roadmaps aligned to meet both the needs of the business and our architecture? Do all of the teams have the right context for where we are as a team & company and the direction we need to head in?
These are questions a VPE needs to obsess over. The answers to these questions affect the entire team, and that is the type of leverage a VPE should be seeking.
Context
In order to scale a talented team, they need to be able to operate autonomously. The key to that autonomy is the team having the necessary context to make good decisions: business context. Customer context. Technical context. Every day the team makes infinitely more decisions than I do across all facets of engineering. If they’re pulling from an empty well of context, they won’t have what they need to make informed decisions and set priorities. Keeping that well full is some of the best leverage an engineering leader can provide.
For example, one of the teams I’m responsible for is the user growth team. Ideally the engineers on that team should be partnering with their business stakeholder and cross-functional partner (Product) to identify the right growth opportunities and prioritize their roadmap to deliver the biggest return on engineering investment. To identify the right opportunities, these engineers need to have business context for this domain. What are all the customer acquisition channels? What do each of their funnels look like? Which are above or below industry standard? What is our current spend across channels? What is our growth forecast for the year? How is our Marketing leadership team thinking about channel diversification? This type of context isn’t necessary for just ideation or prioritization; this type of context should be dictating technical decisions as well. If you’re prospecting for conversion wins, then move fast and A/B test a quick MVP. If there’s an opportunity to facilitate a strategic shift in the domain, then it’s time to revisit the foundation that domain was built upon to ensure it’s equipped for the shift.
When context is relayed properly, it should have a cascading effect. It starts with the company strategy. What is our CEO’s vision for the company and how does our CTO plan to enable that vision through technology? That vision will give birth to the strategy for the functional department heads and their engineering counterparts, which will cascade down to the teams to be a lens for roadmaps, priorities, and implementations. I try to be at the center of all of this — constantly seeking the context I don’t have for strategic decisions made across the business. With that context, I can stock the right wells so talented teams can function autonomously and thrive in their domains.
Loosely Coupled, Highly Aligned
When you have high performing teams operating autonomously, be mindful of technical collisions and/or conflicting domain decisions. I apply a standard principal with regards to this problem: “maximize cohesion and minimize coupling”.
For teams to have true autonomy to make an impact in their domain, they need to be loosely coupled. When teams become overly dependent on each other — especially for technical reasons — independent tracks of work start to congeal into a monolithic, waterfall roadmap. This limits agility and therefore impairs the ability to iterate and learn quickly.
Loosely coupled does not mean mutually exclusive priorities or boundaries. In fact, I’ve found the most success when there’s some collaborative overlap across teams focused towards a shared platform or outcome. Facilitating the peripheral vision for engineering leaders to identify these symbiotic relationships across teams is a great source of leverage to maximize the collective impact for the business.
In the words of Ed Catmull:
Driving the train doesn’t set its course. The real job is laying the track.
While the core responsibility of a VPE is to keep the trains running on time, there are always more destinations to reach and routes to be improved. Generating leverage, seeding context, and facilitating loosely coupled, highly aligned teams is a great way to supplement the core VPE responsibility and maximize your sphere of influence over the engineering team.