Part 2: How engineering leads can work well with product management leads

This is the second part of a 3-part talk given to the CTO School. Part 1 covered good vs bad product management. Here I want to share ten ways an engineering leader can best partner with their product management counterpart.

1. Think strategically about the pressures on the business, not just the pressures on engineering

One of the benefits of creating a triumvirate between an engineering, product, and design leader is that each person brings a different perspective and skill set. It creates a healthy creative tension, but everyone has to remember that they are there to make a great business, or you’ll have no business. Inevitably, this means compromises — for everyone. This seems obvious, but so often I’ve see people retreat to defend only their corner.

2. Be a creative partner fascinated by customer needs; be willing to gather direct research on those needs

It is really important for engineers to understand the problems they are working on. It is important for everyone to have some empathy towards the customer. As a leader, you set the tone. Make sure that you sit in on a few customer interviews. Make sure that your people do the same. Listen with an open mind to customer support, even though it might be painful to be reminded of all the problems you know about and some you might not.

3. Inspire your engineers to be creative partners, not just in engineering problems, but product problems

A team of active creative partners is a beautiful thing to behold, and even more fun to be a part of. Not everyone should be doing everything together — that is far too inefficient — but the creative process should include everyone. As much as I love the song (and that machinima), don’t let your people be treated like code monkeys, and don’t let them act like one (“just tell me what to build already”).

4. Don’t sandbag

I would not be surprised if you have a few non-technical people in your business who need to be given very conservative estimates because they stubbornly refute the true complexity and uncertainty of product development. I get it. But within your triumvirate, trust each other and make best guesses and you together try to set expectations. Be partners.

5. Accept tech debt, but don’t hesitate to challenge it

Tech debt is probably the most common cause of conflict. Some people fail to appreciate work that doesn’t directly impact the UI. It’s a version of “out of sight, out of mind,” I guess. But inside the product leadership team, everyone probably gets it. They just might not agree on when to work on it.

I believe that you should include infrastructure-related OKRs/KPIs in your heartbeat reports so that you can spot the creeping/growing impact of tech debt.

In the early stage, you should refactor as you can but it usually happens less while you hunt for some semblance of product-market fit. Plan for periodic infrastructure-focused iterations. And make sure everyone knows that they can ring the alarm bells if they think it is getting out of control (I think of it like letting anyone pull the stop cord on the Toyota production line).

For later stage teams, I think it is generally best to have a rotating team(s) that is dedicated to infrastructure and refactoring.

6. Engineering, product and design all report to the CEO

I think the best scenario is a trio of equal partners, but there are three caveats to this. First, the CEO has to have the capacity to have 3, not 2, reports. Second, the leaders have to be truly ready to be leaders. Third, the business has to be able to afford true leaders. If any of these three things do not apply, it is better to tuck a role under another one. There is no one answer. It is common to see design report to the head of product, but I’ve also seen PM report to engineering successfully.

7. Create a team working agreement for leadership, not just the cross-functional teams

I’m a believer in team working agreements that cover the ground rules for how work gets done (processes, tools, hours, expectations, etc). A publicly shared working agreement makes things explicit and gets ahead of problems caused by false assumptions. This concept isn’t just useful for your teams! Create a working agreement for the triumvirate as well. The more things are above board, the less nasty politics you will have.

In terms of dividing things up, I roughly think of it like this:

• PM is point on the outcomes and priorities
• Design is point on the user experience, voice and visual identity
• Engineering is point on how something is built
• Everyone is a creative partner and gets a say in the above

A product business requires constant compromise because quality is a relative thing. Sometimes you will deeply disagree with a decision. Democracy does not always pick the best answer given inevitable uncertainty. Build an appeals structure into your team working agreement for when one leader seriously disagrees with the decision. The appeal goes to the CEO. If all three leaders know that this is an accepted option for everyone, then you can preserve a transparent process not an invisible, political one.

If appeals are constantly happening, however, then obviously you have a non-functioning leadership team and something needs to change.

7. Do retros together to spot problems early

As with working agreements, retrospectives are not only useful for your team. Do monthly retros as a leadership triumvirate as well. Given the inevitable craziness of manager calendars, book them in advance and try to hold them sacred.

8. Sit together

If you are in the same location, the heads of all three groups should sit together, just as your cross-functional teams should sit together.

9. Be generous

Depending on current priorities, product, design and engineering should each have different times in the driver’s seat. If egos or selfishness dominates at the leadership level, you get a disfunctional organization.

10. And the blunt truth…

If there isn’t mutual respect and trust, someone has to go. Period.

(Part 3 is on interviewing PMs)