A good manager should be able to either provide technical guidance or at least ensure that it's coming from somewhere.
I've seen teams complain that management rushed them. So management stopped rushing them. The quality of the code didn't change at all. Not even a little bit. The developers had no idea what to change, and neither did management.
Software engineer with over 10 years experience in different technology stacks, architecting, developing, CI/CD and leading teams. Currently working with Java, Node.JS and Serverless
From my experience teams achieve better results when they have complete responsibility over the piece which they produce, from gathering requirements to post-go-live maintenance, an can make decisions on their own. With all respect for managers, very often I saw ones who do more harm than good for the projects through micromanagement. Team also work better knowing the long-term vision and plan and don't jump from project to project every quarter but have enough time to learn the project. I know companies which work in silos where no team really owns the product, one team works on features, other work on bugfixing yet another do deployment. When work is spread like that no one really feels the impact of doing good work from the very beginning till the end and no one feels responsible for failures. In most cases like that I saw a poorly designed solution, discouraged employees and high turnover. Personally I prefer to work in small self-organizing independent teams but this works when at least a few members have experience, I definitely would not risk it with all junior devs in a team, even though I saw some excellent junior teams in action, but general experience is that juniors have too much fantasy to experiment with technologies and tools ;) while seniors tend to find a good balance and prefer battle tested solutions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A good manager should be able to either provide technical guidance or at least ensure that it's coming from somewhere.
I've seen teams complain that management rushed them. So management stopped rushing them. The quality of the code didn't change at all. Not even a little bit. The developers had no idea what to change, and neither did management.
From my experience teams achieve better results when they have complete responsibility over the piece which they produce, from gathering requirements to post-go-live maintenance, an can make decisions on their own. With all respect for managers, very often I saw ones who do more harm than good for the projects through micromanagement. Team also work better knowing the long-term vision and plan and don't jump from project to project every quarter but have enough time to learn the project. I know companies which work in silos where no team really owns the product, one team works on features, other work on bugfixing yet another do deployment. When work is spread like that no one really feels the impact of doing good work from the very beginning till the end and no one feels responsible for failures. In most cases like that I saw a poorly designed solution, discouraged employees and high turnover. Personally I prefer to work in small self-organizing independent teams but this works when at least a few members have experience, I definitely would not risk it with all junior devs in a team, even though I saw some excellent junior teams in action, but general experience is that juniors have too much fantasy to experiment with technologies and tools ;) while seniors tend to find a good balance and prefer battle tested solutions.