PM and EM Rules of Engagement(segment.com)
segment.com
PM and EM Rules of Engagement
https://segment.com/blog/product-manager-engineering-manager-rules-of-engagement/
38 comments
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
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
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?
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.
> This imbalance in industry experience is often the root cause of tension between many PM/EM pairings, particularly in B2B space.
This is an incredibly astute observation. Product management has become an incredibly hyped role which has seen a lot of growth. Similarly, there are been an explosion in supposed PM methodologies and tools which have yet to be proven. There has not been an opportunity for the profession to stabilize yet.
My observation is that a lot of junior people are coming in with little experience and are naturally using approaches which don't always make sense for the business. They don't really have the option to do anything else because they are too junior and don't have have a span of control to change all the things they need to (if they see the bigger picture.)
You find that they'll be endlessly churning smaller features which pisses off a bunch of your biggest advocates. The irony is that you may have folks in your support team who have a much more strategic view of your customer needs, but they not empowered to do anything while you have junior PMs who mean well, but can be eroding the experience.
This type of situation gets under the skin of engineers and they'll throw out statements like "why do we even have PMs?" Over time this can lead to attrition in the engineering team.
This is an incredibly astute observation. Product management has become an incredibly hyped role which has seen a lot of growth. Similarly, there are been an explosion in supposed PM methodologies and tools which have yet to be proven. There has not been an opportunity for the profession to stabilize yet.
My observation is that a lot of junior people are coming in with little experience and are naturally using approaches which don't always make sense for the business. They don't really have the option to do anything else because they are too junior and don't have have a span of control to change all the things they need to (if they see the bigger picture.)
You find that they'll be endlessly churning smaller features which pisses off a bunch of your biggest advocates. The irony is that you may have folks in your support team who have a much more strategic view of your customer needs, but they not empowered to do anything while you have junior PMs who mean well, but can be eroding the experience.
This type of situation gets under the skin of engineers and they'll throw out statements like "why do we even have PMs?" Over time this can lead to attrition in the engineering team.
[deleted]
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.
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.
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.
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.
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.
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:
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.
* designers
* QA
* tech lead
* senior developers
* delivery lead
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.
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.
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.
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.
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.
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.
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]
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.
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.
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.
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.
> These people, should they exist, are too few for a whole industry.
I believe these people are called purple unicorns.....
I believe these people are called purple unicorns.....
> 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.
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.
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.
> 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.
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.
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.
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.
> 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.
I normally have my sound muted, precisely to avoid such nuisances. But this site shows why even that strategy is not always enough.
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.
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.
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.
URL if you have segment blocked: https://archive.is/HOV30
[deleted]
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.
That's the hard part.
If you're building something with predictable timelines, it's another story but often in tech it's not.
Does anybody have any experience on how to balance the input of a slightly different pairing...product manager and project manager?
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".
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.
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.
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.
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.
This explains why I get along with my PMs so well. I have zero interest in dabbling in their domain, and am happy to just take care of the How/When/Who.
Newly minted PM here - very valuable comment for me.
In this case I’m so very glad to be almost completely clueless on the engineering. This is something that I thought was a big problem, but it might actually be the opposite. Thanks!
In this case I’m so very glad to be almost completely clueless on the engineering. This is something that I thought was a big problem, but it might actually be the opposite. Thanks!
This is a great comment. Thank you for taking the time to write it out. Spot on.
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.