[pascalo]

Well, I for once am hoping they don't all come back to haunt me!

I've rarely met a good one. In most agency style environments PMs are responsible for the messes that will have to be picked up by the devs, having promised the world and are unable to backtrack on any of it "because the customer has already agreed to it". I'd rather talk to someone about what they want out of their product and then let them make an informed decision where they can weigh up cost and impact of a certain feature. After all it's their money.

[kabdib]

I've met a good PM or two.

Know how you tell a good PM? You think, "Thank God someone is doing that job. I'd hate to be doing it." They are bringing teams together and smoothing out rancor and NIH, getting agreement on things that are hard to get agreement on, researching things that nobody else has time to do, ensuring that Joe and Susan and Amhed are talking to each other regularly, and they know everything about the project, at least at a high level. They are technical as hell and you wonder why they aren't slinging code. You read the specs they've written and are just awe-struck by their technical depth and completeness.

Know how to tell a bad PM? You avoid them because they depress you and make you wish they didn't exist, because they subtract value from what you are doing. You go to their daily status meetings with a heavy feeling in your heart. You explain time after time to them that no, you can't use XML for that, that adding 12 programmers to the project won't bring in the schedule by six months, and that the slide deck they're giving to management in an hour has so many mistakes and fantastic assumptions that it might as well be crayon drawings by a three year old. The specs they write, if they exist at all, are mostly schedules and technical buzzwords and are useless. Typically, they love SharePoint.

Good PMs are very, very hard to find.

[maxsilver]

> I'd rather talk to someone about what they want out of their product and then let them make an informed decision where they can weigh up cost and impact of a certain feature.

So, you'd like to be a PM then?

[pascalo]

Not really. I'd rather work in an agile team with a proper product owner aka customer on board, where the whole team can discuss cost vs benefit of each individual feature and then act accordingly.

[USNetizen]

That setup rarely ever works. There needs to be a person to interact with the customer. Developers don't work well with customers.

A good PM will discuss options with the team, but they will serve as the interface through which the customer communicates with the team. The customer does not care how things get done, only that they get done on time.

[pascalo]

"Developers don't work well with customers"

Why does it have to be like that? This sort of silo thinking is probably what created the disconnect in the first place.

The customer might care about how things get done, if it means the difference between getting 85% of their wish list done or 50%, all depending on one obscure feature.

Agile/SCRUM can make the potential complexity of a feature more visible because it's a team estimate. It also can make the decision process less laggy because the customer/product owner sits in on the team. Finally it can make the end goal more visible to the Devs, resulting in less of a disconnect.

My 2p

[maxsilver]

It's not so much that it "has to be like that", in that your merging two different roles, without finishing your thought. Your arguing for good project management, and practicing good project management, while telling yourself + others that it's "no project management."

There is no such thing as "no PM". Such a concept can't exist (for the same reason that "no developers" can't exist). There's actual work there, that someone has to do, or nothing gets built.

Now, it's totally fine if you say "I think it's best if all of our team members spend 75% of their time as developers, and 25% of their time as project managers". That's what you've just described above, and (in my opinion) there's nothing inherently wrong with that.

But your misleading yourself if you claim "PM's aren't needed because Agile", or "PM's aren't needed because the one's I've met 'silo' us off". All you've done is shift the PM burden from a specific person, to some/all of your developers. Your developers are now actually "part-time developers, part-time PM's"

There's also some weird assumptions that your making around PM's. PM's do not have to silo developers away from the client (and good ones don't). PM's do not have to estimate for devs (good ones always use team estimates).

I've seen developers write buggy code, or brittle tests. But I would never say "developers aren't needed". You've clearly encountered bad PM's, and that's very unfortunate. But that doesn't mean "PM isn't needed", and as you yourself just described, you already have to pick up that work on your own since you lack one on your team.

[pascalo]

All good points, and I agree with you that project management as a task isn't going away. Of course my original comment was coined towards the agency style workplace (and meant to be a bit tongue-in-cheek), that's where I experienced the worst permutations of the role.

I'm not saying that there aren't any good ones somewhere else, but I just haven't really met any.

[seivan]

I agree with you. No need for these types of fake jobs.

[USNetizen]

Obviously you lack serious development experience. These "fake jobs" are the only reason we have serious apps like Salesforce, SAP and others. If you want to create a "hip" app just to get featured in TC and such with a 90% possibility you'll fail then, yeah, you don't need a good PM, because you're almost certain to fail anyway regardless.

[pascalo]

I am not sure what SAP and Salesforce have to do with my example of a typical agency environment?