Too Many Cooks
I increasingly dislike the team metaphor for collaborative groups. First of all I dislike sports jargon as much as business jargon, and right now software, the industry I work in, is so rotten with jargon and fads that doing even decent work takes a back seat to following those fads and “best practices.” I’m never going to be able to work on a uh “team” even again because any mention of “stories” or “technical debt” (unfinished work) is going to make my head pop.
A team is a group of people who wear the same two colors and compete together against another group of people wearing two different colors. That doesn’t describe any workplace.
And it’s not how I work. I would rather have complete control over one component of a project, usually one or more servers in my case and usually including its/their databases, and collaborate with others who also have ownership of their components e.g. the browser front end.
The team idea would have multiple people working on, for example, the code fo the same server and I guarantee you that will complicate the effort with conflict. On my last job we had a dev lead who was supposed to be a management/development liaison but fancied himself a developer. He was neither, and every time he did anything in my code I had to go in and fix it. I don’t mean reformat it to my liking, though that too, but fix stupid shortcuts and sloppy work. And this thin-skinned lout’s reaction to seeing my improvements (as they indisputably were) wasn’t a learning experience for him, it hurt his fee-fees, which he took out on the rest of us by being uncommunicative and petulant.
I don’t want to be on any “team.” If the project is too large for one person I want to work with people of comparable seniority and professionalism, not jargon-spraying mediocrities. And if the project is something I can do single-handedly, that is my preference.