> Anyway, it might be good to talk to your PMs and not assume they're evil villains.

I've always thought PM's to be more or less aliens with a ray gun tapping at their watch. Communicating with them goes nowhere since they don't empathize with your point of view. The only thing they're concerned with is when something's going to get done. The only form of motivation is threat of existence in the company.

> While I've certainly seen incompetent, bureaucratic and/or poorly incentivized PMs, I don't think I've ever met one who wants to throw their developers under the bus to get a job done.

Perhaps, it's also possible you've never worked at enough shops to see it.

> one reason PMs might not "care" about scaling up that database, is that it almost never needs to be scaled. Seriously.

You're not the one going to be called at 4am when postgres takes a dump. If you volunteer to cycle into the on-call hours, I'd feel more compassionate for your point of view. Until PM's do this, I decline to see it that way.

I guess I feel like the PM is worthless position unless the PM is writing code along side the team, and can fully appreciate the technical problems -- and more importantly -- offer technical solutions.

A good PM is worth their weight in gold, but the problem is that the qualifications for a good PM are very hard to make objective. This leads to the role becoming magnet for power-hungry MBAs with a bean counter mentality who will tend to outcompete anyone with real knowledge of UX or engineering unless the company understands the danger of money/power-driven PMs and actively counteracts it by focusing on actual product skills.

I’ve found that only hiring technical PMs can be really helpful in this regard. YMMV depending on the product, but when it fits it’s great.

I've been the guy who gets called at 4am when postgres takes a dump. I've also been the guy doing the calling (well, not really as a PM, since again, we don't generally have the ability to tell anyone what to do at 4AM, but I digress.)

> Communicating with them goes nowhere since they don't empathize with your point of view.

Can't speak for everyone, but again, I've been on both sides of the table, and I've never seen an example of this. I think it's rare.

> The only form of motivation is threat of existence in the company.

This is so extreme that I feel I must respond just for the sake of other people reading it: if your PM is motivating you via threats, something is very wrong.

> if your PM is motivating you via threats, something is very wrong.

Seriously? This is how 80% of companies work. In many of those companies, stack ranking is a very effective tool for running people out the door. It's often _baked_ into corporate culture.

If that's your experience, you either have been extremely unlucky, or you should look back on your own behavior.

I've had some problems with PM before, but never about threats, and that would go very poorly with most people I know.

In 2022 what's the leading cause of people leaving a company?

Toxic Management / Toxic work culture.

https://www.cnbc.com/2022/01/14/the-biggest-reason-people-qu...

Modern management have had what? 100 years to fix this now?

I think the grandparent meant that the PM is motivated by the threat of having to leave due to a failing project.

That's how I read it.

> I've never seen an example of this

Without knowing what your experiences are, as context, it's not possible to see the value in this. How many places (for how long) did you work as a dev?

> Former engineer turned PM here.

I think you'r experience as an engineer has biased your view. For example number 3 with your engineering experience you might think that but ultimately it's the engineering team that has to deal with the scaling not you.

Your incentives are to scale everything back to meet dead lines while the engineers incentive is to make every thing work so that when it goes live they don't get called into a meeting to be thrown under the bus. As the only one that actually produces something that can be criticised at the end of the day the engineers incentive is naturally to minimise that.

The problems that arise from this are not people problems, its not a problem with the engineers spinning stereotypes or pm being bad faith its a problem with incentives being aligned agains't each other.

Except that it's not a problem it's everything working as intended, the higher ups want pm and engineering to have it out with each other as they see that as checks and balances.

As mostly an engineer (though I've spent time as a tech/team lead and engineering manager in the past), I think you've missed the point.

Most of the things will not need to be "scaled" at all. Ever.

As an engineer, I mostly struggle to come up with a simple solution while accommodating all the crappy, leaky abstractions in the rest of the code: that's the hard part of the job. And 20 years in, I still wonder why people think it's smarter to introduce seventeen layers of abstractions for things that have one or at most two implementations, but that's what they do.

> I still wonder why people think it's smarter to introduce seventeen layers of abstractions for things that have one or at most two implementations

Tell me you are a Java dev without telling me you are a Java dev. :)

(While I know it's not just Java with this problem, my personal experience is that Java is the worst.)

> Tell me you are a Java dev without telling me you are a Java dev. :)

FWIW, I am not :)

Indeed, concern about how well your product might scale to handle high load and use of umpteen layers of abstraction sounds somewhat contradictory to me! (I'd also say most scaling problems aren't necessarily all that hard to solve, but having some idea of what limits might be hit fairly quickly if there was an anticipated need to grow the userbase is a pretty key part of building SaaS platforms. Even single user apps can suffer from scaling issues if suddenly they're expected to deal with far more data than anyone had bothered testing with. Allowing the engineering team, including QA, time to assess potential scaling issues is surely the first step.)

I think some harsh language was used (probably because of frustration), but I think they didn't mean to imply outright _malice_.

More like "incompetence" (eg poor people skills, planning skills, and often lack of technical understanding), followed by shallow human nature which gives in to survival instinct, which generally leads the PM to "blaming developers", so they they don't themselves get in trouble (and a lot of people have problems owning mistakes in general, but that's enough misanthropy for one post).

Also, they don't really _blame_ the developers by point a finger at them and shouting "he did it" like some childish display. They try to soften the blow (humans usually try to be decent; we just can't agree what decent is always) by adding an adversary into the story (like the technical debt, or hidden complexity).

Edit: Forgot to address this, but talking to a PM can often backfire, because you need exceptional interpersonal skills to have difficult those kinds of conversations with a PM. And if they're insecure and take it the wrong anyway, they can make you even more miserable.

Any engineer that moves away from engineering never really enjoyed or "got it" anyway, by using the "I used to be an engineer!" tag you're just trying to score extra points. It doesn't make your argument more compelling, cmv.

Check my profile. I was an engineer for a long time, and I enjoyed it. Been writing code in a professional capacity for multiple decades.

I became a PM because I wanted a new challenge while not being totally divorced from making things. It's a harder job, in multiple ways, and one of the things that makes it hard is convincing (mostly junior) engineers that I know what I'm talking about. There are many days when I want nothing more than to go back to the simple, closed-form world of writing code. Compared to dealing with people, even the hardest coding problem is straightforward.

I probably shouldn't be replying, but I've noticed too many coders hearing "PM" and flipping the idiot bit. I want to do something to fight back against that trend.

It's good not to make assumptions about other people.

Thank you for your pushback, seriously. This "us vs them" mentality, especially applied to PMs, is outright toxic and counterproductive.

I was blessed to be able to build a team of developers who understand business value and prioritise accordingly, who like building things for others and not just a shrine to their intellect [1], and I wouldn't want to have it any other way. It's amazing to work in a team where most challenges are product and market challenges, and the rest is just pragmatic technical considerations. The world people describe in this thread sounds like a self-perpetuating hellhole.

[1] although arguably it's much harder to build something simple but good enough and compatible with future changes

"I hate this 'us vs them' mentality, but I need to keep my developers in check and make sure they prioritise business value accordingly"

Is exactly the kind of paternalistic nonsense that developers have to endure.

PMs exist to shield us from the shit. I work with a great one who does this, trusts the team and lets us get on with it without introducing ridiculous process, but the vast, vast majority of PMs I've had to work with are utter garbage.

What do you mean "keep in check"? In my experience people caring about the product and value that it brings to the world and having real visible impact on it don't need "keeping in check". It is important to screen for that during interviews, yes, and it won't work in feature factories and bullshit adtech that no one actually cares about, but when it's smart people in a small team working on something generally good for the world it just happens on its own. There is nothing paternalistic about it.

Maybe when it's a large dysfunctional org, yes. Ideally PMs exist to facilitate, not to "shield".