How to Pick Your Battles on a Software Team

If you feel that 'software is art', that 'you are going to have problems with ego' then probably your view is that of the solist, and likely not of someone who would be happy in a team unless they get to call the shots and impose their will on others.

Good teams simply follow the leader and take their paycheck. Great teams cause the team members to grow and will produce work that none of the members individually could aspire to. Great teams know the strengths and the weaknesses of the members, and they themselves know these too.

If you want to phrase working together in terms of 'battles' then you've already lost.

And if you feel that if there is no mathematically correct answer about something, just aestetics or simply choice and the end result is less important than whether or not it was your way or the other persons way then I again conclude that you are most likely not a team player.

And there is nothing bad in that, there is definitely room for solists. But if you are part of a team then you have to play by team rules, otherwise it becomes a war zone with bad results for the project and the health and well-being of the rest of the team.

Nobody needs to 'swallow their ego' in order to present an option, the worst that can happen is that a particular road isn't taken, as long as you don't identify with the road as yours you'll do just fine. But as soon as you see the roads taken as validation of your ego then you are on very dangerous ground.

I'd love to see an example of a team that is internally dysfunctional but that still manages to produce. I've been in this industry for 3 decades and yet I've never seen such a beast, on the other hand - and in the spirit of the argument - I'd love to see examples of this.

> Many teams even often seem unaware of their dysfunctions.

A dysfunctional team means: a team that does not perform (or at least, that's my reading of the word, it does not 'function').

To have some issues that could be improved on does not immediately qualify a team as dysfunctional, that's a pretty heavy term.

> Even if we don't use the charitable interpretation, then perhaps a "great team" would act on the assumption that it is almost certainly dysfunctional, as part of ongoing processes of self-improvement.

Yes, great teams tend to strive to become better (and they usually do). They also tend to leave companies as a unit and move on if they feel they are not appreciated, so for companies there is actually some risk to having a 'great' team, great teams tend to negotiate as one and team members will look out for each others interests.

> After all, once you think you're perfect, you're in trouble.

Agreed.

> And teams aren't "closed". Outsiders (like that contractor or executive from another department) interact with the team and are momentarily part of it. Interactions with them may be dysfunctional, due to culture clashes, inevitable bumps as people learn to cooperate, etc.

That's not how I would define a team but you are welcome to your interpretation and within that interpretation I'd agree with you.

And then you move on.

Over the years I have encountered people arguing passionately about things that, as it turns out, they did not fully understand. It is fine to not understand things but if you’re new to a language/team, you should be saying things like “shouldn’t we do X?” or “I read on [site] that X is better”, and not act like you have found the One True Way to do everything.

Ultimately, you need to communicate some experience/example showing why it is important to do X, or you must be in a position of authority where you can say that you choose X because there is no clear decision among the alternatives.