How Eng and Prod can work better together

There exists a natural tension between engineering leaders and product leaders. This tension is good because we need to focus on both - building the right thing and building it right. However, this tension sometimes moves out of the healthy realm to the "us vs them" space causing a lot of problems for the developers. This doesn't have to be so - by identifying areas of friction and intentionally working on them, you can go from a sometimes good relationship to a great one.

I believe that the relationship between these two "bosses" of the product team rests on three pillars - creating boundaries, building alignment, and growing trust.

Good fences make good neighbors

Creating boundaries at work is really focused on clearly understanding what each member of the team is supposed to do. This goes beyond the traditional roles and responsibilities document in your company. Although that is a great way to get started. If the official R&R document sounds vague you can also get together at the org level and create a RACI document outlining who's Responsible for, Accountable to (and can make decisions), need to be Consulted, or just Informed for each of the "jobs" within a team.

However, I've found more success with a team chartering session. Get the team together and an external facilitator (bonus if it's an agile coach) and start to hash out your team's goals, mission, vision as well as team's operational routines. Ask the tough questions and decide how decisions will be made within this team.

Ask questions like 'Who signs off on the decision to go to Prod?' Or 'What should we do if the onCall engineer doesn't respond at 2 am?'

It doesn't matter if all questions don't get answers - the key is to bring all latent concerns and unstated needs to the table. The stuff that never gets said but influences opinions anyway. That's half the battle won. Use a format that works for you with questions that keep your team up at night.

Bonus Material

When looking at the stated or traditional roles and responsibilities of Engineering Managers and Product Owners in your organization, understand that all of them are not made the same way. Depending on their personal strengths, their life experiences, and what's worked for them at your organization, there will be different models of successful EMs and POs. Read more about Engineering Manager Archetypes here. I've found a Product Owner archetype list also here

Realign Routinely

How do you know if a product team lacks alignment? When you ask the EM and the PO the same question about the Product or a Feature feasibility and you get very different answers. Another common symptom is when the PO wants a feature and the EM says no, they try to get the developer to build it anyway. Or the EM wants something to be built that's not on the backlog and they ask the developer to build it without checking in with the Product owner.

In a healthy relationship, this should never happen.

One of the reasons a team may be misaligned could be due to a structural misalignment.

Engineering and Product Orgs need to be mirrored and balanced. Typically there exists a Head of Product (Director of Product) and a Head of Engineering (Director of Engineering) whom each has Product Owners and Engineering managers reporting to them. Additionally, the respective heads do not report to the same boss. This is key in order to allow each part of the organization to have equal heft and strength so that the power balance is not lopsided.

If this is not the case and the orgs are balanced consider whether Building alignment needs to be not just at the team level but at the org level. Backlog grooming, sprint planning, and standups all serve to build alignment between the engineering and product stakeholders on where we think the product should be going.

However, for true alignment, the Head of Engineering and Head of Product also need to be aligned. One mechanism to do this is using the OKR method - Objective Key Results. You can learn more about OKR's here (book reco!) My Product counterparts and I get together every quarter to discuss what the key objectives of the product are and how we will measure the results.

Trust Compounds

Once you set up boundaries and plan to realign regularly you do know who is supposed to do what and what the product direction is. Nothing will still get done unless you can trust each other to get there.

Trust compounds in everyday interactions.

The more the credibility, reliability, and authenticity of the interactions between the team members the more trust grows. If there's a perception that your actions favor your personal interests over the team's interest trust negates.

An area where the credibility and reliability of the engineering team has the potential to come under stress is when incidents occur. Production incidents are a period of high stress for the product team. As a product owner, who has to answer to the business the pressure is immense since they can't actually fix the issue. Here's where engineering managers can play a key role. How do they set up systematic OnCall Management playbooks? Communication during incidents needs to be clear, transparent, and frequent. Product owners and stakeholders need to feel that the engineering team is reliable and will show up in a consistent manner when bad things happen, and fix them.

What occurs after an incident is equally important. Is there a clear process for building RCA (Root Cause Analysis) documents? Are there blameless retros? Anyone who can honestly self-reflect and learn from mistakes automatically gains credibility.

The biggest problem that needs to be fixed in eng-prod interactions is this - Product owners ask the questions (when will we ship?), engineers answer. Product owners state what needs to be built, the engineers build them.

I have rarely seen Product Owners share their thoughts and wait for the Engineers to ask questions. I've rarely seen a Product Owner share their status during a standup. Or Product owners who share what they learned from the users and Engineers chip in about what needs to be built.

My advice for more authentic and empathetic conversations between engineering and product owners? PO's share context and let engineers ask questions.

Sometimes there's a perception that when things go well the PO gets the credit. When there's an issue? The engineering manager is under fire. Both EM and PO need to get together and make sure that the recognition goes to the team first rather than take the credit. Nothing builds trust more than stepping back and letting the team take credit for the work done.

There you have it - three actionable ways to strengthen the relationship between engineering and product. What's worked for you? Are there other points I am missing? Do share in the comments.