[Gokenstein]

"Don't be afraid to filter people out, it happens that some beginners take a toll on the time of the team, because they develop errors / don't test code."

I would put a huge caveat here: Make sure you're deeply involved the process and understand what's going before taking any steps to sideline a programmer that's underperforming.

I worked for 3 years on a project that was underperforming by every metric. Major features were constantly riddled with bugs, rewritten, over budget. We had no way to push our issues above the PM who was throwing the developers under the bus.

The functional requirements would change daily, deadlines would not move, we were getting less and less QA time and 0 time to write or update tests and we were trying to write an integration with a service that was still in development (trying to hit a moving target).

They brought in a BA and kid you not, she quit 3 weeks in. That got the notice of management, finally, and our semi-technical schizophrenic partner on the client side was let go. Before we were able to escalate these issues there was a very different impression of the work we were doing. Afterward it was like black and white. Perfect releases, on time, on budget, and we were delivering real value to the client.

[NicoJuicy]

You are talking about your POV as a developer under a bad PM, which is unrelated to the question in my view :)

I agree, it seems harsh because I talk efficiently. But I suppose most of us try to fill in the social aspects according to their situation of the roadmap I "suggested", we are all adults here and nobody will become a dictator and reference my comment, I hope :p

[Gokenstein]

I thought I emphasized the point pretty well: Get involved in the process if you're managing a team of developers and don't just look at metrics. They can be misleading if there is no way for developers to communicate UP to managers or if there are self interested parties between you and your devs.

[NicoJuicy]

I've never thaught about a PM that isn't "involved" and only relies on metrics.

My experience is that PM's are part of the team ( and mostly a senior developer), not part of management.

They translate management decisions to their team and take responsibility for it. They shouldn't live in their ivory tower and not know what is going on.

Their experience gives them insights in developer efficiency issues and can solve more advanced problems.

Sometimes they help program, sometimes they are doing infrastructure ( Eg. Cloud management) or deployments.

They did good in the past and now do something else as a way of promotion and encounter new social aspects in managing a team and deploying a project.

Some should better stay developers and some like the challenge.

And if I interpreted the OP well, he's a promoted developer close to the team. And not a hired worker that thinks he's a PM without Dev experience.

[Gokenstein]

Oh, we've had very different experiences relating to project management! I've never had a PM that was a former developer, and in my world senior developers usually act as solution architects without the title, mostly removed from the day to day development tasks unless they're briefing developers on documentation and implementation details.