The VPP/VPE Relationship

This post was co-authored with Michael Richardson, who leads Product at Routable. You’ll understand why we’re writing this piece together very shortly.

At most companies, Product and Engineering are separate organizations. But effective organizations aren’t really separate: neither can succeed without the other. Without good product management, engineering might ship great code, but they risk shipping features that customers don’t want. (In practice it’s frequently much worse: without good product management, engineering often doesn’t ship at all.) Product teams can have the best ideas in the world, but they’ll fail if the engineering team doesn’t understand or fails to implement those ideas.

Product, at its heart, is the shaping of the company’s future by synthesizing customer needs with business opportunity. Engineering manifests that vision and is constantly pushing forward the boundary of what’s possible. It’s the flow between these organizations that makes effective product development. Software businesses are driven forward by the correct opportunity, done in service to the right customers, at the right time, reliably built and maintained over time, and commercialized effectively.

For an organization to succeed – to reliably and consistently deliver great products that customers want – Product and Engineering need to work well individually, but more importantly, they need to work well together¹.

The working relationship between these two organizations starts with the relationship between their two leaders. Titles differ, but in this piece, we’re referring to them as the VP Engineering (VPE) and the VP Product (VPP). If these two individuals don’t have a strong individual working relationship, the team relationship is doomed².

That’s what this piece is about: what a strong relationship between the VPE and the VPP looks like, and how to build it. We’ve seen first-hand how important this relationship is, in these roles where we’ve needed to build these relationships personally, and want to share what we know. This article itself is a bit of a case study: we came up with the idea together, brainstormed it together, and it represents the blended sum of our joint Product/Engineering leadership experience.

Why it’s so important for the VPE/VPP to be aligned

What does it look like when these organizations are out of lockstep?

There are many symptoms of a misaligned organization, and these symptoms can cause cascading missteps, friction, and frustration throughout both the org and the entire business.

Missteps

A misstep isn’t the end of a company. But if all you’re doing is stepping poorly, and not improving over time, then that’ll end up being a pretty bad time for all involved (customers included). Many common missteps for companies can be caused by misalignment between product and engineering:

• Building the wrong thing. The classic result when there isn’t joint conviction and joint critical thinking about a path. Valuable time and energy is wasted on something that ultimately doesn’t have much business impact.

• Unreliable planning. There’s a lot to be said for better estimation to get more reliable, but ultimately many financial plans need to be based on a roadmap. When that roadmap diverges significantly from reality, there’s often a direct financial impact, and scrambling across teams to figure out where to find an immediately addressable opportunity.

• Shadow plans. When Product and Engineering work together, there’s a unity of purpose. In misaligned organizations, you’ll often see dual plans for what engineering is going to do, and what product wants to build for their customers. In reality, you end up with some kind of in-between monstrosity that doesn’t benefit anybody.

Repeated missteps, if not addressed, can be the death knell for a company.

Frustration

Aside from the potential impact to the company itself, there are serious concerns for the people on misaligned teams. When leaders have conflicting approaches to solving problems, or even how to approach opportunities, you lose flow between organizations. Some classes of problems might not even attempt to be addressed, because they aren’t seen as important!

• Team vs individual empowerment. Strong product and engineering teams are the best atomic unit of product development. When both organizations try to optimize for individuals, then you’ll have a large group of people who aren’t set up for success and will struggle to do their jobs. Likewise, if one group is optimizing for individuals and the other for teams, problems will be solved in different ways (a valuable employee being forced to leave the company instead of being offered a role change, as an example).

• Conflicting messaging. When one person says something that’s slightly off or conflicting with another, you introduce subtle but inherent conflict around which “side” you believe to be more correct. That can manifest itself in arguments around approach and priority and lead to team and individual frustration.

• Politicking. Putting the onus on individual contributors to maneuver between the two leaders in an organization puts them in a hard spot and disempowers them. It creates “sides”, which creates increasingly more conflict.

All of this frustration can lead to retention issues and unhappy staff.

Friction

Ultimately, in unaligned organizations, it’s simply harder to get things done. The friction of the day-to-day, and the system in which people operate, outweighs any inherent velocity or momentum in a team:

• Slow decision making. It can take a long time to get people on the same page if they approach problems very differently. This can cause major stalls in planning and productivity.

• Inaction. Issues can sit unresolved for a long time because the cost and difficulty of addressing them is just too high. This could be a personnel issue, a resourcing issue, or even a major strategic choice.

• Misplaced resources. Often, in these types of situations, only the easy and obvious things will get funded. People will route around conflict and you’ll start to see well-funded teams develop that are far away from the misalignment, or see side projects that solve tertiary problems get momentum. In addition to being wasteful, this is often demoralizing.

All of this friction can lead to repeated delays, inaction, and a lack of progress.

What alignment looks like

The responsibility for making sure that these bad things don’t happen lies first with the VPE and VPP. Solving or preventing these problems starts with alignment between these two individuals. When the VPE and VPP are truly aligned, this is what it looks like:

• The VPE and VPP speak with a single voice to the organization. If you were to ask, say, for a list of the current priorities, you’d get the same list from each person. The level of personal involvement or level of commitment from their respective teams might differ, but both would agree on priority. For example, if there was a complex platform upgrade in process, you might expect the VPE to know more about its status and to have committed more of her team to it, but if it’s the #1 priority you’d hear that it was #1 from the VPP as well.

• There’s shared ownership of product delivery. When something goes well, it’s viewed as a shared success – “we built this”. There’s no jockeying for credit, no arguments over who “really” worked on a project. The VPE and VPP congratulate each other and their teams when projects succeed, and jointly share the failure when they don’t. More importantly, they jointly share the commitment to continuously improve the entire process.

• Disagreements are handled clearly, quickly, and professionally. There’s a mistaken belief that highly functional relationships are ones without disagreement. This isn’t true: disagreements happen all the time! In a strong relationship, with lots of trust, these disagreements are no big deal: they can be discussed, debated, and resolved.

  Counterintuitively, it’s the dysfunctional, distrusting relationships where you won’t see any disagreement: it isn’t safe to discuss. As Patrick Lencioni writes in The Five Dysfunctions of a Team:

  When team members do not openly debate and disagree about important ideas, they often turn to back-channel personal attacks, which are far nastier and more harmful than any heated argument over issues (p. 203).

  When the VPE and VPP are strongly aligned and have a strong personal relationship, they’ll model this behavior. You’ll observe them disagreeing, but they’ll do so professionally, and resolve disagreements quickly and clearly. Once a decision is made, they’ll align behind it regardless of whose idea it was originally.

When the VPP/VPE are on the same page, this strong working relationship goes a long way towards preventing missteps, friction, and frustration.

Tactics to build alignment

Now that we’ve seen what good alignment looks like, let’s figure out the tactics that can help get there. It’s easy to talk in broad strokes about “mutual respect” and “good working relationships”, but harder to articulate the specific tactics and activities that can get you there. Further, there are no right answers here; so much depends on the individuals in question. However, there are some patterns. Here are some of the things we’ve seen work repeatedly:

Hold regular one-on-ones

Start with the basics. The foundation of nearly every successful VPP/VPE relationship we’ve seen rests on regular individual meetings. Y’all might spend this time reviewing priorities, discussing staffing and hiring plans, asking each other for help with tricky issues, etc. One of the most important uses of one-to-one time is to pre-wire an upcoming decision: if something’s going to be contentious, you can get on the same page ahead of time and go into an important decision with one voice.

Weekly is an absolute minimum; many successful pairs meet much more often than that. On collocated teams often these other “meetings” are quick encounters in the hall, a few moments at each others’ desks, a trip out to coffee together, etc. But if you don’t work in the same office as each other, it’s important to schedule enough time together each week. Slack is OK for some sorts of quick discussions, but not sufficient to build the level of trust you two will need to have with each other.

Agree up-front on values, norms, and principles

Inevitably, there’ll be disagreement, conflict, or even crisis. Prior preparation makes the difference between a disagreement that’s resolved quickly and to mutual satisfaction, and one that spins out of control. It’s nearly impossible to agree on high-level values in the heat of a disagreement. On the other hand, if that agreement already exists, it can often resolve a disagreement about tactics before it gets bad. Conflict or crisis can be navigated more smoothly if you can fall back to shared values, agreed-on norms, and mutually understood principles.

Therefore, it’s important to work these things out ahead of time, when the situation is calm. We recommend that the VPE/VPP spend plenty of time early in their relationship – both individually and with their teams – coming to a shared understanding of values, norms, working principles, etc. To get you started, here are some questions you might want to work through together:

• What are our teams’ values, and how do we live those values day-to-day?
• How should we structure our working processes?
• What are those processes set up to achieve, and why?
• What is our process and structure optimizing for?
• What sacrifices are we willing to make to optimize for those things?
• What is the role/area of responsibility of each team, and the role of each person within those teams?
• When things get sticky, what questions should we ask ourselves to help resolve problems?
• When we disagree, how should we resolve those disagreements?

If you work through these kinds of questions – and write the answers down! – you can return to those answers when you need them, and they’ll help you navigate stormy waters.

Develop joint roadmaps, priorities, and hiring plans

Much of a director/executive’s time is spent doing long-term planning: things like articulating priorities, developing roadmaps, and allocating budget and headcount to support those activities.

It’s easier to develop these kinds of plans separately, but you’ll both be much more successful if they’re shared plans. Separate priorities or roadmaps require frequent re-alignment, at best, and can even come into conflict. Remember that Product and Engineering can’t succeed without each other, so we suggest you explicitly hitch your fortunes to each other and develop long-term plans as single, shared roadmaps.

If your organization uses OKRs or similar, try to make as many of them shared as possible. They don’t have to be 100% the same, but you should certainly make sure they don’t conflict!

We also suggest considering budget and headcount to be a shared resource. Often your organization will allocate these separately – X net new headcount for Engineering, Y for Product – but that can lead to inefficient hires. Instead, once you’ve agreed on your long-term priorities and roadmaps, consider together how you should best hire and/or spend budget to get there. Sometimes “giving up” a hire to your counterpart can lead to much more success than jealously guarding these reqs.

Work as partners

One of the key ways that great VPE/VPPs work well together is by supporting each others’ work. This a balancing act: both should know enough about each others’ discipline to lend a hand and take some of the load, but both also need to know to step back and respect domain boundaries.

On a very basic transactional level, each needs to know enough about the other field to let their counterpart take some vacation! But going deeper, great VPP/VPE pairs can stand in for each other with their respective teams, saving some of the “back and forth” that can happen with less-skilled and less-aligned pairs. For example, a good VPE will know enough about Product Management to recognize a poor product decision in a beta version and correct it without needing to block everything waiting for a PM. And a good VPP will know enough about the underlying technical architecture to recognize product decisions that will be too difficult to implement and find a better way without having to go back and forth with engineering. And, of course, modeling this behavior helps encourage the engineering managers and product managers that report to them to develop these skills, too.

You can work on this by explicitly teaching each other – take some time to explain some piece of technology or a product management technique. You can practice by giving each other lower-stakes work in the other discipline, and debriefing together. You can sit in on each others’ key meetings, like important customer calls, technical decision sessions. It can sometimes be helpful to attend each others weekly staff meetings. All this can help build context and skill so you can push the boundaries of your domain to somewhat overlap your counterpart’s.

However, this sort of stepping-in needs to be balanced against some boundaries and respect for each others’ domain. Each needs to be self-aware about their level of knowledge, and the consequences of deciding without their counterparts’ input. They need to recognize situations where they should defer to their counterpart – and do so.

When those boundaries need to be drawn, do so clearly: “this is an engineering decision, so we’re going to get Amelia’s input before we proceed.” And, critically, back each other up. There will inevitably be decisions that are less popular with one team than the other. For example, a common friction point is between shipping new features and paying down technical debt. A good VPP will trust the VPE’s analysis of an acceptable level of technical debt, and back them up if there needs to be a feature freeze to attend to a critical migration. Likewise, a good VPE will trust the VPP’s customer knowledge and back them up if corners need to be cut to meet a market deadline. Whichever way that decision goes, y’all should be presenting it as a single shared decision, supporting it fully, and modeling that unity of purpose for the team.

Conclusion

Throughout our careers, we’ve been lucky enough to work closely with partners in the other organization. This has required hard work to establish close working relationships, but those relationships (and, often, friendships) go deep and often remain long after careers take people apart.

Many of these tactics were developed organically through experience combined with a strong desire to have a close working relationship with the person probably most essential to you being able to do your job effectively. By actively developing that relationship, you’ll both be able to go farther than you could on your own, and hopefully a lot faster. And, of course, it’ll hopefully end up being a lot more rewarding as well!

If you have more things that have worked well for you, we’d love to hear from you.