How to Pick Your Battles on a Software Team

"Conversely, there are several different conditions that constitute “losing.” The team can lose if you make a teammate feel like their contributions aren’t valuable. The product itself can also lose by missing out on early critique of its features, or by missing an opportunity to have its features developed less expensively."

I'd argue that even with significant opposition, any battle that needs to be won can. "I don't think we should store all the user passwords in plaintext on the server."

The entire premise behind "picking your battles" is that battles are expensive, and hence, you can't afford to fight every battle. But in a highly functioning team, bringing up suggestions and points for discussion shouldn't be expensive. It should be natural and fluid, with every person in the team expected to voice suggestions and concerns whenever they see them. In a team where people aren't constantly trying to jockey for position, where people are open to discussions without getting caught up in their egos, having people bring up suggestions freely is of great benefit to the team and the project.

Maybe the real question that needs to be asked isn't how to "pick your battles", but rather, how to build an organization where people can contribute suggestions and concerns, without getting themselves dragged into a battle.

Battles are not the way to go, regardless of the stakes. If you feel the direction a project is going in is not to your liking you can always quit. As soon as you start phrasing things in terms of battles, winning, losing and so on you're going to end up very frustrated and potentially toxic to the rest of the team. A good team member knows how to make their objections heard without engaging in confrontational tactics and will be able to present their reasoning in non-confrontational fact driven terms.

And is able to accept that they do not always get what they want. If that happens too frequently then maybe ask to be transfered to another team or maybe leave for another company.

But leave the war and associated terminology and attitude out of it.

I've had someone in our little group at TT who would approach each and every little item like a battle and I was very glad when he moved on, it's fairly easy to destroy an otherwise winning team when someone starts to treat the process of software development as something that can be won or lost.

There is work to be done, and if we do it well we all win, and if we mess up then we all lose.