4 ms·

Feels like it badly needs the reciprocal "How to be a PM that engineers don’t hate". Otherwise it comes across as "Ten things you grunts need to do to make my c

by smcin 3y ago

Feels like it badly needs the reciprocal "How to be a PM that engineers don’t hate". Otherwise it comes across as "Ten things you grunts need to do to make my career go better". The OP makes some pretty big generalizations: > 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... 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. Well that's one possibility, but I've never seen it in reality, let alone call it common. Another strong possibility is that the team (PM in particular) didn't spend enough time thinking through use-cases and writing acceptance tickets. And/or that whoever's supposed to be communicating with the customer isn't doing that well. Or indeed that the customer themselves doesn't understand their needs well (in which case quickly getting them an MVP without much acceptance testing is entirely the right thing to do, then iterating - but ideally that should have been budgeted up front, which would be on the PM as much as anybody - and more so if they're "more tenured"). So, less blamespreading, more the team rolling their sleeves up. Especially if the PM really aspires to be a "partner" to developers (as they say elsewhere). And btw if the "engineering team is much less tenured than the PM" is a recurring pattern, then that suggests trying to scale too fast, or antipatterns in hiring/ development/ budget/ management/ retention/ compensation (for example any developer with half a clue in that org would eventually either aim to get promoted/ jump ship into PM/ quit). The solution isn't always to whip the developers harder. It may be about mismatches in management/ budget/ incentives/ KPI.

crm 3y ago
Looks like the OP has you covered ! https://staysaasy.com/product/2023/03/12/pm-engineers-dont-hate.html https://staysaasy.com/product/2023/03/12/pm-engineers-dont-h...
- smcin 3y ago
  Not really, none of the second article's philosophy seems to show up in this article: "Hold Yourself Accountable/ Help With the Dirty Work/ Be an Engineering Management Ally/ Be a World Class Copilot" seems to conflict with their scenario "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". Also as commented, the OP makes too many implicit generalized assumptions about the org: that PM and developers report to a similar management chain (that's often not the case, depends on the org) or at least is aligned with compatible incentives. Their throwaway remark "if the engineering team is much less tenured than the PM" and the lack of inquiring about why that scenario might have arisen makes you wonder, too.
  - mathgeek 3y ago
    Sounds like a blog post you should write to share your own experience, since you disagree with OP.
    - dventimi 3y ago
      Or add a comment to HN, which is what they just did
gipp 3y ago
> Feels like it badly needs the reciprocal "How to be a PM that engineers don’t hate". The link to that exact article is literally the first sentence of this one.
- hacym 3y ago
  Reading the title and commenting without context strikes again!
rockemsockem 3y ago
How is this the top comment when it's literally the first thing in the post. Did you read it?
972811 3y ago
it's fairly embarrassing that your suggestion is literally the first sentence in the article
- smcin 3y ago
  No it's not, because that other article absolutely isn't reciprocal, for all the reasons I had already listed above [0], 14 hours before you even wrote this. If you had read the other article, you'd see it flatly contradicts this article. Over there the OP trots out rhetoric like "Hold Yourself Accountable/ Help With the Dirty Work/ Be an Engineering Management Ally/ Be a World Class Copilot", but here moans about (hypothetically legitimate) scenarios where the PM may temporarily have to shoulder a lot of the QA burden (or push back on the customer rather than blame developers, if the customer doesn't understand their own use-case). Conversely in this article the OP makes cryptic hand-waves towards "As always with power balances, just be gracious... Know that there are implicit power dynamics that should be managed graciously... So, be a good partner...", but what they write feels like they only view it as a one-way partnership, and makes it sound like they don't care if the developers are getting the short end of the stick. Or, they're trying to make a faulty generalization from their personal experience to other orgs where developers and PMs report to different chains and have very different incentives, as again other people here had already commented [1] before your post. Your comment isn't constructive, and it intentionally misrepresents what I had clearly already written above half a day before you posted it. Please don't do that again. [2] And I didn't make a "suggestion", I critiqued the OP's absence of having actually written something genuinely reciprocal like they said they had. [0]: https://news.ycombinator.com/item?id=36466224 https://news.ycombinator.com/item?id=36466224 [1]: https://news.ycombinator.com/item?id=36467921 https://news.ycombinator.com/item?id=36467921 [2]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

by smcin 3y ago

crm 3y ago

Looks like the OP has you covered ! https://staysaasy.com/product/2023/03/12/pm-engineers-dont-hate.html https://staysaasy.com/product/2023/03/12/pm-engineers-dont-h...

smcin 3y ago
Not really, none of the second article's philosophy seems to show up in this article: "Hold Yourself Accountable/ Help With the Dirty Work/ Be an Engineering Management Ally/ Be a World Class Copilot" seems to conflict with their scenario "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". Also as commented, the OP makes too many implicit generalized assumptions about the org: that PM and developers report to a similar management chain (that's often not the case, depends on the org) or at least is aligned with compatible incentives. Their throwaway remark "if the engineering team is much less tenured than the PM" and the lack of inquiring about why that scenario might have arisen makes you wonder, too.
- mathgeek 3y ago
  Sounds like a blog post you should write to share your own experience, since you disagree with OP.
  - dventimi 3y ago
    Or add a comment to HN, which is what they just did

gipp 3y ago

> Feels like it badly needs the reciprocal "How to be a PM that engineers don’t hate". The link to that exact article is literally the first sentence of this one.

hacym 3y ago
Reading the title and commenting without context strikes again!

rockemsockem 3y ago

How is this the top comment when it's literally the first thing in the post. Did you read it?

972811 3y ago

it's fairly embarrassing that your suggestion is literally the first sentence in the article

smcin 3y ago
No it's not, because that other article absolutely isn't reciprocal, for all the reasons I had already listed above [0], 14 hours before you even wrote this. If you had read the other article, you'd see it flatly contradicts this article. Over there the OP trots out rhetoric like "Hold Yourself Accountable/ Help With the Dirty Work/ Be an Engineering Management Ally/ Be a World Class Copilot", but here moans about (hypothetically legitimate) scenarios where the PM may temporarily have to shoulder a lot of the QA burden (or push back on the customer rather than blame developers, if the customer doesn't understand their own use-case). Conversely in this article the OP makes cryptic hand-waves towards "As always with power balances, just be gracious... Know that there are implicit power dynamics that should be managed graciously... So, be a good partner...", but what they write feels like they only view it as a one-way partnership, and makes it sound like they don't care if the developers are getting the short end of the stick. Or, they're trying to make a faulty generalization from their personal experience to other orgs where developers and PMs report to different chains and have very different incentives, as again other people here had already commented [1] before your post. Your comment isn't constructive, and it intentionally misrepresents what I had clearly already written above half a day before you posted it. Please don't do that again. [2] And I didn't make a "suggestion", I critiqued the OP's absence of having actually written something genuinely reciprocal like they said they had. [0]: https://news.ycombinator.com/item?id=36466224 https://news.ycombinator.com/item?id=36466224 [1]: https://news.ycombinator.com/item?id=36467921 https://news.ycombinator.com/item?id=36467921 [2]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html