3 ms·
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 ev
by erikb 10y ago
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.
- nicoburns 10y agoI 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.
- erikb 10y agoI can agree with that perspective. Yes, the implementation details should be left to the engineers. And in that regard you could consider both peers.
- dpark 10y ago> 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).
- op00to 10y agoThis 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.