VP Engineering and VP Product: How to create a united front

I screwed up.

It was 2015 and I was VP of Engineering at an awesome cloud security start-up called CloudLock.

We had been working on a big bundle of new features for a while. Months.

At one point my boss, the CEO, told me "this will determine whether or not most of our customers renew." No pressure 

The marketing launch date was a few weeks away. We had already pushed the release back two times.

One of my Directors told me we overestimated the capabilities of a new API we were dependent on. Which meant we underestimated the amount of work it would take to deliver.

"How much longer?" 3-4 weeks he said.

Marketing had press interviews scheduled. Sales had customers lined up.

Our dev team had been putting in extra hours for weeks to hit our date. Now I had to ask them to keep going even though I knew the grind was getting to them.

All of that was bad but that is not how I screwed up.

I met with all of our leads that morning and gathered as much information as I could. Then I managed to get a last-minute meeting with our CEO so I could fill him in.

I told him everything. It was a good conversation. He was disappointed but calm. He understood.

Then he asked "what does Jennifer think?"

Oh shit. I screwed up.

Who is Jennifer? 

Jennifer was our VP of Product.

We had worked together for years. Both starting out as middle managers then getting promoted to Vice President. We were partners. Thick as thieves. Or at least we were supposed to be.

We were working this project together but in that moment I created a small but dangerous separation between her and I.

Our boss asked... "What does Jennifer think?" Great question. I had no idea. I hadn't asked her yet. In fact, she had no idea we were pushing the release. Because I hadn't told her yet.

How does the story end? 

There was no big dramatic blow-up.

But I did make Jennifer look bad. And I made myself look bad. And I contributed to confusion within the company that day.

Worse, I lost trust and credibility with her. It took me a while to earn it back. How did I do it? Don't worry... this is a story of hope and self-improvement and friendship and world domination!

The inherent tension between engineering and product

Plenty has been said about why it's hard for engineering and product leaders to work together. I personally think it comes down to three realities:

1. Product is incentivized to push value to customers as fast as possible. Engineering is incentivized to keep operating efficiency as high as possible.
2. The VP of Product is interfacing more with sales, marketing, and executives who care about business things. The VP of Engineering is interfacing more with engineers who care about technical things.
3. Product is more strategy. Engineering is more execution. If you boil that down, you basically have one department telling another what to do.

Ok so It's hard. But that's why you became VP of Engineering. Because you're great at building software but you're also great at leading people and translating engineering to executives.

Your different skills, experiences, and motivations are the reason you need each other. You literally can't be successful without each other.

How to keep a unified front with your VP of Product 

After that situation in 2015, I realized I needed to make some changes. I had to build a better relationship with Jennifer and that wasn't going to happen without an intentional effort.

So I bought lunch and asked her a bunch of questions like "why did you get into product management?" and "what do you expect from me as the VP of Engineering?"

I listened. I took notes on my laptop. Everything she wanted from me was fair.

We came up with a framework for our relationship. The theme was united front. And we came up with the three tenets to help us achieve our united front.

1. Shared view of reality 

2. Flow of information 

3. Shared success 

CloudLock flourished in no small part because Jennifer and I became a powerful team. Kicking ass. Taking names. Empowering our people to work together to ship software that our customers loved.

We taught each other a lot and we became friends. So I figured I better reach out to my friend to make sure I get the story straight. The quotes and video you see throughout the rest of the blog are from my Zoom with her on Friday, May 15th.

"The #1 thing we learned together that we tried to adhere to was the concept of united front". - Jennifer

1. Shared view of reality

Jennifer and I were aware that, sometimes in some other companies, engineering and product leaders didn't get along. As we talked about why this happened, we realized that some of it stemmed from each group having a different source of truth. If you're looking at different data about what's happening across your teams and projects, how can you possibly be on the same page?

 

2

 Advanced issues found

▲

 

Is perception reality? Maybe in some cases. But not here. We needed one shared reality. 

We decided it was especially important for us to be on the same page about our Investment Profile. Investment Profile just means who is working on what and we looked at it across three dimensions:

Ratio of stories versus bugs and non-functional (tech debt)

Resource allocation (which teams are working on which projects)

0

 Advanced issue found

▲

 

This one seems simple but it got hard to stay on top as our team grew in size. Especially since what Jira said was often not the truth when we started digging in with our team leads.

Ratio of innovation versus sales requests versus customer retention 

At CloudLock we actually called it Fix / Compete / Differentiate. Building features to keep up with competitors is different than true innovation.

The outcome of maintaining these views of our investment profile was our ability to have intelligent discussions about the following questions:

• Do our ratios align to strategic company goals?
• When are certain people/teams going to free up?
• How can we move this team from feature X to feature Z?
• How many people do we need to hire to meet demand?
• Are we investing enough in non-functional work to address support issues?

Maintaining this shared view of reality wasn't easy. Our company was growing super fast. New developers were being onboarded every week. Priorities were changing constantly.

We tracked everything in a spreadsheet and it took hours each week from lots of people across both teams to keep it updated.

But we got good at it and eventually got to the point where we could track thousands of hours across dozens of developers for each iteration. Even down to the "half-a-dude".

Jennifer and Dan explain how they tracked their Investment Profile down to the "half-a-dude" in this 50-second video.

2. Flow of information 

"You tell me big stuff first and I'll tell you big stuff first." That was our pact. After my screw up I didn't need any convincing.

To keep our shared view of reality and maintain our up-to-date Investment Profile, we had to talk to each other a lot. Jennifer was better at this than me. She's more of a social, get in a room, brainstorm, talk it out kind of people person. I'm more of a headphones on, do not disturb, get in the zone, Slack message kind of computer person.

But I had to break out of my comfort zone because, to stay united, certain things required constant, immediate updates.

There was a lot of important information that came to me first:

• "When is feature X going to be ready?"
• "Is that release going out on time?"
• Existing developer is leaving on XYZ date
• Significant bug reported by a customer
• Grumblings from tech support
• Production issues

Then there were the things she usually knew about first:

• Big deal came in where XYZ new feature was required
• CEO decided on a new strategic direction
• Feedback from beta customers

Our pact really worked. When we talked through everything first, we came up with great options and solutions and were able to speak more authoritatively to the business.

It helped us speak with one voice - whether we were together or not. That applied to our respective teams as well as with our CEO and the executive team.

Engineering team

Many developers think of themselves more as artists than scientists. They get wrapped up in what they are creating. So when things change, especially if they change mid-feature or mid-iteration, they can take it hard.

When Jennifer shared strategic changes with me first I was able to connect the dots on what it meant for my team, think ahead about all of the questions and objections I might get and translate the purpose and importance of what we were doing.

For example, my team at CloudLock got excited when I presented something as a "huge challenge". Engineers love solving problems. The bigger the problem, the more satisfying the work.

Dan talks about the importance of communicating strategic changes to devs in the right way in this 25-second video.

Product team

Product managers are no different. They develop strong opinions about what the company should be building so they really care when their features are delayed or don't get prioritized. Especially when something non-customer facing like non-functional work is ahead of them on the roadmap.

I always tried to tell Jennifer first because she was great at showing her team how the short term expense would translate into more features being delivered faster in the long run.

Executive team

Was my instinct that day to tell our CEO about the push right away understandable? Maybe. He was pushing hard on this particular project. I knew he would want to know ASAP.

But it was actually impossible for me to show up fully prepared for the conversation without talking to Jennifer first.

Jennifer explains why perfectly in this 40-second video.

If we had talked it out first, she probably would have come up with 10 ideas that did not involve us just straight up pushing back the release again.

3. Shared success

"Engineering and product teams need shared metrics and OKRs to stay aligned and encourage the teamwork you're looking for." 

One of the most demoralizing things I experienced in my career was when I was working on a team that finished a big thing and we were super excited about it... and then we noticed that nobody else in the business cared. That's a fast and effective way to crush the spirits of a dev team.

For people and teams to stay aligned, they have to share success and failure. To have that, you need shared goals. There are plenty of areas where the teams share responsibility.

User Experience is a great one. Product management, UX and engineering all have to come together to create a great experience for the customer. At CloudLock we used Pendo to measure several metrics related to usage (e.g. how often is XYZ feature used). It was a core data point that engineering and product looked at together regularly.

Cycle Time is another good one and it's not just for engineering teams. When product teams write clear requirements and success criteria, devs write more effective code faster, and review cycles go more smoothly. Conversely, when requirements are not well understood, coding time takes longer, review time takes longer and the overall time to deliver slows down.

Once we started measuring shared indicators of success we found that we were able to celebrate together frequently instead of just once every quarter after a big release. The positivity trickled down to our directors and managers and brought our teams closer together.

See 17 metrics modern engineering and product leaders are using to unite their teams and accelerate delivery.

Click here to download the guide.

Return on investment

Yes... Investing the time to create a united front with Jennifer was good for our company, good for our people, and good for Jennifer. But I'm pretty sure I got the most out of it :)

After we started practicing the tenets of our united front, here's just a few of the things I remember Jennifer doing to help me.

Scoping down to hit our deadline 

Great product leaders know what's really important and how to deliver 80% of the value for 20% of the work. There were countless times when Jennifer got in the trenches with us at the end of an iteration to figure out how to deliver something on time that would make customers, sales, and, marketing happy.

Air cover with the business 

Our CEO was a great motivator... always trying to add more features without taking any away. :) When Jennifer advocated for engineering, he was a lot more willing to negotiate.

Investing in more non-functional work 

Jennifer did a great job of articulating how some of our non-functional projects would actually benefit our customers and our business in the long-term. Better than I could on my own.

For example, when I wanted to fully automate our test coverage, Jennifer helped me position it to our exec team as a strategic priority versus just "more automation."

Investing in more engineering hires 

Our investment profile was rock solid and backed by data so when the CEO was asking for more features, Jennifer was often the one who would point out we needed more devs.

Purpose-driven development

Jennifer connected my team directly with customers which brought a whole new meaning to our work. Truly understanding the people using our product gives us a higher purpose which led to happier developers and better work.

Jennifer talks about why she brought Dan into customer meetings in this 90-second video.

Jennifer's full truth 

In case you're wondering, Jennifer opened up about how she really felt that day when I shared our big news with the CEO before her.

She was joking. I think :)

I took everything I learned from my experiences at CloudLock and started LinearB. We connect and analyze data from Git and Jira to create a single source of truth to help engineering and product leaders build a united front. Check it out.