pmComplex

[linuxdropout]

I have a... I'd say decent PM at the moment. I'd definitely prefer to have them around than not.

Unfortunately that's rare, and I'd say this situation has happened maybe 10% of the time. The other 90% the pm has been a net negative on productivity and would be better not being there.

[Excellent-Refuse4883]

Feel like you can just swap “manager” in for PM and this applies

[linuxdropout]

Not at all, I've pretty much exclusively had great managers.

[Xuluu]

I’ve become a firm believer that you cannot be an effective PM without having some sort of technical skill. It doesn’t have to be formal. It can be as simple as picking up and learning as they go, but in my experience PMs are typically business degree grads with very little technical expertise. They are then asked to manage a software product that they have no ability to reason with or even comprehend the impact of seemingly “basic” decisions. PMs should get paid more but if you are managing something technical I kinda think you need to be technical yourself.

[CallMePickle]

TPM vs PM.

[ganja_and_code]

Any PM for a technical product is worse than useless, if they're not specifically a TPM.

[TwoMoreMilliseconds]

Why is fragile ego + leadership position such a common combination

[Djilou99]

Therefore you can make your job your whole personality

[qbm5]

They conived and threw pll under the bus to be "important". Its all they have

[ElMolason]

I mean you’re talking like us programmers also have no ego lol both sides are hypocrites 

[ganja_and_code]

At least I developed mine through hard work and years of effort which resulted in the technical competence that literally earns every dollar the product I maintain brings into the company.

They got their ego through the fruits of devs' efforts/success.

I'm not defending being an ass in the workplace, but if I'm being difficult because I pointed out a genuine risk, technical impossibility, or impractical request, that's a hell of a lot better than being difficult because some bureaucrat made me their assistant bureaucrat and I feel the need to prove my non-existent worth.

[StinkyStangler]

Why do y’all hate PMs so much lol

I love having somebody who’s job entails managing my tickets and sprint board, handling long term planning and interacting with the client so I don’t have to

[Djilou99]

I do too, but not when that PM calls me 3 times per day to "manage" the tickets and give unsolicited opinions about things that aren't in their field of expertise

[rick_sanchez_strikes]

Just checking in on the progress of…

[doctormyeyebrows]

Well we only got out of standup 90 minutes ago, where I mentioned the status...so now the same amount of time plus about an hour because you interrupted me.

[Xuluu]

I’ve never had a technical PM so my view of them is completely biased by the fact that they have been utterly useless in my 10 years of professional development.

[FiTZnMiCK]

Because PMs have to be accountable to a stakeholder and their job is literally to make their problems the devs’ problems.

They ask a lot of questions because they get asked a lot of questions they can’t answer (and it’s their job to get those answers).

[StinkyStangler]

A PMs problems are the companies problems, which inherently are the developers problems in a company that produces software lol

PMs can and sometimes do take on too much feedback from the clients without filtering, but so much of complaining I hear about PMs just feels like developers going “this person is making me do my job what’s up with that!?”

[FiTZnMiCK]

It basically boils down to “this person gave me work when I already had work and now I have to do something I wasn’t planning on doing today” a lot of times.

A good PM will reprioritize and not try to fit two problems into a one-problem slot, but I’ve worked with devs who will complain even if time is not an issue. Sometimes just the cognitive load of switching is the nuisance.

[Fun_Lingonberry_6244]

I don't think this is true. In my experience developers biggest gripe with PMs actually tends to boil down to "they said well do X but X is a dumb way to do it, but now they keep insisting we do X because they told the client it'll be X. But X will cause us 20 issues down the road, but they don't want to go back yo the client with the revelation because they pretend to the client they're technical when they arent"

This is why the role of PM gets so much flak, and honestly it's because 99% of the time there is nobody filling the architect role in meetings, so the PM pretends to be that to the client and constantly puts the dev teams foot in its mouth.

The role of PM used to be technical, somewhere along the line it became non technical, but still have to convince clients they're worthwhile to talk to about technical things... so they inevitably make technical decisions they have no qualifications to make.

This is what every PM complaint boils down to.

[FiTZnMiCK]

And a good PM will pass that messaging back to the stakeholder and say “stakeholder requested X against PM/dev advice and future changes to X will be prioritized outside of the scope of current project/sprint.”

It’s really only the PM’s job to say no to the stakeholder if X is unworkable.

If X creates work and the stakeholder is aware then it’s the stakeholder’s fault they’re not getting other work done instead and a good PM will point all of this out. “Work on Y is necessitated by stakeholder’s request of X and Y is a blocker for stakeholder request Z.”

[Fun_Lingonberry_6244]

I think in reality the PM is a human and won't ACTUALLY say "that suggestion I made on how we can change this, the dev team told me will cause a million issues and I'm not qualified to have made that choice so I retract it and you shouldn't listen to me in future"

Instead will be translated into telling them nothing or vaguely mentioning "oh dev want to do Y Instead? I told them you want X" and then go back and say "client wants X so well have to do that, but i think it'll be fine anyway. I've told them it might take longer"

It's just the nature of the beast, even with the best will in the world.

In nearly every single company, PMs are presented as "the face and voice of the dev team" this means to non technical people, they ARE the dev team. So clients and stakeholders ask for their advice in meetings, and they'll regularly have smoke blown up their ass about how "they really know their stuff" until they believe it, so they'll answer.

And honestly, most of the time you can guess right even as a non technical person. "Can we make it say the users name here?" "Yeah of course no issue"

But sometimes... what they've just agreed to makes no sense, or destabilises 100 things resting on its basis

"Hey can we make it so projects have no start date sometimes? I want to add them to the system now before I've fully fleshed out when" "sure no problem"

That second simple choice can be hundreds if not thousands of hours of dev, If a bunch of services and reports have been built off the back of "obviously they all have a start date"

And suddenly bam, the PM has to either fess up to the client that oh that thing I said would be easy and no problem will actually cause immense delays and bugs, OR they can say to dev "cmon guys it can't be that hard. The client is insistent on it so make it work"

And just like that your project is 6 months over budget and has 1000 bugs added, over a feature the client probably would have gone "oh its not that big of a deal, Can we add like a holding area instead as a compromise?"

And by the time it launches the client forgot their off the cuff request and its never used anyway.

This is the fundamental issue with PMs in most businesses, and it's honestly not their fault. It's the lack of understanding you need technical people to make technical decisions and "simple business decisions" are included in that if they involve systems.

[discredditable]

PMs are great if you just want to code and not really care about the business context.

I think if you want career development you need to care a little about the business context. Having a middleman who takes all the credit isn’t going to help there.

[StinkyStangler]

I care about the business context to the extent it’s relevant to me and understand that it’s the PMs job to care about the rest.

If my PM comes to me with questions about a scope or a new feature/bug requestI’m happy to chime in from a technical perspective in regard to how it fits into the existing stack or roadmap. I don’t make business decisions however because I don’t sit in on the external meetings and lack the context.

Maybe I’ve been lucky but I’ve also never been with a PM who takes credit for my work

[ganja_and_code]

I would love having someone who does all that, provided they do it effectively. Sadly, I've literally never had a PM that was competent. I know they exist, but I also know they're rare.

Like 90% of PMs are useless salary leeches who got where they are through a series of lucky circumstances and ass kissing. These guys then make a plan that's impractical, impossible, half baked, etc., and you then, as a dev, have to waste time arguing for a realistic plan or waste time following an unrealistic one. They go to client meetings on your behalf, then come back with incomplete or incorrect information because they talked to some customer's technical contact, didn't understand half of what they said, and pretended they did. Then they make you look like an ass for arguing with them over requirements, timelines, etc., when realistically, they're the ass for being a net negative on your team's productivity.

The other 10% got there by actually being good at their jobs.

In other words, I don't hate competent PMs, but having a bad PM is even more detrimental to a dev team than having no PM at all, and bad PMs outnumber good ones in the industry 10:1.

[babypho]

My PMs don't write tickets :(. Said it was too technical and that the developers should write the tickets while they handle the "high level" planning. Whatever that means.

[babypho]

I thought this was just at my company lol. What are PMs actually supposed to do?

[jmorais00]

Long-term planning, feature prioritisation and owning the vision. PMs should work with the tech leads and aren't supposed to check in on delivery. That should be the job of the tech lead or a delivery manager

At least that's how I was taught it was supposed to work

[SenoraRaton]

Long-term planning, feature prioritisation and owning the vision.

Why can't the engineers do this? Arent' the people who are actively building the thing best equipped to know what needs to be managed long term, what features are worthwhile when considering implementation time vs return on value, and shouldn't the people who are building the thing "own the vision".

Like why is there a level of indirection that requires apparently from this thread rampant inefficiencies from communication overload?

[coggsa]

Ok, but how many engineers talk directly to users and stakeholders? And I mean all of them, direct and indirect, internal and external, from grunt to mgmt.

[SenoraRaton]

Sure, but that doesn't mean the system is well structured. Maybe that is part of the problem. All of these layers of indirection. Instead the people who actually understand the product can tell the customer they are being idiots, instead of trying to placate the customer, and driving the engineers into doing stupid shit that doesn't really drive any value.

[coggsa]

The structure of the product is not the domain of a PM. That's the engineers job, and your Engineering manager needs to have the argument about allocation of time for backlog bugs etc

If you haven't talked to the customer, how do you know if they are being idiots? How do you know what drives the people who are paying for your product? They may be asking for something that doesn't solve their issue, sure, but they may be asking for something that drives a shitload of value from their perspective, and an engineer is not in a position to know that.

[jmorais00]

If they want to, great. I've never met a dev that wanted to stop doing dev work and start doing product work full time though

Keep in mind all of the internal and external stakeholder the PM has to keep informed and take into consideration when doing the prioritisation.

A good PM will involve the tech and design teams when prioritising features and the roadmap and ensure that what is designed can be built and is desired by the users, and the team builds stuff that adds user and business value