Comment by quelltext | Hacker News Reader

Comment by quelltext | Hacker News Reader

The best experiences I had were working on products I cared about deeply in a way a PM should AND there actually was a PM involved who did care about them. In fact everybody involved should.

However, in a project there is a bunch of stuff you need to do that's mainly specific to product management. Tracking the feedback, talking to users, coordination with other product teams, covering the nontechnical pieces, etc. Every stakeholder does their thing. The PM in most cases doesn't code, a legal or compliance stakeholder doesn't try to talk to users or come up with product feature roadmaps, the engineers don't create the artwork etc.

The shittiest experience is when you work on a product with a formal PM but you wonder what it even is they are doing, not engaging in shaping the details just signing off, not talking to stakeholders, etc. and you, the engineer, has to fill in. Buuut you also cannot just do whatever because the PM exists and needs to be consulted.

I’ve had that product manager before. The real Shittiest PM isn’t the one who’s absent, it’s the one who does too much but not well. Constantly shifting priorities, unclear, yet rigid guidance, and unrealistic targets.

You could say this for almost any primarily supportive role. Individuals forget these roles bring nothing on their own and exist entirely to empower ICs. Conversely, that means they can disenfranchise ICs and be a net loss just as easily.

They aren't useless, but one could argue the industry needs a reality check on how many of these supportive roles need to exist (in terms of quantity) and how many of these individuals are contributing anything. There are plenty of bad stories ranging from "benevolent but capable" to "clearly power tripping and a drain".

Part of this problem, IMO, is that we as a society have largely eliminated subordinate supporting roles, in favor of adding more organizational work to both the ICs and management tier. Which leads to needing more managers, which leads to beaurocratic bloat as the people who have the power to make decisions end up being in a position where increasing management overhead improves their standing.

It all went downhill once we decided ICs should not only take care of the bureaucracy, but also adapt to supporter roles rather than the other way around. I won't rail against the usefulness of soft skills, but requiring almost every IC to be a well-spoken social butterfly just seems lazy in the face of the ridiculous number of supporting roles.

Ideally it'd be more 50/50 (help-me-help-you kind of deal), but right now it feels incredibly one-sided at most places.

Exactly. It's the difference between having a manager and having a secretary. When your support staff also has the power to fire you, it's inevitable that the technical staff have to adapt to the support.

I've seen and lived what you describe on occasion and it sucks. Managing the features does not mean deciding them, just like programming the features does not mean deciding them. Same for all disciplines. Establishing the process and responsibilities around which decisions are made is the hardest part of directing a project, and the default often ends up becoming "I direct thus I decide".

I have a PM who basically makes A/B choices as presented by tech leads, and leaves it to tech leads/devs to meet with users..

People that aren’t pulling their weight are annoying in any role.

Reply on news.ycombinator.com