We’ve talked about How To Be A PM That Engineers Don’t Hate, now let’s talk about it in the other direction.
To be an engineer that PMs don’t hate:
- Be responsible with the power of shipping code
- Don’t make Product Management your QA team or your project manager
- Don’t gang up on PM (they’re outnumbered on teams)
- Don’t mistake technical knowledge for intelligence (don’t be an asshole)
- Explain the value of tech debt in a way that is easy to understand
Be responsible with the power of shipping code
Engineers have one thing that creates a very unique power balance: they ship the code. Engineers can get some stuff done without PM or design, but PM and design cannot realize business value via product without engineers building it.
The code-shipping dependency is a lot of power for engineers to wield. When this power is leveraged and abused, things go wrong. The most simple version of bad behavior in this regard is being lazy and making PMs ask you for stuff - updates, information, opinions. It gets worse if you’re ungracious about answering. The absolute worst version of this looks like parents and teenagers - PMs asking for information and engineers acting like that’s annoying and bothersome. Please don’t do that.
Engineers, to be a good partner to PM:
- Don’t make PMs hound you for information. Be proactive.
- When PMs do ask you for information, answer promptly and graciously (and if you’re experienced, teach them how to ask questions as efficiently and asynchronously as possible).
- Avoid anything that looks like “I didn’t get my way so I’m not building the thing.” Disagree and commit if needed, but if you ever go on strike you’ll fracture relationships beyond repair.
Don’t make Product Management your QA team or Project Manager
The PM role can sometimes have ambiguous borders; just like engineering managers, they’re often solving various types of problems - whatever the team needs. This ambiguity can lead to scope creep in responsibilities, often in the least glamorous places. As a responsible engineer and good partner, you need to avoid this happening.
A common area for things to get messy is QA. In many agile teams, PMs end up doing UAT or requirements checking before tickets go live. Sometimes, teams can slowly move towards a state where UAT is finding more and more bugs (instead of just checking requirements). A common way this happens is if the engineering team is much less tenured than the PM, and the PM knows how to test better than the engineers. In any case, PM acting as QA is not a healthy state. If PM is catching lots of bugs in UAT, engineering teams need to re-evaluate their QA strategy and fix the problem ASAP.
Another place that engineers can over-rely on PM is in project management. Because PMs are most active at the start and end of projects - handing the steering wheel to engineers to execute and picking it back up when code is complete to deliver downstream - there can often be blurriness about how much PMs should be project managing in the middle. The TLDR here is that PMs should not be running all project meetings. Engineering managers, IC project leads, or tech leads need to be managing engineering execution, not PMs.
Don’t team up on PM (they’re outnumbered on teams)
PMs (and designers) are almost always one-offs in teams that have multiple engineers. This is a power dynamic that needs to be understood: do not team up on PMs, and deeply understand that this one-to-many setup makes their job different and difficult in unique ways. As always with power balances, just be gracious.
Don’t mistake technical knowledge for intelligence (don’t be an asshole)
One of the cardinal sins of engineering collaboration is assuming technical knowledge is tantamount to overall intelligence. Sure, your PM might not understand the heap debugging you did yesterday, but don’t let that go to your head. Don’t be a jerk in general, but just be wary of letting technical prowess nudge you towards thinking you’re smarter than anyone. If you need a hint on how to humble yourself, just imagine you have to explain your product’s competitive gaps, partner landscape, and recent revenue trajectory via powerpoint in a meeting with the exec team, like PMs often do.
Explain the value of tech debt in a way that is easy to understand
One of the niche places that PMs and engineers can butt heads is tech debt prioritization. Especially when there aren’t artificial proportions that are allotted to each, PMs often want to understand the why of tech debt, and engineers can sometimes fall back on “you just have to be an engineer to get it”. More often than not, that explanation says more about the engineer’s understanding of the tech debt than the PM’s understanding. Tech debt prioritization should be compelling, obvious, and transparent - if it’s not, you risk diving into a rabbit hole of code refactoring without actually focusing on why it matters.
Summary
Be an engineer that PMs don’t hate. Know that there are implicit power dynamics that should be managed graciously, including:
- The power of shipping code
- The power of numbers (one to many team topologies)
So, be a good partner, don’t let your PM start doing QA, explain your tech debt justification, be well and prosper.