How to Pick Your Battles on a Software Team
How about some good old consensus?<p>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&#x27;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.<p>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.<p>But leave the war and associated terminology and attitude out of it.<p>I&#x27;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&#x27;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.<p>There is work to be done, and if we do it well we <i>all</i> win, and if we mess up then we <i>all</i> lose.