Ignoring curation of software development teams is bad management practice
Most managers of software engineers don't have the skills to understand when team curation is missing, this results in teams that have members that are dangerously outside of their wheelhouse
Team curation can be an important management job depending on the maturity of the team. I’ve seen a few amazing teams that handled technical curation via senior, caring staff steering members into work that was appropriate for their skill level and growth needs. However, many teams don’t have that level of maturity and the curation task falls through to the development manager. Sadly, most managers of developers lack the skills necessary because of the industry's propensity to promote weak engineers into management. Can’t code? Become a manager!
You can recognize these weak managers because they actually can’t tell how strong their team is, and will easily fall into blaming their team for failures. I would ask any manager with the gall to blame their team for being the weak link, “Why do you have such weak engineers on staff?” In truth I suspect most of them are just weak managers that can’t tell the difference between a level 2 and 5 software engineer, because they never got past 2 before jumping into management. These types of managers tend to think a level 5 engineer someone who has a certain number of years of professional experience. We all know this to be patently false.
In place of competent team curation, these weak managers often apply domination and kingdom building anti-patterns. As an example I’ve seen managers not only pit their team members against each other, but pit their team against others, using words like “I’m not sure what’s going on with the backend team, we’re doing great on the front end.” Substantive software product development is complex work that requires teams of people working together in good faith and development managers who degrade relationships within and between teams should be shown the door. Seriously, just sack them. For some reason, legacy companies are especially bad in this way. I’ve never worked in anything other than software development organizations, so I’m not sure if the divide and conquer pattern has some sort of a Darwinian net sum gain for other types of organizations, but in software engineering organizations, it is just awful.
In summary here are a few team curation tasks that are often ignored:
Is the team making sure people aren’t writing code solo in areas they don’t understand? - This happening is a strong sign that the team doesn’t have ownership of the codebase, they probably take the blame for when something goes wrong, but no sense of ownership or craftsmanship.
Do the team members like each other, do they naturally work together to solve problems? - A common anti-pattern here, driven by Jira metrics, is for the team members to mostly only “collaborate” when it comes time to tepidly peer review and apply a rubber stamp so they can get back to working on their Jira tickets
Does the team systematically onboard new staff? - Again, if this is lacking it really speaks to a lack of ownership because the team doesn’t really care if the new guy wrecks the codebase - not their problem, it’s the new guy’s problem
Finally, there is the difficult work of removal of team members that just can’t do the work needed. We’ve all worked with these people, for one reason or another they are just way out of place. For me it was a guy who got hired and he had spent a week chasing a missing semicolon in a C++ header file. He had 100+ errors and was fixing them by adding semicolons in files that included the header file. I helped him fix the root cause, but that and other similar kinds of fundamental misunderstandings about classes and instances of classes really indicated that he wasn’t ready to write code professionally. He wasn’t the last example of this problem I ran into in my career, and most times the situation was never resolved by management, in fact 9 times out of 10 it was resolved by the team simply suffering in silence until circumstances moved the person on to their true calling.
The reason removal of bad engineers is so important is because mayhem has an outsized effect in both the physical world and the virtual world of software. Teams that have engineers introducing too much mayhem will never be able to get to nirvana because it takes so little effort and time to destroy code bases in ways that will never be fixed. The survival of the product depends preventing incompetent engineers from introducing change. This is where a caring, competent development manager steps in and handles the situation. There are many tools at the manager’s disposal, it could be sending the engineer to get some key skills training, or transferring them to a team where their skills fit, or helping the engineer to move on to an opportunity that is a better fit elsewhere.