I wanted to like this article, but I feel that it focuses too much on "winning" and "losing" - building software is (mostly) a creative task, and (I think that) treating it like a series of wins and losses can be a dangerous mentality to start off with.
Finding a creative equilibrium between two ideas is the key to forming the right amount of "creative abrasion", but walking away from every discussion feeling like you won or lost is not going to get you there.
If you're arguing about smaller or inconsequential things like tabs vs. spaces or other stylistic items, you need to spend some time and document guidelines, which should be enforced equally on everyone. This saves tons of time down the line, and eliminates a lot (but, of course, not all) of these problems.
I generally agree, although she does try to redefine winning as a discussion that results in more of a win-win for everyone and losing as an area where someone "wins" the discussion but offends the other party, so it's not quite as contrarian as it seems.
So, I think she means, a win for everyone, and she has the right approach. But I also agree with you, the terminology isn't quite accurate.
I fully agree. When working on a team, you have to think about the future not only the current moment. If every time you have a disagreement it results in a win-lose situation I can guarantee you the mood among the your team will go down quite rapidly. I would suggest 'Getting to yes' by Bruce Patton, Roger Fisher, and William Ury on this matter of negotiation.
But this is one of the things that the article sets out to define! That the work process should not be driven individual competitive arguing (which is pretty much the default mode of interaction for male technical staff), but people need to think about whether the arguments that they find themselves having are worth it for themselves and for the 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 don't know this book - thanks for the advice. I would recommend "How to win friends and influence people", which gives also good advice and a lot of hints.
I agree -- there was also a very "product v. engineering" vibe to it also. Maybe my company is different from most they see, but we don't have product doing code reviews for developers. The place tension can arise seems to be more around the fact that product always wants to move faster and engineering expresses that they can't always do that. I don't think either side is right all the time, but the way the article starts with "Winning battle = product giving into engineering", "losing battle = product being pushed into a better decision by engineering" screams to me of a lack of understanding that in a good organization each party has the best possible information for making decisions that represent the interests of the company from different perspectives, and these meetings are to figure out how those interests align or conflict and sort them out.
Either I completely misunderstood the article, or ...
I also had a similar feeling, and I think it's more productive to focus on results and goals, rather than "winning" or "losing". Nobody wants to be a loser.
Further, I don't like the term battle, as it has a negative connotation, and this is exactly what you need to control or even to get rid of in a team: battle, win/lose, blood, emotions, arguments.
In general I find the article pretty superficial and somewhat biased. In a real work environment you might have the best idea ever that might lead the product/company towards success, however, in front of you there is a senior dev/team lead to convince, and he is defensive and negative (and who knows, maybe he is having a bad moment in his life). How do you "win" this "battle"? By rationally "showing the numbers"? If we were all robots, this approach would possibly work, but in a team of 5 people there are 5 animals with 1) emotions, 2) personal problems, 3) different personalities, with ambitions, etc etc.
Ideally things like tabs vs. spaces, indention levels or bracket styles, etc. are checked by a pre-commit hook so there's never a person being put in the position of choosing between looking like an asshole for picking on something "trivial" vs. upholding standards.
True, but some of this rang true since, in the past, there were certain people I felt like I was competing with. Over time, of course, that gets toxic and bad for business, something which needs a long-term solution.
Finding a creative equilibrium between two ideas is the key to forming the right amount of "creative abrasion", but walking away from every discussion feeling like you won or lost is not going to get you there.
If you're arguing about smaller or inconsequential things like tabs vs. spaces or other stylistic items, you need to spend some time and document guidelines, which should be enforced equally on everyone. This saves tons of time down the line, and eliminates a lot (but, of course, not all) of these problems.