[getoffmyyawn]

As an engineering leader, I tend to agree that giving Product Managers too much power causes lots of problems. A big one is retaining good engineers.

My experience of bad PMs is that they live in the Y side of the XY problem space[0] and believe they should have total say over how the engineers and designers spend every minute of their time.

Thankfully my company has a great CPO and we have agreed to avoid this type of PM. Anyone who says that the PM should be the Product CEO is not hired. Anyone who says they are the one to define how the engineering teams work is not hired.

At a truly tech lead organization, PMs work for the engineering teams, not the other way around. We have some great PMs who collaborate and provide lots of value.

0. https://xyproblem.info/

[who-le-o]

"PMs work for the engineering teams" made me cringe. This statement is no different than what the article is preaching, just another flavor. PMs and Engineering should work together. PMs #1 role and why they should even have a job is bringing customer clarity and urgency. Being a tech-led/product-led organization is just another version of sales-led organization. The ultimate balance is being customer-led which many companies/teams don't fully understand. But I fully agree with the "product CEO take" - as a PM I hate that framing.

[matwood]

> At a truly tech lead organization, PMs work for the engineering teams, not the other way around.

Every company should be customer led. Not in the sense they tell you exactly what to build, but understanding the customers problem and then coming up with solutions. In small companies it is much easier to align everyone with the customer. When we were a small company I would send engineers to sales/industry conferences, and it was great to see their eyes open and suddenly understand all the 'odd' requests coming from sales.

This becomes harder in a large company, so the customer has to be proxied somehow. PMs and sales are the common customer proxy. But, if the engineers are being asked to do something and they don't see the value, that is absolutely a failure of communication from PMs and sales. I've also seen the other side where the engineers fight anything that doesn't fit in their idea of the product, regardless of customer or business demands. Both are frustrating.

[stakhanov]

> At a truly tech lead organization, PMs work for the engineering teams, not the other way around.

This reminds me of a company I worked at that had a lot of rhetoric going around inverting the power relationship between teams and their managers.

Basically the "project manager" role was renamed into "project advisor", the department manager to departmental advisor and so forth, carrying the connotation that a subordinate might just choose to ignore "advice" from above.

In reality, the whole thing was a charade to bullshit people into believing they had more power than they actually had. If someone decided to disagree on any given piece of "advice", they would usually find themselves in a call with the line manager one level up and be told that they were perfectly on track for not getting any salary increase this cycle and no more promotions ever again, because of the arrogance, ignorance, and a dozen other negative personality traits, attributable to anyone who won't follow "advice".

This was soo much worse than just having "a boss". If you have a boss, you might just think to yourself "The boss is full of shit, but I'll have to implement it anyway, because that's just how it goes. He has power, I don't." But now there is this whole gaslighting element where you start to question your own reality: "Why does it seem to me right now that the boss is full of shit? Is that because I'm too arrogant to take advice? Is it because I'm too dumb to fully grasp the greater wisdom of his advice?"

Once you create a caste such as the "product managerial" caste, it just doesn't matter what you call them, and how you define their role on paper. They are going to be in power.

Because there has to be some reason why you chose to distinguish them from the engineers. The article itself seems to reflect some of the bogus beliefs that motivate why engineers can't be their own product managers: Like they are so socially inept that they can't coordinate with relevant stakeholders, and they are so far removed from the customer that they have no way of figuring out by themselves what to build. There also has to be a reason why you chose to distinguish them from the sales people: Like salespeople will just recklessly say "yes" to any and all customer demands with no idea of the cost of actually building stuff.

So what's the solution, if you think you have these problems? Apparently, to create a new caste of people. Let's call them "product managers". And because we are calling them something different, those prejudices won't have to apply to them. They won't be socially inept and removed from the customer, because we're not calling them engineers. And they won't be reckless because we're not calling them salespeople.

If you hold those beliefs, they are going to be in charge, won't they? Because you've just chosen to think of everyone else in this negative way, and put those project managers up on a pedestal. You've chosen a whole caste of people whose very reason for being is predicated on those negative beliefs about these other groups. And they'll work hard to perpetuate those beliefs, possibly even sabotage the company to make them stay true. They don't even have to be evil to act this way, just human, because is psychologically natural. Hire a full time event manager, and you'll have someone who will constantly be politicking the company into doing events, because, otherwise, why are they here? Hire full time product managers, and you'll have someone who will constantly be politicking the company into not letting engineers and sales people make "product" decisions.

The better thing to do is to go back to the original problems and try to solve them: Like, give engineers blocks of time off from coding duty, so they have time to be more proactively communicating with stakeholders. Send them along with a sales person every now and then so they get to talk to customers regularly. Give them time off so they can be trained in usability and design. Let sales people follow along with engineering status updates when you're building a feature that they promised to a customer. So they come to appreciate just how much work it is to actually build stuff. ...now there's no longer a need to have product managers, and you've actually solved problems that were going to cause trouble anyway, regardless of whether you have product managers or not.