Hacker News Reader

Comment by heisenbit | Hacker News Reader

Some PMs wear at times the peer hat. However I believe it is not a good idea to consider yourself a peer. Confusion about roles can lead to conflicts. By design the PM has to have to last word in most critical decisions, especially with outside contacts and that makes one stand out. An important part of the PM role is to say "NO" to all sides - while a peer may say only "no" - and this requires power. How to achieve a power position and how to maintain (wrt. to team but also other parties) it is also part of the PMs work.

Particularly at the beginning I would think carefully - possibly with the help of an experienced peer aka senior project manager - how to divide responsibility in the project. I found RACI (https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) often a robust and quick way to get started navigating a new project setup.

View on HN

> However I believe it is not a good idea to consider yourself a peer.

But PMs are peers. PM is not a position of authority. If you are acting as a PM and try to present yourself as if you have the authority to override dev decisions or demand that they do certain things, it might work, or you might breed resentment and hurt your interactions as well as the general team dynamic.

A PM should treat devs as peers and work to reach compromise and get buy-in from key stakeholders. A PM should not attempt to force their vision or plans onto the team. If you can't do the job without being in a position of authority, then you're not a good PM.

I think the difference here is between having responsibility vs acting like the guy with the crown. A manager should respect his engineers and shouldn't tell everybody that the engineers are "his guys" like he owns some slaves.

But in the end he's the one who should be allowed to override an engineer's decision on whether to work on task A or task B, when to pull extra hours and when it's okay to slack a little.

And if he's good he will be able to keep all the annoying meetings away from the engineers, which as well gives him more power over them but also allows them the freedom to focus on the code.

In a good relationship between PM and engineer it doesn't feel like one is on top of the other. But that doesn't mean there is no hierarchy in the company decision making perspective.

I think you have correctly identified a class of decisions in which PM's should have the final say:

ie. "What should the team be working on now"

But equally there are a class of decisions in which developers ought to have the final say:

"how should we implement this" and sometimes "which technology should we use"

I think peer is about right. With an important caveat, that PMs are often ALSO people managers. But that role is separate.

I can agree with that perspective. Yes, the implementation details should be left to the engineers. And in that regard you could consider both peers.

> But in the end he's the one who should be allowed to override an engineer's decision on ... when to pull extra hours

No way. I can agree that often the PM has the ability to set task priorities (not always, devs can push back and the devs' people managers will have the final say), but no way does a PM have the authority to decide that a dev should be working extra hours. Absolutely not. That is a pure people management decision (and one that should almost always be decided no).

This is a great point. If there's a resourcing issue, it should be brought up on the project calls way before it's an actual problem.

I'm conflicted, because both of these statements are true.

People are going to come to you with unrealistic requirements. This can't be a discussion- you have to say “No, there's no way my team can pull that off, we need to fix this”, and you have to have the relationship and credibility for them to believe you, trust you, and know they can work with you to come up with a solution. That's ambiguously like being a peer that also has the authority or respect to have the final say.

At the same time, you'll find out that every new project starts with the same response from your best developers: “No, I don't think we can do that”. 99% of the time, there's some ambiguous requirement making them apprehensive at a totally reasonable request. You have to have the relationship to firmly say “I'm willing to put in the hard work to figure this out with you”. You should have the credibility that they will have some kind of faith that you can better scope requirements in a way that alleviates their concerns.

Simply put, if you are a PM and don't consider yourself a peer, I don't want to be a dev in your organization for exactly the reasons I listed above.

If this is how you work today, ask yourself how many devs you work with already feel the way I do? If the devs can't tell you 'no', they have no control, no creative freedom. Put me in that situation, I'll find work elsewhere.

Having worked at some large corporations then have pmos and such. Yes, pm's are normally clased as peers. Devs normally report to a people manager. Pm's dont manage people.

PM's normally do their job via persuasion. They may get push back from the team on certain issues. Their job is report on this push back and the reason for it.

> Confusion about roles can lead to conflicts.

Agree. Accountability is the key here (this is not about authority). If things do not pan out as expected, the PM must be answerable, and to be in that position, [s]he must have the ability to make the final call in most situations.

Reply on news.ycombinator.com