6 ms·

In today's world of agile development, I haven't met any project managers worthy of anything. I feel that strong product managers are capable of managing develo

In today's world of agile development, I haven't met any project managers worthy of anything. I feel that strong product managers are capable of managing development as well. I can't believe there are actual people getting paid to move JIRA tickets around full-time.

Justsignedup 8y ago
Good project management is invisible. They just make projects happen. They make sure everyone is talking. They make sure decisions are made. Everyone knows what to do when to do it. Etc. I seen good project management. It is magical. Then the manager left. Everything slowed down to a crawl.
- bfdm 8y ago
  Yep, it's the thankless job that when done well nobody notices.
- JMTQp8lwXL 8y ago
  Invisible makes it sound intangible. If you can't quantify the value you're adding to an organization, are you adding any at all? Making sure "the right people are talking", "decisions are made", etc. do sound like things that can be tracked to confirm if a PM is indeed adding value.
  - kamaal 8y ago
    >>If you can't quantify the value you're adding to an organization, are you adding any at all? At some point in time recurring wins can look like a perpetual machine. The problem is when you get there, people think like, Now that we got what we want why do we need this person? It's only after the person goes and a few months down the lane you begin to see things falling apart. Of course by then things just become the new normal.
  - crispyambulance 8y ago
    > If you can't quantify the value you're adding to an organization, are you adding any at all? The problem with that line of thought is that it's not at all easy (or even possible) to quantifiably measure performance on an individual basis. This is especially true for roles like PM's whose job is to enable the labor and talent of others.
    - JMTQp8lwXL 8y ago
      Many roles are difficult to quantifiably measure. The same is true for software engineers-- suppose two developers are shipping code, but one writes 2x as many lines of code. Do we say they're twice as productive, or delivering twice as much business value? Not necessarily. But there should be something that can be measured, even if it's imprecise, to at least show that something's being done. How do you measure the success criteria for the role of a PM? It's challenging. But it should be done.
      - crispyambulance 8y ago
        Measure and "quantifiably measure" are two different things. I agree that performance can and should be evaluated, however, for many jobs that is an intrinsically subjective task. There's nothing wrong with that. It's just the nature of such roles. You still evaluate, you just don't boil it down to one "score".
  - TStowe 8y ago
    Oftentimes I've seen PMs used to talk directly to clients about projects, and groups of execs. Hired because they're great "window dressing".
  - zaarn 8y ago
    On a similar thought the IT department of organizations in the past was neglected. After all, they don't add any value, they are only needed to shuffle around dead hardware for new hardware. Similarly a good manager provides auxiliary value; it doesn't directly add value to the organization but if it's not there then the overall value decreases. Not everything in an organization is immediate positive effect.
zamalek 8y ago
I worked under one in South Africa and he was genuinely passionate about project management: he was constantly in courses, constantly researching and constantly asking for feedback. One of the teams I oversee now in NA also has a brilliant project manager. Of all my 12 years in the industry I haven't once seen someone pull a team into productivity nirvana like she does. She deeply understands the concept of agile and every sprint she is trying a new idea with her team (process is a feature!). They do exist, but they are rare.
Aloha 8y ago
Not everyone lives in an agile world. Besides, there are still politics to shield from, budgets to maintain, stakeholders to brief, paperwork to do - all stuff that putting an engineer on - would be an utter waste.
- democracy 8y ago
  Exactly, for some reason we got rid of PMs, then architects, then "devops" (as they understand it) replaced system administrators, and now as a software engineer you have to do much more, actually leaving less time for your actual are of competence.
deleted 8y ago
[deleted]
mikekchar 8y ago
It's unfortunate. Especially in agile, a good project (err.. product...) manager is worth their weight in gold. I have to be honest, I've had my hand slapped here on HN for conflating project managers with product managers. I admit that I do this because from an agile software development perspective you need a variety of skills. One of the biggest problems I've seen on agile projects is a lack of analysis. Often "agile" development processes are chosen because people want to avoid analysis. I think the thinking is that if you remove all the documentation and discussion around what you are building, the developers will just "do the right thing" and you'll save a whack of time. In fact, on the XP teams I've run, I tend to have 2-3 month backlogs of stories. You want to think through what you are building and what the implications are. There are 2 main differences between this and a more analysis-up-front approach. First, your stories are changeable and prone to re-ordering. Second, you defer some decisions until later. There is no phase when the requirements are carved into stone. However, if you get to the beginning of the sprint and you don't know what the acceptance criteria for all of the stories in the sprint are, then you are in big trouble. Also, I come from the ancient days. I've personally written a 1300 page requirements document. That took 6 months to write. That was largely ignored. When I tell people that I want a couple of months out of "this is what we're doing if nothing changes", these days people think I've got all top heavy on them. Times change... This is where a good project/product manager comes in handy. You need someone who owns the overall vision of what you are building and has time to think through the implications. You need someone who is constantly grooming the backlog and updating the cards as the vision changes. You need someone who understands the business priorities and knows when and how to reprioritise the backlog. You need someone who is constantly asking the question, "It's fine to do X, but what does that mean for Y", or "What makes you think that this is the solution we need" or "Who is going to be affected when we do X". Often product/project managers think, "Oh I don't have to know how the product works in detail". This is a huge red flag for me. They often think "Oh the programmers can decide what to do here". Yes, the programmers can, but they already have their plate full with how to do what needs to get done. If you ask them to think through all the details of what and why then they will have less time for how. Similarly, if you have a team of 6-8 developers, then you will have 6-8 opinions about what the best thing to do is. The vision will potentially be weakened and you will often find that the programmers spend half their time arguing about who has the best idea. At best you'll have 1 developer doing the product/project manager's job and the rest will be doing programming jobs. I could go on forever here. I haven't even touched on dealing with internal politics, reporting, ensuring visibility of problems, coordination with other groups, gathering data, etc, etc, etc. If you don't have someone doing these things then they are often not getting done at all (often to your detriment) or you are wasting your precious programming horse power dealing with the realities of business. As you can imagine, I over the years I've regularly butted heads with "I don't really want to do anything at all" product/project managers. But if I get someone willing and able, I will absolutely load them down with work that has the potential to make a massive difference to everyone.
sh87 8y ago
I have observed a few over the past years. Their work revolves around starting up the standup call, sending meeting invites, moving tickets/stories/defects and yeah thats about it. Seems depressing and frustrating as a dev. But they seem to be as happy as a fish in a bowl. I don't get it.
panda888888 8y ago
Disagree completely. A good project manager sees themselves as a peer to devs, with a goal of shielding their team from dumb administrative stuff (like requests from upper management that are clearly out of touch with how the product actually works). To do so, they must see themselves as a peer. Anyone with an ego who wants to boss people around will be a terrible PM. A good PM enables their team and is altruistically driven. Once you work with someone like this, you'll understand how amazing PMs can be.
siruncledrew 8y ago
It’s easy to be bad and hard to be good. There’s PMs I know that casually joke about how about most of their week is time spent dicking around on the internet while having a few meetings and watching some tasks get done. They are more like project secretaries where they DGAF about being involved. Then there are PMs that go the extra mile to keep stakeholders involved, triage bugs and tasks, and willfully volunteer to fill in as needed. They are the ones that can actually add substantial value to a project.

Justsignedup 8y ago

Good project management is invisible. They just make projects happen. They make sure everyone is talking. They make sure decisions are made. Everyone knows what to do when to do it. Etc. I seen good project management. It is magical. Then the manager left. Everything slowed down to a crawl.

bfdm 8y ago
Yep, it's the thankless job that when done well nobody notices.
JMTQp8lwXL 8y ago
Invisible makes it sound intangible. If you can't quantify the value you're adding to an organization, are you adding any at all? Making sure "the right people are talking", "decisions are made", etc. do sound like things that can be tracked to confirm if a PM is indeed adding value.
- kamaal 8y ago
  >>If you can't quantify the value you're adding to an organization, are you adding any at all? At some point in time recurring wins can look like a perpetual machine. The problem is when you get there, people think like, Now that we got what we want why do we need this person? It's only after the person goes and a few months down the lane you begin to see things falling apart. Of course by then things just become the new normal.
- crispyambulance 8y ago
  > If you can't quantify the value you're adding to an organization, are you adding any at all? The problem with that line of thought is that it's not at all easy (or even possible) to quantifiably measure performance on an individual basis. This is especially true for roles like PM's whose job is to enable the labor and talent of others.
  - JMTQp8lwXL 8y ago
    Many roles are difficult to quantifiably measure. The same is true for software engineers-- suppose two developers are shipping code, but one writes 2x as many lines of code. Do we say they're twice as productive, or delivering twice as much business value? Not necessarily. But there should be something that can be measured, even if it's imprecise, to at least show that something's being done. How do you measure the success criteria for the role of a PM? It's challenging. But it should be done.
    - crispyambulance 8y ago
      Measure and "quantifiably measure" are two different things. I agree that performance can and should be evaluated, however, for many jobs that is an intrinsically subjective task. There's nothing wrong with that. It's just the nature of such roles. You still evaluate, you just don't boil it down to one "score".
- TStowe 8y ago
  Oftentimes I've seen PMs used to talk directly to clients about projects, and groups of execs. Hired because they're great "window dressing".
- zaarn 8y ago
  On a similar thought the IT department of organizations in the past was neglected. After all, they don't add any value, they are only needed to shuffle around dead hardware for new hardware. Similarly a good manager provides auxiliary value; it doesn't directly add value to the organization but if it's not there then the overall value decreases. Not everything in an organization is immediate positive effect.

zamalek 8y ago

I worked under one in South Africa and he was genuinely passionate about project management: he was constantly in courses, constantly researching and constantly asking for feedback. One of the teams I oversee now in NA also has a brilliant project manager. Of all my 12 years in the industry I haven't once seen someone pull a team into productivity nirvana like she does. She deeply understands the concept of agile and every sprint she is trying a new idea with her team (process is a feature!). They do exist, but they are rare.

Aloha 8y ago

Not everyone lives in an agile world. Besides, there are still politics to shield from, budgets to maintain, stakeholders to brief, paperwork to do - all stuff that putting an engineer on - would be an utter waste.

democracy 8y ago
Exactly, for some reason we got rid of PMs, then architects, then "devops" (as they understand it) replaced system administrators, and now as a software engineer you have to do much more, actually leaving less time for your actual are of competence.

deleted 8y ago

[deleted]

mikekchar 8y ago

It's unfortunate. Especially in agile, a good project (err.. product...) manager is worth their weight in gold. I have to be honest, I've had my hand slapped here on HN for conflating project managers with product managers. I admit that I do this because from an agile software development perspective you need a variety of skills. One of the biggest problems I've seen on agile projects is a lack of analysis. Often "agile" development processes are chosen because people want to avoid analysis. I think the thinking is that if you remove all the documentation and discussion around what you are building, the developers will just "do the right thing" and you'll save a whack of time. In fact, on the XP teams I've run, I tend to have 2-3 month backlogs of stories. You want to think through what you are building and what the implications are. There are 2 main differences between this and a more analysis-up-front approach. First, your stories are changeable and prone to re-ordering. Second, you defer some decisions until later. There is no phase when the requirements are carved into stone. However, if you get to the beginning of the sprint and you don't know what the acceptance criteria for all of the stories in the sprint are, then you are in big trouble. Also, I come from the ancient days. I've personally written a 1300 page requirements document. That took 6 months to write. That was largely ignored. When I tell people that I want a couple of months out of "this is what we're doing if nothing changes", these days people think I've got all top heavy on them. Times change... This is where a good project/product manager comes in handy. You need someone who owns the overall vision of what you are building and has time to think through the implications. You need someone who is constantly grooming the backlog and updating the cards as the vision changes. You need someone who understands the business priorities and knows when and how to reprioritise the backlog. You need someone who is constantly asking the question, "It's fine to do X, but what does that mean for Y", or "What makes you think that this is the solution we need" or "Who is going to be affected when we do X". Often product/project managers think, "Oh I don't have to know how the product works in detail". This is a huge red flag for me. They often think "Oh the programmers can decide what to do here". Yes, the programmers can, but they already have their plate full with how to do what needs to get done. If you ask them to think through all the details of what and why then they will have less time for how. Similarly, if you have a team of 6-8 developers, then you will have 6-8 opinions about what the best thing to do is. The vision will potentially be weakened and you will often find that the programmers spend half their time arguing about who has the best idea. At best you'll have 1 developer doing the product/project manager's job and the rest will be doing programming jobs. I could go on forever here. I haven't even touched on dealing with internal politics, reporting, ensuring visibility of problems, coordination with other groups, gathering data, etc, etc, etc. If you don't have someone doing these things then they are often not getting done at all (often to your detriment) or you are wasting your precious programming horse power dealing with the realities of business. As you can imagine, I over the years I've regularly butted heads with "I don't really want to do anything at all" product/project managers. But if I get someone willing and able, I will absolutely load them down with work that has the potential to make a massive difference to everyone.

sh87 8y ago

I have observed a few over the past years. Their work revolves around starting up the standup call, sending meeting invites, moving tickets/stories/defects and yeah thats about it. Seems depressing and frustrating as a dev. But they seem to be as happy as a fish in a bowl. I don't get it.

panda888888 8y ago

Disagree completely. A good project manager sees themselves as a peer to devs, with a goal of shielding their team from dumb administrative stuff (like requests from upper management that are clearly out of touch with how the product actually works). To do so, they must see themselves as a peer. Anyone with an ego who wants to boss people around will be a terrible PM. A good PM enables their team and is altruistically driven. Once you work with someone like this, you'll understand how amazing PMs can be.

siruncledrew 8y ago

It’s easy to be bad and hard to be good. There’s PMs I know that casually joke about how about most of their week is time spent dicking around on the internet while having a few meetings and watching some tasks get done. They are more like project secretaries where they DGAF about being involved. Then there are PMs that go the extra mile to keep stakeholders involved, triage bugs and tasks, and willfully volunteer to fill in as needed. They are the ones that can actually add substantial value to a project.