4 ms·

Have spent about 5 years in Program/Project Management, and 10 in Developer Lead roles, and the big thing I'd have to say about the PM world is that just becaus

by orbz 10y ago

Have spent about 5 years in Program/Project Management, and 10 in Developer Lead roles, and the big thing I'd have to say about the PM world is that just because it has Management in the title doesn't mean you're a people manager. You're the developers' peer, and will have to do a good chunk of work convincing them that the work you think is important, is in fact important. Everyone has gut feelings on what the project should be and where it's going. Your job is to provide hard evidence and tracking of that on behalf of the end user. Also you're not a full time dev anymore. Don't take dev tasks on unless they're menial and no one else wants to do them. Nothing undercuts trust like doing someone's job for them.

mabbo 10y ago
> the title doesn't mean you're a people manager. You're the developers' peer This, 1000 times. The Project Manager role is one of convincing others, helping organize them, and smoothing out relationships with other teams/organizations. If you try to act like an authority figure, the devs working with you wind up in an "Office Space" style "I have 8 bosses" problem.
- heisenbit 10y ago
  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_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) often a robust and quick way to get started navigating a new project setup.
  - dpark 10y ago
    > 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.
    - 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 ago
        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.
        erikb 10y ago
        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.
ThrustVectoring 10y ago
I'd qualify the "convince people that work is important" should be made conditional on it being actually important. Like, I think it's important to facilitate the other direction of information flow by listening to developers, figuring out why they think certain things are more important than others, and advocating for the things you end up agreeing on.
munchbunny 10y ago
When I made the switch from developer to product/program/project management, the biggest mistake I made was still trying to write code. It's one thing to keep your coding skills sharp, but there is so much to do as a PM other than writing code that will more than make up for the 40 hours a week you gave up by switching jobs. In theory your role as a PM at your company exists because the developers and designers are no longer able to sustain the managerial/organizational overhead coming from team and scope growth. This really depends on the needs of the organization, but my rule of thumb is to only write code if (1) it's to get data you need or (2) you're bored and can't find anything to do.
- civilian 10y ago
  And if you're bored and can't find anything to do, please don't take the fun research task that I'm hoping to get to once I finish the important/boring tickets in my sprint. :(
  - alistairSH 10y ago
    That's one of the hardest thing I do - leaving "fun and interesting, but not critical" stuff in the backlog for my developers. As mentioned up the comments, I try to pick up some of the small and boring tasks. Or, as my test engineer is usually overbooked, I pick up test tasks.

by orbz 10y ago

mabbo 10y ago

> the title doesn't mean you're a people manager. You're the developers' peer This, 1000 times. The Project Manager role is one of convincing others, helping organize them, and smoothing out relationships with other teams/organizations. If you try to act like an authority figure, the devs working with you wind up in an "Office Space" style "I have 8 bosses" problem.

heisenbit 10y ago
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_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) often a robust and quick way to get started navigating a new project setup.
- dpark 10y ago
  > 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.
  - 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 ago
      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.
      - erikb 10y ago
        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.

ThrustVectoring 10y ago

I'd qualify the "convince people that work is important" should be made conditional on it being actually important. Like, I think it's important to facilitate the other direction of information flow by listening to developers, figuring out why they think certain things are more important than others, and advocating for the things you end up agreeing on.

munchbunny 10y ago

When I made the switch from developer to product/program/project management, the biggest mistake I made was still trying to write code. It's one thing to keep your coding skills sharp, but there is so much to do as a PM other than writing code that will more than make up for the 40 hours a week you gave up by switching jobs. In theory your role as a PM at your company exists because the developers and designers are no longer able to sustain the managerial/organizational overhead coming from team and scope growth. This really depends on the needs of the organization, but my rule of thumb is to only write code if (1) it's to get data you need or (2) you're bored and can't find anything to do.

civilian 10y ago
And if you're bored and can't find anything to do, please don't take the fun research task that I'm hoping to get to once I finish the important/boring tickets in my sprint. :(
- alistairSH 10y ago
  That's one of the hardest thing I do - leaving "fun and interesting, but not critical" stuff in the backlog for my developers. As mentioned up the comments, I try to pick up some of the small and boring tasks. Or, as my test engineer is usually overbooked, I pick up test tasks.