6 ms·

PM and EM Rules of Engagement

126 points by dpeck 5y ago

pdonis 5y ago
Note to the author of this article: whatever your site is doing to make my browser's title bar keep switching its text every second, please make it stop. I stopped reading and closed the tab because it was so annoying.
- humbledrone 5y ago
  For me, the "instant back button" moment was the little pop-up at the bottom of the screen that played a loud chime sound. I don't care if the article contains the cure for cancer -- the moment you get in my face like that I'm gone and not coming back.
  - pdonis 5y ago
    > For me, the "instant back button" moment was the little pop-up at the bottom of the screen that played a loud chime sound. I normally have my sound muted, precisely to avoid such nuisances. But this site shows why even that strategy is not always enough.
rjzzleep 5y ago
Basically most of the article revolves around the question of who's responsibility things are and who's authority it is to make decisions to what extent. Feature creep, overstretched budgets, technical debt etc. are all direct results of the competency of these people and the authority at which people are allowed to say no. One thing that the article glosses over is that this is much easier to do when the PM has a deep engineering understanding, and the EM has product understanding. But ultimately there are a lot of conflict potentials with the proposals in the article, specifically because the authorities don't seem to be clear. Though there may be internal segment details that we don't know about from the article that may alleviate these issues. E.g. hiring practices or other things.
- xcambar 5y ago
  The harsh truth: there's too much in this position to be handled by a single person. Ideally, you'd want a single person with a great tech background, solid product understanding and all the additional soft skills in between. These people, should they exist, are too few for a whole industry. I liked the article exactly because it found the sweet spot with joint accountability and separate ownership. Both will learn along the way a little bit of the skills of the other while partnering.
  - htrp 5y ago
    > These people, should they exist, are too few for a whole industry. I believe these people are called purple unicorns.....
- sirius87 5y ago
  > PM has a deep engineering understanding Amen. I've worked at a startup where the barrier to entry for a PM role was either low (in my perception) or they were allowed to get better at their job as the project progressed. Features were conjured up only to be canned after it was baked into the product and higher-ups shot things down. The codebase was a total mess. On the flip side, I've found experienced QA folks wanting to move up the corporate hierarchy by upskilling into PM roles a pleasure to work with, especially when it came to setting expectations upstream and estimating timelines.
mavelikara 5y ago
I have found that many EM/PM pairings are not balanced. The M in both names means different things - the PM manages is the product scope, the EM manages teams. Thus, most PMs are ICs, and EMs are people managers. This, in turn, causes the experience needed to become a PM or EM to differ. Very few organizations would hire a new grad into an "Associate People Manager" job - it is implied that one needs some experience in the industry before one can be entrusted with people management duties. But many new grads step into "Associate Product Manager" roles, where they are on a career track to own business strategy. This is, IMO, a bad trend in PM orgs. This imbalance in industry experience is often the root cause of tension between many PM/EM pairings, particularly in B2B space.
- _n_b_ 5y ago
  Interesting data point. At my (non-software-focused) engineering firms, all product managers are capital-M managers and most come with signifiant hands-on experience within the business—-they often significantly influence very large product strategy decisions than can have 15+ year impacts—-so are expected to be leaders on both the technical and business aspects. The setup is clearly a lot easier to swing in a bigcorp with relatively low turnover and relatively high-value products, rather than a smaller company without a deep talent pool and sufficient span of control for a manager-level product manager... but I think it’s a better model all the same. *PdM, incidentally, to differentiate them from project managers who are the PMs
  - waterfowl 5y ago
    who do they manage? or what is meant by "capital-M managers"? If they're managing junior PMs(or product management folks with a lowlier title, analysts, etc?) wouldn't that mean you have non capital-M people "doing product management" if not officially PMs?
- ianai 5y ago
  That sounds like an argument for requiring some experience in the industry before the PM role? But at least the PMP does require prior experience.
alrs 5y ago
Don't know much about Segment, but whatever they're up to bought them a total block in uMatrix so this is un-readable in my browser.
- mrgreenfur 5y ago
  They are a CDP, customer data platform, that tracks user behavior so it can be distributed to various mar tech and analytics tools. Its a reasonable product and on most ad block lists for its tracking.
makeitdouble 5y ago
These two bits when combined are to me the most at odds with reality: > Although they should jointly discuss the various trade-offs involved in a decision, each decision has a single owner. > When? > Owned by the EM (based on trade-off conversations with the PM). Basically the EM is responsible of delivery date, but doesn't have authority on the business side to adjust for potential timing issues. For instance the PM/EM can agree on a first timeline, but the EM won't be decide to pay for more time in exchange for more business return, or lower running cost. Or to short a project that takes more resources than the expected return. My point is separating responsibility for cost, resources, time, and return is a losing proposition in most settings, as they are intertwined.
- jon-wood 5y ago
  One of the key points in the article is that this is a partnership - while the EM has final say on the timeline, that's going to be influenced by the PM's product requirements. Maybe the PM says that the timeline quoted isn't going to work, in that case the EM is going to work with them to change the scope in order to better fit the timeline.
simonswords82 5y ago
Does anybody have any experience on how to balance the input of a slightly different pairing...product manager and project manager?
- parkersweb 5y ago
  I've seen that happen - more as PO (product owner) and PM. In those cases PO owns the 'Why' and 'What', PM owns the 'When' and liaises with EM for the 'Who'; EM owns the "How".
- dpeck 5y ago
  In my experience there is only a need for Project Managers when multiple groups that span multiple functions (development, marketing, customer support, etc) are needed to deliver something and they need to work on different cadences. The Project Manager can act as a transmission of sorts to make sure deliverables happen at roughly the right times to not block each other. Outside of those circumstances I have never seen any value in it. For software only initiatives the entire project management function is little more than ignoring Jira boards and calling meetings with lots of people to “check on status”. If you have anyone doing this then your organization is in a bad place and needs to be set right, it will not get healthier.
captn3m0 5y ago
URL if you have segment blocked: https://archive.is/HOV30 https://archive.is/HOV30
jacobr 5y ago
Are responsibilities really this neatly separated? I’ve worked in both huge, small and medium sized Scandinavian companies and apart from EM and PM, the following people would also have a say in answering these questions: * designers * QA * tech lead * senior developers * delivery lead Is this because of my biased experience with consensus culture, or is the article a simplification? Also, an Engineering Manager would typically decide which technical experts are suitable for a given task, but would not be the one deciding which tech to use, apart from budget constraints.
- kelnos 5y ago
  I think the assumption here is that at least the tech lead and senior developers, and possibly delivery lead, report to the EM, so the EM can speak for them (hopefully after consulting them, of course). QA sometimes also reports to engineering, or may not even exist at all. Designers are, unfortunately, often overlooked when making schedules... But I think the simplification comes from the idea that the EM owns those decisions, even if the EM doesn't make them in isolation.
- deleted 5y ago
  [deleted]
- parkersweb 5y ago
  I'd always expect EM to be drawing experience from tech lead / senior developers. EM can sometimes be a facilitator (rather than developer) to ensure that right people are tasked to answer the How, When & Who. I wonder how other people see design fitting into that mix? The fact that EM is recognised - but somehow "Design Management" (research, prototyping, design vision, user experience etc) isn't feels like it too often leads to an imbalance in the way that products are built.
- codingdave 5y ago
  The article felt accurate to me - The PM and EM absolutely make the decisions. If they are good at their job, yes, of course they listen to everyone else before making those decisions. Failing to let everyone have their say would lead to not only a poor product, but a poor team. But at the end of the day, it is not a consensus, it is the PM/EM listening, researching, thinking, and then deciding. FWIW, the best teams I've been on have been mostly driven by consensus anyway - if everyone is in consensus, the PM has an easy decision, so that is how it happens as often as not. But a good PM will know when to strive for that solution, and when to just make their own call.
deleted 5y ago
[deleted]
option_greek 5y ago
This assumes equal competence and maturity levels on both roles. However often this isn't the case at all because there usually is a well defined career progression to EM role while PM can come from any set of roles (Business analyst, operations, project management, sales etc). The best PMs I have seen come from business/operations and bring valuable domain experience to the table. The worst ones come from Project management/ scrum master/fresh MBA grads etc where there is constant chip on the shoulder mentality to ensure EM/devs don't encroach on their decisions. Even though the article highlights the 'who' as contentious, in reality even 'what' can be equally contentious when the PMs don't bring enough customer or domain understanding to the equation.
- eatonphil 5y ago
  The best PMs I've worked with were engineers 10 years ago. While some with this background may be insufferable on the "how", the best PMs I've worked with don't do that. Paradoxically these PMs just never think about implementation and do think seriously about the product on the whole and about P&L. The worst PMs I've seen were from business/ops side, they never looked for a whole picture they just focused on individual features and as a result constructed a completely incoherent product. Of course a good PM can probably come from any background just wanted to share my different experience from yours.
  - dpeck 5y ago
    I think the key is that they come from A background. Few, if any, people have the people skills, technical know how, and domain knowledge to be a PM early in their career. Instead we diluted the PM role so much to allow new grads to have a place to go, and so that PM leadership could increase their headcount, and now we have engineering managers having to manage their product counterparts because they lack the experience to manage themselves.
motohagiography 5y ago
Seeing this division of PM:why, what, vs. EM:how, when, and who is vincidating, but in multiple organizations, I have never met an EM who did not want to be a PM (n~=20), and this misalignment created friction. PM envy is a real thing. However, it's because of a lack of distance between the skills in the EM/PM pairing. The successful pairs I've seen, there was no threat to the skills of the other. A non-technical PM who is content to take the EM's technical views at face value and takes incoming flak on behalf of them, and an EM who recognizes the complexity of the multiparty dynamic of sales, board/investors, customers, and finance, and defers on those issues - together, these are very distant and so they work together in a complementary way. Obviously it's more nuanced, but the complementary difference was key. Where the PM is an architect with skills (my own conceit), and the EM thinks the tools they have for solving problems can also be applied to managing complex dynamics, the overlap is going to make bad neighbours. You need real complementary skill diversity, because if one thinks they are too similar, it's going to be a hyper-personalized war for their percieved security, and the whole thing goes bonkers. Negative team conflict is essentially "mimetic violence," to use the Girard/Danco framework. The best EMs I've seen loved the tech problems they were solving and really liked leveraging people to scale teams to solve them, and found that satisfying. IMO, an EM who doesn't get excited at how cool their stuff is is a liability. The best PMs I've seen both knew and genuinely liked their customers, albeit with benevolent boundaries. One guy I saw was like this happy monk who listened and relieved suffering with new features. Whatever the unicorn he's now at pays him is not nearly enough. They have an invisible, energizing effect. If you are in a PM/EM conflict, consider whether you think you can do the other person's job, and if you think you can, not only are you wrong, but you are likely at least half of the problem. However, the solution is to recognize the other person doing something you can't (not telling them, rather, admitting it to yourself and your unintentional behaviour will just change). IMO, there is no point in talking it through, the conflict is based on your internally held beliefs about how similar you are, and the only way to resolve it is to adapt those beliefs with new consideration. Mentally treating what they do as a kind of alien magic can create enough breathing room because that exercise of creating that conceptual distance is the opposite of holding territory and security. If you literally can do their jobs, you are a mismatched pair, and if you are an exec creating these pairings, consider reassigning pairs that are too close in skills and lack complimentary properties.
jollybean 5y ago
Except that the 'What and Why' irrevocably depend on 'When'. They are functions of each other. That's the hard part. If you're building something with predictable timelines, it's another story but often in tech it's not.
marcinzm 5y ago
The worst PMs I've seen are one that take the Why/What ownership to mean they are supposed to be a mini-dictator whose sole vision drives the roadmap. The best ones combine together all the feedback from everyone (including engineers) into a cohesive whole.

126 points by dpeck 5y ago

Note to the author of this article: whatever your site is doing to make my browser's title bar keep switching its text every second, please make it stop. I stopped reading and closed the tab because it was so annoying.

humbledrone 5y ago
For me, the "instant back button" moment was the little pop-up at the bottom of the screen that played a loud chime sound. I don't care if the article contains the cure for cancer -- the moment you get in my face like that I'm gone and not coming back.
- pdonis 5y ago
  > For me, the "instant back button" moment was the little pop-up at the bottom of the screen that played a loud chime sound. I normally have my sound muted, precisely to avoid such nuisances. But this site shows why even that strategy is not always enough.

rjzzleep 5y ago

Basically most of the article revolves around the question of who's responsibility things are and who's authority it is to make decisions to what extent. Feature creep, overstretched budgets, technical debt etc. are all direct results of the competency of these people and the authority at which people are allowed to say no. One thing that the article glosses over is that this is much easier to do when the PM has a deep engineering understanding, and the EM has product understanding. But ultimately there are a lot of conflict potentials with the proposals in the article, specifically because the authorities don't seem to be clear. Though there may be internal segment details that we don't know about from the article that may alleviate these issues. E.g. hiring practices or other things.

xcambar 5y ago
The harsh truth: there's too much in this position to be handled by a single person. Ideally, you'd want a single person with a great tech background, solid product understanding and all the additional soft skills in between. These people, should they exist, are too few for a whole industry. I liked the article exactly because it found the sweet spot with joint accountability and separate ownership. Both will learn along the way a little bit of the skills of the other while partnering.
- htrp 5y ago
  > These people, should they exist, are too few for a whole industry. I believe these people are called purple unicorns.....
sirius87 5y ago
> PM has a deep engineering understanding Amen. I've worked at a startup where the barrier to entry for a PM role was either low (in my perception) or they were allowed to get better at their job as the project progressed. Features were conjured up only to be canned after it was baked into the product and higher-ups shot things down. The codebase was a total mess. On the flip side, I've found experienced QA folks wanting to move up the corporate hierarchy by upskilling into PM roles a pleasure to work with, especially when it came to setting expectations upstream and estimating timelines.

mavelikara 5y ago

I have found that many EM/PM pairings are not balanced. The M in both names means different things - the PM manages is the product scope, the EM manages teams. Thus, most PMs are ICs, and EMs are people managers. This, in turn, causes the experience needed to become a PM or EM to differ. Very few organizations would hire a new grad into an "Associate People Manager" job - it is implied that one needs some experience in the industry before one can be entrusted with people management duties. But many new grads step into "Associate Product Manager" roles, where they are on a career track to own business strategy. This is, IMO, a bad trend in PM orgs. This imbalance in industry experience is often the root cause of tension between many PM/EM pairings, particularly in B2B space.

_n_b_ 5y ago
Interesting data point. At my (non-software-focused) engineering firms, all product managers are capital-M managers and most come with signifiant hands-on experience within the business—-they often significantly influence very large product strategy decisions than can have 15+ year impacts—-so are expected to be leaders on both the technical and business aspects. The setup is clearly a lot easier to swing in a bigcorp with relatively low turnover and relatively high-value products, rather than a smaller company without a deep talent pool and sufficient span of control for a manager-level product manager... but I think it’s a better model all the same. *PdM, incidentally, to differentiate them from project managers who are the PMs
- waterfowl 5y ago
  who do they manage? or what is meant by "capital-M managers"? If they're managing junior PMs(or product management folks with a lowlier title, analysts, etc?) wouldn't that mean you have non capital-M people "doing product management" if not officially PMs?
ianai 5y ago
That sounds like an argument for requiring some experience in the industry before the PM role? But at least the PMP does require prior experience.

alrs 5y ago

Don't know much about Segment, but whatever they're up to bought them a total block in uMatrix so this is un-readable in my browser.

mrgreenfur 5y ago
They are a CDP, customer data platform, that tracks user behavior so it can be distributed to various mar tech and analytics tools. Its a reasonable product and on most ad block lists for its tracking.

makeitdouble 5y ago

These two bits when combined are to me the most at odds with reality: > Although they should jointly discuss the various trade-offs involved in a decision, each decision has a single owner. > When? > Owned by the EM (based on trade-off conversations with the PM). Basically the EM is responsible of delivery date, but doesn't have authority on the business side to adjust for potential timing issues. For instance the PM/EM can agree on a first timeline, but the EM won't be decide to pay for more time in exchange for more business return, or lower running cost. Or to short a project that takes more resources than the expected return. My point is separating responsibility for cost, resources, time, and return is a losing proposition in most settings, as they are intertwined.

jon-wood 5y ago
One of the key points in the article is that this is a partnership - while the EM has final say on the timeline, that's going to be influenced by the PM's product requirements. Maybe the PM says that the timeline quoted isn't going to work, in that case the EM is going to work with them to change the scope in order to better fit the timeline.

simonswords82 5y ago

Does anybody have any experience on how to balance the input of a slightly different pairing...product manager and project manager?

parkersweb 5y ago
I've seen that happen - more as PO (product owner) and PM. In those cases PO owns the 'Why' and 'What', PM owns the 'When' and liaises with EM for the 'Who'; EM owns the "How".
dpeck 5y ago
In my experience there is only a need for Project Managers when multiple groups that span multiple functions (development, marketing, customer support, etc) are needed to deliver something and they need to work on different cadences. The Project Manager can act as a transmission of sorts to make sure deliverables happen at roughly the right times to not block each other. Outside of those circumstances I have never seen any value in it. For software only initiatives the entire project management function is little more than ignoring Jira boards and calling meetings with lots of people to “check on status”. If you have anyone doing this then your organization is in a bad place and needs to be set right, it will not get healthier.

captn3m0 5y ago

URL if you have segment blocked: https://archive.is/HOV30 https://archive.is/HOV30

jacobr 5y ago

Are responsibilities really this neatly separated? I’ve worked in both huge, small and medium sized Scandinavian companies and apart from EM and PM, the following people would also have a say in answering these questions: * designers * QA * tech lead * senior developers * delivery lead Is this because of my biased experience with consensus culture, or is the article a simplification? Also, an Engineering Manager would typically decide which technical experts are suitable for a given task, but would not be the one deciding which tech to use, apart from budget constraints.

kelnos 5y ago
I think the assumption here is that at least the tech lead and senior developers, and possibly delivery lead, report to the EM, so the EM can speak for them (hopefully after consulting them, of course). QA sometimes also reports to engineering, or may not even exist at all. Designers are, unfortunately, often overlooked when making schedules... But I think the simplification comes from the idea that the EM owns those decisions, even if the EM doesn't make them in isolation.
deleted 5y ago
[deleted]
parkersweb 5y ago
I'd always expect EM to be drawing experience from tech lead / senior developers. EM can sometimes be a facilitator (rather than developer) to ensure that right people are tasked to answer the How, When & Who. I wonder how other people see design fitting into that mix? The fact that EM is recognised - but somehow "Design Management" (research, prototyping, design vision, user experience etc) isn't feels like it too often leads to an imbalance in the way that products are built.
codingdave 5y ago
The article felt accurate to me - The PM and EM absolutely make the decisions. If they are good at their job, yes, of course they listen to everyone else before making those decisions. Failing to let everyone have their say would lead to not only a poor product, but a poor team. But at the end of the day, it is not a consensus, it is the PM/EM listening, researching, thinking, and then deciding. FWIW, the best teams I've been on have been mostly driven by consensus anyway - if everyone is in consensus, the PM has an easy decision, so that is how it happens as often as not. But a good PM will know when to strive for that solution, and when to just make their own call.

deleted 5y ago

[deleted]

option_greek 5y ago

This assumes equal competence and maturity levels on both roles. However often this isn't the case at all because there usually is a well defined career progression to EM role while PM can come from any set of roles (Business analyst, operations, project management, sales etc). The best PMs I have seen come from business/operations and bring valuable domain experience to the table. The worst ones come from Project management/ scrum master/fresh MBA grads etc where there is constant chip on the shoulder mentality to ensure EM/devs don't encroach on their decisions. Even though the article highlights the 'who' as contentious, in reality even 'what' can be equally contentious when the PMs don't bring enough customer or domain understanding to the equation.

eatonphil 5y ago
The best PMs I've worked with were engineers 10 years ago. While some with this background may be insufferable on the "how", the best PMs I've worked with don't do that. Paradoxically these PMs just never think about implementation and do think seriously about the product on the whole and about P&L. The worst PMs I've seen were from business/ops side, they never looked for a whole picture they just focused on individual features and as a result constructed a completely incoherent product. Of course a good PM can probably come from any background just wanted to share my different experience from yours.
- dpeck 5y ago
  I think the key is that they come from A background. Few, if any, people have the people skills, technical know how, and domain knowledge to be a PM early in their career. Instead we diluted the PM role so much to allow new grads to have a place to go, and so that PM leadership could increase their headcount, and now we have engineering managers having to manage their product counterparts because they lack the experience to manage themselves.

motohagiography 5y ago

Seeing this division of PM:why, what, vs. EM:how, when, and who is vincidating, but in multiple organizations, I have never met an EM who did not want to be a PM (n~=20), and this misalignment created friction. PM envy is a real thing. However, it's because of a lack of distance between the skills in the EM/PM pairing. The successful pairs I've seen, there was no threat to the skills of the other. A non-technical PM who is content to take the EM's technical views at face value and takes incoming flak on behalf of them, and an EM who recognizes the complexity of the multiparty dynamic of sales, board/investors, customers, and finance, and defers on those issues - together, these are very distant and so they work together in a complementary way. Obviously it's more nuanced, but the complementary difference was key. Where the PM is an architect with skills (my own conceit), and the EM thinks the tools they have for solving problems can also be applied to managing complex dynamics, the overlap is going to make bad neighbours. You need real complementary skill diversity, because if one thinks they are too similar, it's going to be a hyper-personalized war for their percieved security, and the whole thing goes bonkers. Negative team conflict is essentially "mimetic violence," to use the Girard/Danco framework. The best EMs I've seen loved the tech problems they were solving and really liked leveraging people to scale teams to solve them, and found that satisfying. IMO, an EM who doesn't get excited at how cool their stuff is is a liability. The best PMs I've seen both knew and genuinely liked their customers, albeit with benevolent boundaries. One guy I saw was like this happy monk who listened and relieved suffering with new features. Whatever the unicorn he's now at pays him is not nearly enough. They have an invisible, energizing effect. If you are in a PM/EM conflict, consider whether you think you can do the other person's job, and if you think you can, not only are you wrong, but you are likely at least half of the problem. However, the solution is to recognize the other person doing something you can't (not telling them, rather, admitting it to yourself and your unintentional behaviour will just change). IMO, there is no point in talking it through, the conflict is based on your internally held beliefs about how similar you are, and the only way to resolve it is to adapt those beliefs with new consideration. Mentally treating what they do as a kind of alien magic can create enough breathing room because that exercise of creating that conceptual distance is the opposite of holding territory and security. If you literally can do their jobs, you are a mismatched pair, and if you are an exec creating these pairings, consider reassigning pairs that are too close in skills and lack complimentary properties.

jollybean 5y ago

Except that the 'What and Why' irrevocably depend on 'When'. They are functions of each other. That's the hard part. If you're building something with predictable timelines, it's another story but often in tech it's not.

marcinzm 5y ago

The worst PMs I've seen are one that take the Why/What ownership to mean they are supposed to be a mini-dictator whose sole vision drives the roadmap. The best ones combine together all the feedback from everyone (including engineers) into a cohesive whole.