Director of Engineering vs. VP of Engineering: What’s the Difference?

January 5, 2022 • Engineering Management

The wide world of engineering leadership can be, well, a little confusing. To help you get a handle on things, we’re going to present a run-down of how engineering management looks at the top level. At this point, we’ve already covered:

how to make the transition to becoming an Engineering Manager
how to manage teams more effectively, and
a guide to engineering career ladders

Now, we’re going to discuss what makes a VP of Engineering successful and take a deeper dive into what separates this position from the levels below it, specifically a Director of Engineering (DOE).

There is, however, a caveat when addressing these roles. Depending on the size, scope, and structure of an organization, responsibilities (and sometimes names) of roles will differ — as such, there’s no one-size-fits-all job description. VPEs and DOEs could oversee teams of 20 or, in other cases, 250.

And one last bit of housekeeping: for the purposes of this article, we’ll define a Director of Engineering as an individual who manages a team of managers (also known as a second-line manager) and we’ll define a VPE as a manager of managers’ managers (or a third-line manager). Try saying that three times fast.

Without further ado, here are 5 key differences that set a VPE apart in an eng org.

Difference #1: More focus on the engineering organization, less focus on the quarterly deliverables

As the VPE, you’re now the face of the eng org. That means, compared to a Senior Engineer or even a Director, you’ll have a much wider range of considerations on your plate.

To start, your focus will be set on longer-term objectives rather than individual sprints. In practice, this means orienting yourself toward organizational deliverables rather than quarterly deliverables. As a VPE, you will need to have a vision for the organization’s trajectory over the next 12+ months — one that takes into account things like the robustness of systems and the team’s overall productivity and efficiency.

Another key contrast between EMs, DOEs, and VPEs is a shift from tactical delivery metrics to organizational delivery metrics. In the role of VPE, you’re likely to analyze things like eNPS surveys to get a clear sense of organizational health and ensure predictability of delivery is in place over the long term.

Part of understanding what it takes to be a successful VPE lies in formulating the right questions — especially those pertaining to team structure and workflow. As an executive manager, you might ask things like:

Does it make more sense to work in-person, 100% remote, or find a hybrid model? What are the trade-offs of each?

Are there talent gaps present? Should you address them through hiring or upskilling — alternatively, should the org expand its geographic footprint to address these talent gaps?

Is there any friction between teams leading to inefficiencies?

TL;DR It’s a big shift — you’ll move from architecture of the code itself within your own domain of responsibility to architecture of how the team operates and is organized.

Difference #2: You own refactoring the org and managing organizational debt

Between new hires, teams that might not have even existed six months ago, and evolving objectives from the top down, a lot can get lost in the mix.

This brings us to organizational debt.

If you have experience as — or working with — an EMs or DOE, you’re probably familiar with tech debt. As described by Martin Fowler, these are “deficiencies in internal quality that make it harder than it would ideally be to modify and extend a system further.” Engineering Managers, Directors of Engineering, or Tech Leads can typically assess and refactor tech debt by digging into the code, modifying it, and ‘cleaning it up’ in a way that makes the code more stable in the long run.

When it comes to organizational debt, however, things can get a little more complicated. Org debt is similar to technical debt, but it’s applied to the pitfalls that compound across the entire organization during its growth. Rather than dealing with just devs and technical personnel that have helped to get a product off the ground, org debt encompasses all the people, management decisions, and the broader culture that have been implemented.

Put simply, if something in your org is not working, you’re responsible for going back and identifying possible roadblocks that have led to bottlenecks.

So how do you approach a problem that might touch all parts of the org? Despite its scope being larger than tech debt, org debt can be managed and groomed like a product backlog. And, moving forward, you can be part of the solution; avoid unnecessary org debt by communicating with managers about what works for their teams and being intentional when implementing new processes.

TL;DR VPEs need to have a full picture of an org’s past and future development to understand org debt. Then, they can actively re-factor, raise problems to individual managers, or, if need be, find solutions themselves

Difference #3: Measure progress over multiple quarters or years vs. in-quarter

Organizations can’t be refactored as quickly as a single team can — and, naturally, there are going to be some problems you can’t solve on your own.

Therefore, your mindset with regard to determining progress as a VPE will differ from DOEs or EMs. As a manager of other managers who have varying operational timelines, your roadmap spans the long-term, and your metrics of progress might span multiple quarters or even years.

Let’s take a step back, however, and think about what ‘progress’ means at the company-wide level. In a previous blog post, we talked about different measurements that managers use — as a manager of ICs, delivery metrics will include things like code churn or cycle time. But in the role of VPE, you’re more likely to use metrics that relate to the cross-functionality of teams and measures that apply to the whole organization, such as employee satisfaction or budget variance.

Once you’ve determined the org metrics that matter most to your company’s unique objectives, you should distribute them down to individual managers.

For example, if there’s friction between teams during hand-offs, you might need to reorganize the groups and re-evaluate and redefine the interfaces between them. Likewise, if you notice that the eNPS score is decreasing or hear about delivery issues occurring several levels below, you should introduce feedback loops that consistently collect information. This, in turn, gives you the full scope of your org’s effectiveness.

TL;DR It takes time to re-factor an org — measure progress in the long-term and move from delivery metrics to organizational metrics to get the full picture

Difference #4: Set the strategy — don’t wait for someone else to set it for you

As you move up the career ladder, you may also take on additional responsibilities for org planning and internal documentation. And, unlike DOEs, VPEs are involved in both setting the broader business strategy with executive-level peers and developing an engineering strategy that cascades down to teams.

So what, exactly, is a strategy? A business strategy is a company’s deliberate plan to reach its vision. It usually assesses a company’s position against the rest of the market and outlines top-level objectives. For eng orgs, though, it’s just one part of the equation.

An engineering strategy addresses the tech specifications needed to reach the business vision, considers how eng teams fit in with the broader organization, and weighs current eng/tech capabilities against what a company will look like in 2-3 years. Without an eng strategy, business objectives may not be grounded in reality.

Here’s the good news: An engineering strategy doesn’t need to be ultra-complex or even that exciting. As Will Larson, CTO at Calm, describes, “the reality is that a good engineering strategy is boring, and it’s easier to write an effective strategy than a bad one.”

To take the lead on an eng strategy, Larson also recommends creating design documents. Design docs outline a specific engineering problem in an org, discuss possible solutions, and explain the details of the selected approach. You may want to create several design documents in the beginning that outline the details of various objectives, then synthesize them into one final strategy. Again, it doesn’t have to be perfect — but it should be specific.

When gathering information from other managers about current weaknesses and gaps, you might ask about:

The technology they currently use and if it is/isn’t sufficient

Gaps in experience within their teams

How they raise issues and bottlenecks to superiors, and if they have a way to build them into team planning

With this data, you can fine-tune the engineering strategy so that it aligns with — and ultimately strengthens — the business strategy.

TL;DR Get specific in your strategy and communicate across the org to decide what to include

Difference #5: Rely on domain experts, but ask the right questions

If you’re eyeing becoming a VPE, you’ve likely already come a long way. Accruing more and more technical expertise will certainly help you move up the ladder and can get you up to the level of Director; but once you cross the threshold to become a VP, this technical knowledge won’t get you much further.

Despite what we’ve covered so far, though, ascending to the VP level doesn’t mean you need to be superhuman.

It’s crucial to admit you don’t know everything and, moreover, to be open to learning about new areas so that you can be informed and ask the right questions. In the role of VPE, assessing the decision-making quality of your team and understanding execution risks are more important than being an implementation expert yourself.

In the end, the best way to scale is by ‘giving away your legos.’ As the org grows, there will be new people taking on new responsibilities. Even if they’re taking over a domain you started, VPEs need to recognize that building something bigger requires handing off the individual pieces to others.

Molly Graham, who oversaw fast-growing teams at Facebook, Google, and Quip explains, “Almost everything about scaling is counterintuitive… one of the foremost examples is that reacting to emotions you’re having as your team adds more people is usually a bad idea.”

Embrace growth by resisting the urge to grip your old responsibilities too tightly — there may be an adjustment period, but it’s all part of the process.

TL;DR Change happens fast, and it can be chaotic. Learn from and trust the experts to ensure teams are consistently making thoughtful decisions.