PM and EM Rules of Engagement
segment.com
segment.com
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.
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
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.
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.
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.
* 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.
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.
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.
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.
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.
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.
I believe these people are called purple unicorns.....
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.
> 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.
I normally have my sound muted, precisely to avoid such nuisances. But this site shows why even that strategy is not always enough.
That's the hard part.
If you're building something with predictable timelines, it's another story but often in tech it's not.
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.
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.
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!