If work activities is about titles, I hope yours is multiple lines long.
We are talking about what is the most efficient. One of the point of Agile was to attempt to lower the division of tasks (and I'm saying that even if I don't like the way it was attempted nor the overall effect 20 years later) because having a broader vision of things is more efficient than trying to communicate (to what I would add: IF the project scale is reasonable enough to do that...); thus: a little bit of PM tasks, a little bit of working with customer, etc -- at least more involvement than if crappy requirements were produced after crappy contracts were signed, and neither of them could be revised.
So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem? You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.
It isn't, and I'm not going to go there. But discussion about work activities does need appropriate and accurate labels, for it to be effective.
> So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem?
Who said it's not good or that there's a problem? I didn't.
> You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.
I don't know what I wrote that leads you to believe this, but I said nothing like this. You seem to be reading too far into things I wrote; or worse, things I never wrote.
----
To try and clarify what I meant and where I was going: I was talking about accurately identifying the work that actually happens. Specifically, I was trying to show my parent commenter, ipaddr, how their erasure of such work leads to poor results for everyone involved, including the people trying to even talk about it.
I'm not trying to argue for a better salary or title — I've already got too much and too many of those, as you hope. But I've seen this very discussion happen too many times with clients of mine, with the same devolution. People think their problems will be solved if they get a good "PM". If said PM lacks technical background, they think they can just pair them with a good senior engineer and all will be good. I've seen this fail enough to know that's not how it works; and not because the senior engineer wasn't "senior" enough or "good" enough. As I said elsewhere[1] in this thread: There does exist a big difference between "lead or senior developers" who are good at development and those who are also good at using their technical knowledge to manage a team's work. A non-technical PM lacks that essential latter part, and if they have to rely on a "developer" to step up and fill that role, they're still a PM, but they're not the sole person doing PM any more.
Failure to identify when there's more than one person fulfilling management responsibilities can and does lead to poor planning and hindered execution.
We are talking about what is the most efficient. One of the point of Agile was to attempt to lower the division of tasks (and I'm saying that even if I don't like the way it was attempted nor the overall effect 20 years later) because having a broader vision of things is more efficient than trying to communicate (to what I would add: IF the project scale is reasonable enough to do that...); thus: a little bit of PM tasks, a little bit of working with customer, etc -- at least more involvement than if crappy requirements were produced after crappy contracts were signed, and neither of them could be revised.
So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem? You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.