When your PM drives you crazy
Mastering the toughest partnership in tech
I’ve worked with 8 Product Managers in the last decade, and the relationship usually played out in 1 of 3 ways:
PM-led team - The PM was ‘giving orders’, and I was not asked for input.
Engineering-led team - I had the final say, and was always able to push my agenda.
A true partnership - the PM understood the technical side, and took part in the product decisions.
A true partnership is damn hard to achieve - I succeeded only twice so far…
Today I’ll cover:
How a broken relationship looks like from the inside
What can you do about it
Tips from Product Management Thought Leaders
Many thanks to John Cutler and Aakash Gupta for sharing their thoughts!
How an imbalance looks like
An imbalanced relationship happens when one side is ‘stronger’ than the other. It can happen for different reasons:
Years of experience - 10-year-PM > first-time EM
Tenure in the company - 4-year-tenure-PM > 1-year-tenure-EM
Relationships - A founding engineer who is a friend of the CEO > an outside PM hire.
Different personalities, company cultures, and tons of other factors.
In the end, the most common result is 1 of 2:
A PM-led team
I’ve been in 3 such teams earlier in my career. In one of them I’ve been for 2 years, and it looked like this:
The PM talked to the customers alone.
She talked to the internal stakeholders alone.
She sat with her manager, built a roadmap, and told me what we would be working on next.
She told me how long it should take (!)
The results were happy customers (she was good at her job), happy stakeholders, and a frustrated engineering team.
The real problems surfaced only after a while:
People were burning out.
Nobody inside the team knew WHY we were building things. We couldn’t anticipate what would happen in the future, so we wasted tons of time because we prepared for the wrong scenarios.
Our codebase was a mess. No tests, very shallow code reviews, and quick and dirty solutions.
You may think it’s easy to fix. I could just insist on more time and higher standards, right?
People who’ve been in such a situation know the reality. When the PM is the final decision maker, it’s very hard to resist.
You will hear things such as: “This one is really urgent, let’s add the tests later, ok?”. Or “Just make it work in 2-3 days, we’ll have time to refactor it next time we touch this area”.
Yeah, right? Naive me.
After being burned, it led me to the other side of the scale:
An engineering-led team
Some of my recent relationships looked like this:
I set the technical priorities, scope, and estimates. The PM filled the rest of the roadmap with their initiatives.
I made the call on bug fixes and when to refactor. Sometimes I even decided on a whim to do a bigger refactor in the affected area, postponing ‘product’ work.
The team provided high-level designs and estimates that were never challenged.
This is NOT a dream scenario. It resulted in disappointed stakeholders and customers, which misses the whole point of engineering.
It’s very tempting to focus only on our own team, fighting for time to do things ‘in the right way’. I love Oren Ellenbogen’s quote on the topic (deeper take here):
Technical Debt is less scary than getting out of business - optimizing code or scaling up components that may or may not be used is sticking our heads in the sand.
You can’t be satisfied with beautiful code and scalable systems. If your PM is not up to the task - you have to take a deep breath and just do the PM work yourself.
A fake balanced team
In this type of ‘balanced’ relationship, each side has its own responsibilities. You get your tech debt time and the PM doesn’t bother you, and you don’t have a say in the product roadmap.
In the long run, it’ll fail.
A much better option is for every technical initiative to be on the roadmap, and have a product-related justification. A single roadmap for the team that both of you agree on.
Mirek Stanek shared practical tips on how to achieve that:
The ability of the PM to defend the technical work against their own manager is a huge force multiplier for the team. Otherwise, when your team will be called ‘slow’ in a meeting you don’t attend - the team will just be thrown under the bus.
Building a true partnership - tips for EMs
There IS a way to make that balance work. In my experience, it’s reached when both sides want to make the right decision for the company.
Not the team.
Not the customers.
Not other stakeholders.
The long-term success of the company.
Here is a quote I absolutely love from ‘Unreasonable Hospitality’, a book about how a restaurant manager created the best restaurant in the world:
In fine dining, there’s often a divide between those who cook and those who serve, with chefs usually winning the tug-of-war. I needed to know if Daniel [the chef he wanted to work with] would approach our partnership differently.
“I love hospitality,” I told him. “I want to make people happy. I don’t want to spend my life convincing you that what I do is as important as what you do. If the dining room doesn’t matter as much as the kitchen, I don’t want to start.”
Daniel understood. He’d worked at a European restaurant where the culinary team wasn’t allowed in the dining room, and another where the service team had to communicate with the kitchen through notes passed under a plexiglass window. That one hurt: the kitchen staff missed seeing guests’ faces light up with appreciation when the food arrived.
By the end of the night, we decided that our restaurant would be run by both sides, making decisions together for the good of the whole. A restaurant driven by the chef might focus on the food, and one by the restaurateur on service, but together, we could create something truly balanced.
The recipe for running an amazing engineering team is very similar to running the best restaurant - it has to be run by both sides, TOGETHER.
3 main tips on how to get there:
1. Help your PM become tech-oriented
If your PM doesn’t have a technical background, it’s up to you to bring him up to speed. Spend the time to explain the benefits of ‘purely technical’ tasks.
Use real examples, not technical jargon.
Instead of: “We need to create the backend in a new service instead of our Java monolith, there was a decision to start breaking it down to microservices”.
Go for: “We prefer to create the logic in a new service our team will own, instead of the shared code. This will allow us to move much faster while implementing future requirements, without being bogged down by other teams”.
2. Become a product-oriented EM
The first step is for you to care about the business:
When your CEO talks in an all-hands meeting - listen!
If you are in a public company - learn from the investor calls.
Try to join conversations with customers, and if you can, even visit them! A few months ago I drove 10 hours to visit some customers in Kansas, and it was one of the most important experiences I had in my 4 years at the company.
You don’t have the privilege to not care about the business!
When you understand the business and feel closer to the customers and other departments of the company, it’ll be much harder to bury your head in the sand and focus only on technical excellence.
It’s part of your job to learn about the Product Management world. How it works, what’s the best practices, and what are the main challenges.
It will allow you to sympathize with your PM, understand the reasons behind his decisions, but also challenge him and suggest new ways of doing things.
The most time-effective way to learn is to read product management newsletters:
I also highly suggest Marty Cagan’s books, and product growth newsletters such as Growth Unhinged by Kyle Poyar, Lenny’s Newsletter by Lenny Rachitsky and How They Grow by Jaryd Hermann.
3. Give the other side some freedom
You’ll never agree on everything.
Maybe there is a one-week-long refactor you want to do, but your PM doesn’t think is needed. Or your PM wants to release an urgent fix, and you don’t feel it justifies working after hours.
Here’s a golden tip for you (also from “Unreasonable Hospitality”) - use ‘It’s important for me’:
Sometimes, the only way to proceed in pursuit of a good partnership is to decide that whoever cares more about the issue can have their way. It wasn’t that I didn’t care about [ommited]… But it was more important to Daniel than it was to me.
There was an unwritten addition to this rule, which is that neither of us could abuse the “It’s important to me” card by pulling it too many times. Mostly, though, we found that the willingness of the other person to relinquish their own position helped to build trust between us.
Imagine the relief.
You challenge each other, and have heated discussions, but you know you always have a card to pull for what’s truly important for you.
Thoughts from experienced PMs
3 tips by John Cutler
Create a bubble - no matter how messy is your company, or how bad is the culture, together with your PM (and designer), you have a chance to your own bubble of excellence.
Your PM has some autonomy in their role, and a great relationship between you too might be enough to overcome many obstacles.Have empathy - you don't know how much pressure the PM is under. For you, it may be “Oops, we found out at the last moment we’ll need a couple more weeks”. Your PM is the one who needs to deal with the angry crowds.
Talk about responsibilities - it can be as simple as writing down all the possible responsibilities, and each side saying where on the EM<->PM graph it lies. You’ll be surprised by the differences of opinion...
Check out John’s article about such an exercise.
Aakash Gupta tips
A great EM takes most of the delivery and project management work off of the PM’s shoulders → A great PM accepts this and embraces it.
A great EM ensures all engineers understand the why and are able to join discovery → A great PM facilitates their inclusion.
A great EM takes all sprint planning and grooming responsibilities → A great PM loves this.
Thanks again to John Cutler and Aakash Gupta.
It was one of my longest articles, and a topic close to my heart. I would be very happy to hear your thoughts and tips on it!
Fantastic piece! A great PM makes life easier, a bad one makes it worse. Classic high valence role.
I've been at the true partnership and those are golden times. It helps if the PM has a bit of technical understanding and the tech lead has a bit of product understanding.