Introduction

Throughout my career, I’ve worked with quite a few product managers. However, it’s taken me quite a long time to understand how to form a good partnership with a PM as a developer, tech lead, and now engineering manager. In the past, I’ve had some bumpy relationships with PMs but I learned that if your relationship is not improving you have to reflect on what you can do from your end to improve the relationship.

These are some of the things I’ve learned in forming an effective product and engineering partnership over the years:

Understanding the basics of product management

The best way to alienate your team’s PM (vision, strategy) is to assume they’re a project manager (execution, tactics). Essentially the PM is supposed to be the voice of the customer (literally called “VoC” in product parlance). They should deeply understand the “problem space” of the customer and discover what opportunities for the company exist in this space.

Am I a trained PM? No. However, understanding the primary role of the PM in your team is a guaranteed way to build great rapport with them.

Other resources:

• Y Combinator | Michael Seibel - Building Product:: A great overview of building product in a startup

• Product Management Glossary:: A useful cheat sheet for those new to product management

• Lenny's Podcast | Christian Idiodi (SVPG) - The essence of product management: Lenny's Podcast is one of the best resources out there for startups and product management. I believe the insights could be useful for any role in a startup environment.

Accepting the fluidity of roles; treating project management as engineering

The most fruitful relationships I’ve had are ones where it’s mutually understood that everyone at some point wears multiple hats. Friction in teams is caused by a mismatch in the personnel allocated to that team and the amount of roles/jobs that the team needs to perform. As an engineer, you can help your PM and team in the realm of project management by:

• Defining the team’s SDLC, and thoroughly documenting it with explanations of the purpose of each step.

• Setting up CI/CD and automations to remove as much toil as possible from project management, like auto-assigning tickets and auto-transitioning tickets based on events like deploys or test failures.

• Helping with manually managing tickets when the automations inevitably get screwed up.

• Teaching your team about trunk-based development or whatever flavor of system version branch management you use so that everyone is on the same page about why decisions are made in the manner they are. Otherwise, you get a team where all the critical knowledge about how the system is delivered through a process is hoarded in one person’s brain (single point of failure) and then everyone else is in the dark and has no agency to make decisions on their own.

• Being able to split up tickets into appropriately sized chunks. Not too big, and not too small. Just the right amount of scope to move your system from one production state to the next. This requires some engineering wisdom and excellent written communication skills as you should be thinking about possible regressions, value vs effort, introduction of tech debt, etc.

The day-to-day execution of your SDLC is the cardiovascular system of your team, it drives everything and is a huge factor in the health of the team. Don’t ignore it, or pretend like project management is beneath you or unimportant.

As a tech lead or engineering manager, it is your responsibility to let go of your ego and set up everyone on your team for success

The most important skill set you have is your ability to transfer technical information in concise, plain, and understandable language. PMs don’t care about the academic intricacies of quantum glarbulation in massively distributed isosymmetric blarguation entropy chaos systems.

PMs sit in the intersection between the customer, technology, and the business. Sometimes PMs have engineering backgrounds, sometimes they are marketers or business analysts. If your PM lacks critical domain technical comprehension about some deeply complicated thing related to your team or product, you have to collaborate with them so that they have enough confidence to make decisions about the strategy of the product. This isn’t to say that your PM will be making technical discussions without you, nor that they need to have the same level of technical expertise as you; it’s a partnership, work together to find the appropriate level of balance in your team.