I agree with the author's advice, but a part of me can't help but feel that "picking your battles" is a sign of a poorly functional team.
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.
> It's crazy to pretend like a software team will not have disagreements from time-to-time.
Sure you can have disagreements. So then you all present your arguments figure out which way forward is the best with as little ego thrown in as possible and move on.
Right now I'm involved on the side with a project where a ton of decisions have already made. I can choose to (1) accept this and be of help as good as I can or (2) revisit every decision already made and to argue about them.
My attitude is to choose (1) wholeheartedly because that's much more useful than (2) even if I might be right about some of those decisions.
If a choice is an existential one (as in, the company depends critically on the right choice in the longer term) then by all means, spend a great deal of time on the decision. But don't turn each and every choice into a 'my way or your way' discussion. It's pointless, it takes up way too much time and in the end a way is usually far more important than the way.
> So then you all present your arguments figure out which way forward is the best with as little ego thrown in as possible and move on.
If you're dealing with people, then you are going to have problems with ego. Sure, it'd be great if everyone could lay down rational arguments, then come to a rational decision and rationally agree to move forward. It'd also be great if the unicorn færies showed up to take us all to Neverland. People have emotions; they hold grudges; they feel that fairness demands that if they yielded last time then someone else should yield next time; they have genuine differences in opinion and perspective.
A lot of software is art: there's no mathematically correct answer, just æsthetics or style or simply choice. People will disagree about which choice to take; they will feel ignored if they don't receive validation from time to time.
Now, an individual can choose to swallow his ego, but it's not pleasant — and frankly sometimes it's bad for the product to be quiet and let poor decisions move forward.
There are team players and there are solists, it's rare to find people that can be both.
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.
> There are team players and there are solists, it's rare to find people that can be both.
I think you're trying to fit human beings, which are extremely complex creatures, into an artificial black-or-white definition. I would even argue that no one in the world is exclusively a soloist or a team player. Most people, if not everyone, adjust their attitude to who they are dealing with.
For example, a given individual may be a soloist on one team, but a team player on another team, based on the experiences they have had on said teams. They also may be a soloist when dealing with someone they don't respect, or a team player when dealing with their boss. Just examples.
Any thoughts on where the best opportunities for those you'd describe as solists (not a term I've heard before -- I initially read it as "soloist") currently lie?
I'd say it depends on just how much of a 'not team player' you are. If you want to be completely independent, developing small mobile apps, mods for games, Wordpress/Bootstrap themes, and projects like that where you can work for yourself and by yourself might be ok. If you want to code alone, but you can handle having a customer having the final say on any decision they care about, you can become an independent consultant/contractor. Next rung up on the teamwork ladder would be your typical open-source or small-business projects, where you work by yourself most of the time but your work needs to be reviewed and sometimes changed, and others will typically have the final say on decisions.
You say "best opportunities". If you're looking to earn a good living, that's hard to do solo. Very few people are good at all of the tasks that go into software development (and I'm including the non-development tasks, like sales and marketing of both the product and your development skills here). Also very few people manage to create a runaway viral hit on a small application (like Flappy Bird), where your solo work can earn enough so that you don't need to worry about making a good living on the other solo projects you choose to work on. For most developers, learning to work on teams with others is a crucial development skill.
One possible opportunity for a 'solist' could be so-called DevOps positions. They are often structured more as a group of loosely cooperating people working on independent tasks. You will get a lot more say in HOW you do things vs a traditional software development team. You will of course have to deal with doing Operations like work in addition to the development (how much vary a lot based on the company/job).
This is where I've ended up due after many years as a software developer at start-ups because you can land a more stable job that pays better while not being driven crazy by micro-management.
Please, we should not be so dismissive. "Great team" commonly refers to output, not internal organization. (At least if we use a charitable interpretation. And if we don't, we're in the uncomfortable position of demoting many teams from "great" once we learn of their internal dynamics.) Many teams even often seem unaware of their dysfunctions.
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. After all, once you think you're perfect, you're in trouble. (http://model-view-culture.myshopify.com/products/your-startu...)
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.
> "Great team" commonly refers to output, not internal organization.
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.
Completely different context, but still a creative team, look at musical groups like the Ramones, Fleetwood Mac, many others who could hardly stand to be in the same room together offstage but still managed to make some great music. Dysfunctional groups can still do great things.
I don't actually think it is all that different. The point you are inadvertently making is that when it mattered (on stage and while practicing) they were performing well as a team. That they didn't like each other outside of that didn't matter much, just like I don't need to personally like my colleagues in some IT project and that I don't need to hang out or spend time with them outside of work.
In fact, I think that 'work / life balance' is precisely there, because teamwork costs energy and spending time away from each other is as important as spending time together, and there is more to life than code.
A couple of years ago I spent some time re-factoring a huge code-base that had totally gone off the rails. The guy that ran the project and I clashed quite badly when it came to the code and our approach to it (but since he asked me to help it was fairly clear that he was out of his depth from a programming perspective). When I got there there was no version control, the code was a giant hairball and literally nothing worked.
We spent the better part of two years untangling the mess and at each and every turn he'd dig in and make progress just about impossible. I tried very hard to keep my cool in all this and to just resort to facts rather than ego and I think that's the only reason that we did not end up in an actual fight.
Being a team player can be super hard, especially when everything is phrased in terms of 'your way or my way'. It eats up a huge amount of energy that could be used more productively and it tends to make it hard to leave the job without taking it home every day.
>Being a team player can be super hard, especially when everything is phrased in terms of 'your way or my way'. It eats up a huge amount of energy that could be used more productively and it tends to make it hard to leave the job without taking it home every day.
The hardest person I had to work with was someone who was super picky about using the right words for all social situations. If you referred to something as "your way" They would make a rather large deal of it. Most of the time, I was just trying to identify one of the two choices.
I mean, uh, the person in question was certainly worth working with, in spite of their social issues, and certainly, learning less confrontational language, you know, language less likely to set off other people is a worthwhile goal, but my point is just that if you spend too much time concentrating on the connotations of the words, rather than on the denotations, well, you can become pretty difficult to deal with for anyone who isn't used to walking on your particular brand of eggshells. Yeah, if you are good enough, we'll deal with it, but don't pretend that making a big deal out of connotations rather than denotations makes you easier to work with. It's quite the opposite.
I mean, I totally agree that minimizing ego should be a goal... but I also think it's disingenuous to pretend we don't have ego at all. We all have ego. It sucks. but it is. lying about it won't help. Acknowledging it and trying to move past it might.
Only if you assume that dysfunction is either a steady state and does not fluctuate, or that there exists two binary states of function and dysfunction, and nothing in between, or both.
If either of those are true, then it's possible to be on a great team (which is itself relative), and still either have aspects that are dysfunctional, or periods where it goes into dysfunction.
> Sure you can have disagreements. So then you all present your arguments figure out which way forward is the best with as little ego thrown in as possible and move on.
Sometimes, when that decision keeps coming back to bite you, and possibly you in particular, you feel the need to keep bringing it up, so others know it's an ongoing problem. That can be seen by others as someone not letting a decision go.
Does that engineering choice that resulted in a somewhat frail system keep coming back to bite you? Congratulations, now you're presented with keeping your mouth shut and just fixing it every time it breaks, or speaking up when it breaks so that people know it's a continual problem, and risk others thinking you are just complaining more, and promoting team dysfunction, or some happy medium, but where is that medium?
This is why it is important to keep meeting minutes and do a post mortem in case something goes wrong. Not to lay blame but to be able to figure out how a wrong decision was reached so that similar decisions can be avoided in the future.
Re. whether teams are steady state or not:
I don't think every team can be fixed and I'm pretty sure that a single toxic new hire can potentially derail any successful and well oiled team.
Even so, many teams that do not perform well can usually be salvaged and teams that already work well are best left alone (and should do their own hiring if the org allows it).
I'm not going to pick any battle. Because I don't believe that is the way forward. I'll inform and I'll produce but I will not confront or invest my ego into which path is chosen. And in the position that I'm in right now I will simply produce.
That's because this is the best way to contribute to a team effort that is already underway. If and when my expertise is required for something I'm quite sure the other team members will know how to reach me.
I think we're done. Your categorical un-charitable interpretation of my comments and persistent use of straw-men in this thread make be believe that further interaction with you is un-productive.
I'm not sure what you intend to gain with misinterpreting what I wrote but it makes no sense to me. Enjoy HN.
The point, though it's clear that you're belligerent enough to avoid understanding it, is that there's plenty of exceptions to the specific point of view you're trying to put forward as the correct one.
The irony, here, is that you continue to explain your position as different from the article's author, then upon elaboration it's clear that you're disagreeing with her terms by some strange default.
Or you can 3) pick some of the most aggregious issues if there are any and try any of the suggestions in the OPs post that can effect positive change. Not having conflict isn't some higher order way of being a human being, it's a march towards mediocrity. Otherwise, I think you're just trying to be disagreeable with the OPs post cause you both seem to believe the same things :-)
Having disagreements doesn't make a team dysfunctional. On the contrary, a healthy team (or marriage btw) includes people bringing up disagreements and learning from each other to resolve them. Without this process, then the team is unable to bring its members' expertise to bear in avoiding poor decisions.
Hmmm. I wouldn't define a great "team" as dysfunctional. Some might point to "high-performing" teams and say something like "well, their results are good even if the tensions are high." To that, I would respond, what would happen if you lowered the tensions? Might performance be better?
Also, on another note, what constitutes "conflict" varies from team to team. What looks like heated debate to some might feel like healthy discussion to another. It is relative to people's perceptions.
Whatever else is going on, I feel a great team ships, reliably, repeatably.
Much can be, has been said about team formation, I only have two contributions.
Empowering individuals is magic. When every team member is emotionally invested, committed to the shared success, great things can happen. I tried to accomplish that thru building trust.
I've sought to do this thru democracy in the workplace. Most of my team's decisions have been done via voting. Roman Evaluation for hiring, go/no go decisions. Approval voting for bug triage. JADs for project scope. Averaging everyone's estimates for schedule. Individual essays then shared with the whole team for post mortems. Etc.
Basically, I did whatever I could to build trust within the team(s) and beyond. For my role, that mostly meant honoring, enforcing the team's decision making (vs pulling rank).
No, it will still be confrontational and that's not how you approach these things.
If you have issues with how the team makes the decisions you have to tackle the problem at the root, rather than to make each and every decision a point of conflict.
I don't think that's what the OP is talking about. It's not a battle unless it's a batte, non functional teams will have more of these than higher functioning teams, but the advice is geared towards those times. Going through positive battles, winning and losing "the right way", that's how you're either going to change dynamics in poor teams, or conversely, how you're going to let bad actors put themselves on blast / realize you're part of a toxic org that you need to get out of
"Not every battle is going to be a winning one, and understanding when to challenge a teammate and when to hold back is a skill that can only be developed with practice. The battles I’ve lost by not being prepared, the battles I’ve lost by picking on something trivial, and the battles I should have started—but didn’t—are what inspired this blog post."
"The more stressful a situation is, the more I find pragmatism is the best tool for improving the product and the team. What are your strategies for choosing when to push back and when to let it be?"
Think of it as a mindset. OP is still sketching things in these terms and has not moved beyond it. That is where the problem lies. Not in not being prepared, by arguing about something trivial or by battles that were not started but did not.
As soon as you start phrasing things in these terms everybody loses.
My observer take is that you two (and perhaps others) seem to disagree on the definition of the word "disagreement" (haha).
Jacques appears to take a view that disagreement (or "picking battles") is tantamount to a fist fight, which obviously should be avoided. But, I think the OP and others discussing here rather think of of it as merely a difference of opinion, to be noted and moved past.
In that sense, "avoiding disagreement" is not helpful because they are not noted, but buried.
If the stakes are non-trivial, it's normal to have disagreements about how to proceed, and ultimately a decision needs to be made.
If you have an environment where everyone is just getting along and there's no conflict at all over major decisions, either no work is getting done, or the observer is blissfully ignorant of the conflict going on. Part of being a "highly functioning team" is that people pick their battles and don't bicker over unimportant things. "Battle" doesn't mean a screaming match -- just a disagreement that needs to be resolved in one way or another.
If you look at really poisonous workplaces, you'll usually find that there's alot of micro-management/supervisory control over all decisions, and the minions adapt by fighting over bullshit to "look good" in front of the micro-manager and ultimately get their way. Also, bike shedding (aka Parkinson's law of triviality) is a handy technique for concealing bad news.
Patrick Lencioni has a few great of books on this. If you like narratives or "buisiness parables" then read The Five Dysfunctions of a Team. If you prefer a more direct/didactic style, then read The Advantage.
Difficult Conversations from the Harvard Negotiation Project is also a useful read.
Agree, to an extent. But, even if you're direct team is highly functional and open to suggestions, it is unlikely that the entire organization is highly functional. This might not impact a fairly junior developer much, but a tech lead, architect, project manager, or product manager all have to coordinate with other teams that might not be open to change.
I think that's what the author defines as a "winning" battle. Notice that "winning" and "losing" in the article are NOT "my idea won" and "my idea lost", but rather... "bringing this up netted improvement" and "bringing this up netted bad feelings".
I'd add this: if you are lucky, your team starts with good levels of rapport, trust, and open communication. If not, I'd recommend putting consistent effort into growing those -- which can happen a little at a time. I might even recommend making time to talk about these topics directly.
Agreed, I'd put it even stronger: if you feel that those are not where you want them to be stop whatever you're doing and get those hammered out, spend a day, two or even a week figuring out what causes the problem, propose a way to deal with them and then restart the work.
Re-evaluate after a month to see if the chosen strategy works.
Building things when those important elements are missing will translate into building things of low quality and with potentially large problems, which may require costly re-work in the future. In a situation like that it is more often than not more productive not to build anything at all until those issues are resolved.
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.
The article strikes me as immature responses to immature behavior from others. It's a How-To for creating a caustic environment.
Try this:
def leadership():
while true:
have_clear_goals()
articulate_goals_clearly()
There is other stuff to good management, sure. But this will go a long way.
The section on "when someone makes it personal" really irks me. It should never be personal in a healthy organization. You can vigorously debate the design, the implementation, or any other issue, while keeping the focus on the issue. It never needs to be personal. If it ever gets personal, a manager must step in and immediately squash that and make it clear "That's not how we debate things here. Personal attacks are unacceptable. Focus on the issues."
But, really. Just have clear goals, then most decisions will make themselves. Debates can be settled by measuring alternatives against the goals. If, when measured against the goals, there is no clearly winning solution, then which one you pick probably doesn't matter, so everyone should stop wasting energy on decisions that don't matter and focus on the ones that do.
I have observed at least 100 teams over the last 5 years. At any given time I'm coaching 4-10 teams. Every six months or so I get new teams.
The number one problem I see is a lack of clear consistent communication of leadership's intent and values.
Disclaimer: I might be hypersensitive to this because of my military experience.
Complex adaptive systems of humans are always searching for systems with which to signal fitness and interpret fitness signals from others. If leadership does not pound these into the organization from their unique vantage point then the system will adopt its own in the vacuum. Rarely does such a scenario turn out optimal for all participants (for reasons beyond the scope of this comment).
It is interesting that you mention military experience. The best manager I ever worked for had been an Israeli commando officer during the military service portion of his life. (If you remember the rescue at Entebbe, he was in the "Plan B" unit that was staged and ready to go in without the element of surprise should Plan A fail. Happily, Plan A worked.)
So what made him a great manager? 1) You never had any doubt in your mind whatsoever what he wanted and when he wanted it. 2) He then asked you if you had everything you needed to get the job done. And then he listened to what you said until he was certain that he understood, and got you what you needed or adjusted the plan.
When you think about it, failure to do those two things as a commando officer means having to write unpleasant letters to parents.
I mentioned this to another friend, also ex-commando (Royal Navy Special Ops Diver "We taught the SEALs how to do it.") He told me he often spent days thinking about exactly the right words to articulate the goal to his unit.
Here's the mission, what do you need for the mission, and if all else fails here's my intent.
People think the military is full of mindless robots but in reality that's just how you're treated during indoctrination. Combat leaders must enable their people to thrive in chaos.
People (and I include myself) are lazy and will present that laziness via technical arguments and pretending not to understand/remember what you are saying. It's the steady string of previously debunked straw-man arguments or orthogonal unrelated objections that is the tell tale signal. If you keep pushing you are just burning relationship currency.
If you dig in for every single little thing your going to be the bad guy org wide because people don't have enough context in most development workflows and aren't going to put in the effort to understand the technical or timeline issues at stake. You will just be the one who makes a fuss all the time. I've watch some solid people get pushed out due to this.
As long as the harm is minimal I'll point it out and let it slide if the objections go off the rails even if the cost to do it right/better is less than the value realized from doing it right/better. Discussion isn't free. When the cost of dragging the discussion out is commensurate to the harm or value realized then that is when I will tax both myself and others involved in the discussion to address it.
This is one reason to have these discussions before code is written and people are invested in not having to make changes. If you are brutal and break things down into small chunks delivered regularly the latitude for things to go sideways is reduced and discussion is more productive.
Exactly, that's the key insight to have. Making the discussions more important than the project is a pretty good way to derail anything, there has to be some sense of proportionality.
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.
>If you feel the direction a project is going in is not to your liking you can always quit.
Sorry but that is terrible advice. Most people would be out of a job with that kind of attitude.
>But leave the war and associated terminology and attitude out of it.
Nobody brought it in in the first place. The terminology was in quotes, to explicitly indicate that its not used in the dictionary meaning of the term.
> 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.
Sure, that looks excellent on paper, but I have found that it doesn't work with actual humans who are actually very _human_ with all of the associated (incl. negative) traits that humans have in varying amounts including pride, pettiness, jealousy, egotism and others. It has very hard to pickup on those because not everyone will display these traits overtly. They will mask it under other rationalizations or explanations or "objective arguments", or what have you. Many people are just sensitive like that. You can try telling them that their work needs fixing in the most gentle, objective way possible, but all they will hear is "XYZ thinks I suck".
>If that happens too frequently then maybe ask to be transfered to another team or maybe leave for another company.
Wow. Much of your comment reads like this to me - "This what a good team looks like, if you aren't on one, find another team or quit your job"
>Sorry but that is terrible advice. Most people would be out of a job with that kind of attitude.
I agree, and I've had to learn this the hard way after leaving 4-5 separate gigs that went fine for several months until someone new came on, or until an issue came to a head, etc. As software engineers, we have a lot of mobility and it's almost too easy to throw in the towel and move on; in any career, there are going to be conflicts, and you have to learn to confront and neutralize them in a positive way that doesn't involve the departure of yourself or the person with whom you're conflicting. "I'll quit" is too often the go-to and can stifle the development of individual professional conflict resolution skills. That option should stay off the table practically up until the point of complete collapse.
>Sure, that looks excellent on paper, but I have found that it doesn't work with actual humans who are actually very _human_ with all of the associated (incl. negative) traits that humans have in varying amounts including pride, pettiness, jealousy, egotism and others.
Right on again. This is another thing that I had to learn in the crucible after years of reading idealistic navel-gazing in trade outlets and message boards. There was a time I believed that while it required being highly selective, you could get a team together that would hold these values and function without pettiness. I now believe that's not really possible long-term and we must accept the petty and political nature of man as a fact of life (and we should be aware of this nature within ourselves as well, instead of naively claiming that we are above all of it; only regular rigorous self-analysis can reveal the influence of these natural tendencies). Not only is that political nature a fact of life, but it is exacerbated and brought to the forefront by the economic structure and corporate culture that we've developed in the West (which is not to say those things are necessarily bad).
I'd really like to see more content about coping with the reality of what we have in the real world, instead of the fantastic idealistic drivel that makes some tech writers popular.
> Nobody brought it in in the first place. The terminology was in quotes, to explicitly indicate that its not used in the dictionary meaning of the term.
Yes, the dictionary term is related to armed conflict and it clearly wasn't in that sense.
> Wow. Much of your comment reads like this to me - "This what a good team looks like, if you aren't on one, find another team or quit your job"
You could also interpret it as 'this is what a good team should look like, try to steer your team in this direction or alternatively, build your own'.
Leaving is a last option, but it is much better for your health in the longer term if you are happy at what you do and being part of teams that approach their work in the manner described is a great recipe for either a burn out or other serious problems.
See the advice I gave another poster elsewhere in this thread.
The article is unfortunately ambiguous. It's pretty clear from the comments here that there are two different camps in terms of how people interpreted it.
However, it's quite clear to me that the author defines 'winning' as reaching a consensus on one person or the other's point of view, and 'losing' as battling to a stalemate or having one person impose their solution on the other. It's about the team winning or losing (or, to put it in other words, "if we do it well we all win, and if we mess up then we all lose"). 'Picking your battles' is an English idiom that means avoiding confrontations.
It's a little light on specifics, but it's not terrible advice. In fact, it's the exact same advice you are trying to impart here.
Even if you don't agree with that interpretation, I think it behooves you as a HN-famous person to at least consider the more charitable interpretation before publicly branding the author as someone whose "advice could quickly turn a functional team into a non-functional one."
Please consider re-reading the article with a view to trying to understand how other people may have interpreted it, and the author may have intended it, differently. Failing that, at least take some of your own advice and give up your scorched-earth battle to the death with the author and every commenter who read it differently. We're all losing right now.
You put the mood into words quite elegantly. I just couldn't find a way to explain it so thoroughly...
It's terrible when this happens in person, such a painful way to agree and yet become separate.
I don't think we all lose, though. I think these situations result in someone hurting themself more than they realize. I've been there, but I failed to frame things properly.
In person, it's about being as honest as possible, if quiet when there's a complicated issue. Being honest, you can learn in-situ when issues arise, which is very much what Jaquesm supported.
I've felt terrible seeing great engineers leave meetings upset over minor issues.
My concern with consensus, is that most teams are comprised of a single or two senior people supported with a larger number of less senior people.
If consensus is the protocol-de-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving).
> If consensus is the protocol-du-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving).
I don't believe that is true. Junior people are only junior people if you treat them like that. If you are the lead dev and you work together with people junior to you (in experience, possibly not in years) then the fastest way to get them to grow is to get them on-board with the decisions taken as a team.
"Pulling rank" is an option of last resort and it is actually a management failure, far better to spend the extra time to educate your team members to the point where they start making the right decisions. This may require introduction to some of the aspects driving commercial decisions but that's fine.
That's an investment, and in a job market that is overheated you might be teaching someone enough to leave and to go work elsewhere but I've found that this strategy is more often than not rewarded with loyalty.
At least half of these problems boil down to effective communications.
I'm glad you bring up these points. It boils down to viewing conflict resolution as being (often) a temporary matter of information sharing with rationality as the ultimate goal.
People who enjoy having authority for its own sake are usually not good at this, since they think they have earned the right to be authoritative, and resist the dialog necessary to achieve true consensus.
I think he's talking about the support aspect. When a group decision is made, the actions taken are often not a group effort. If the group decided to do X but most of the people capable of acting wanted to do Y, you're going to have problems.
Nothing makes me bristle more than having to clean up after mistake that I warned the team not to make in the first place.
> Nothing makes me bristle more than having to clean up after mistake that I warned the team not to make in the first place.
I call those learning moments. Then I engage the people that made or caused the mistake and I'll help them clean up, rather than that I'll clean up for them. That way the lesson gets learned and the next time around it will be easier, and works a lot better than 'I told you so'.
"Pulling rank" is indeed a sign of failure, especially if nobody on the team has rank because then it becomes a question of who on the team has a "relationship" with management.
I understand your logic. But I think it's not that simple: Part of being a senior engineer (at least for me) is to educate my less senior peers. And in a sneaky, non-condescending way, that is.
It's usually thursday or friday evening that my team will pop some beers and talk conceptuals. In those informal discussions information just flows, sentiments are shared and fruitful decisions are reached.
Winning and losing battles implies that battles exist. That's bad enough for me.
I have never myself seen true consensus work anywhere. It ends with a) one person caving and being resentful, or b) abandoning consensus because everyone realized for important things that it took too long or it never got done.
Even on small teams, it's been a goal, but often we have to say "ok, well you're outnumbered, so unfortunately we aren't taking that direction."
A lot of software is produced in a very bad way. But in my line of business (looking at tech companies) the ones that really get it outperform the ones that don't by a very large margin and there are enough of them to make a real difference.
The machinery of consensus forming requires that people know what they know, and more critically, what they don't know. If a team is unable to determine the strengths and weaknesses of the constituent members then that's a recipe for trouble and this will lead to the frustrations that you outlined.
Let me give you one example of such a situation:
A while ago the front-end of an aging website had to be re-built, it's days were numbered but there were many good reasons to invest some time, money and effort into it but not to go overboard. The programmer hired wanted to do a 'good job' and came up with a whole raft of changes that were totally out of scope for the size change we had in mind.
Instead of forcing the issue I opened the books, calculated roughly how much it would require to do it the 'right' way and how much it would cost if we just did what was needed. In the end the decision was mine but I felt confident that we had achieved enough common ground that to do things 'wrong' no longer felt as bad as if it had felt if I had just told him that since I'm paying this is how we do it.
The project finished on budget, on time and was a pretty good success financially and we both benefited from that.
So yes, it is possible, but it will require an investment in time to educate your team members rather than to 'cause people to cave and become resentful' or to 'abandon consensus'.
I don't think you're describing consensus. I think you're describing the benevolent dictator who listens to his peers and subordinates.
Or maybe we're using different definitions of consensus here. As the OWS and anarchist groups I've come into contact with used it, consensus means 100% agreement for something to move forward.
I think this is a really great article. It's unfortunate that people see a word like "battle" and assume that it is meant aggressively. It is just a theme for highlighting the reality that developers and designers disagree all the time. When you work with intelligent individuals who are passionate about what they are doing, there are going to be strong opinions. These situations can get intense, and it is exceedingly difficult when the other party thinks less of your opinion - like because you're a girl. Solid article on a tough topic.
I agree with other commenters that this is simply too combative an approach. I've personally have had better luck with negotiation and redirection.
I will say, I kinda burned out with product managers that don't understand technical requirements. Or product managers that lacked vision. I'm at a point where I'm pretty much done programmer other people's (uninspired) ideas (and am fortunate enough to be in a situation that allows me this freedom). There's a huge productivity difference when I'm working on a piece of software that I'm passionate about vs an app that consider misguided.
Most of the tensions described in the article are things that I believe can be modeled in terms of debts. It depends on which kinds of debt your team willingly takes on. Most teams take on at least one or two types routinely, no matter how religiously they avoid the others:
Technical Debt:
- build it fast by any means necessary
- use whatever pre-packaged library exists, and duct tape it into your existing system.
Analytics Debt:
- build it without any prior UX experimentation on the design.
- build it without any way to measure key interactions
- have no data about the status quo before you build something new, this will insure that your new feature is a success because the before numbers are unknown.
Marketing Debt:
- build it without knowing whether users want it (or what they want)
- build it without talking to users about their problems.
Spec Debt:
- build it without creating a detailed spec, leaving many important decisions up to the developer, who may not know the full reasoning for what she is building.
- have a print designer do the UX, so that many subtle areas of interaction, animation, and behavior are unspecified.
Mental Model Debt:
- build it without having a hypothesis about why it is helpful and what might need to be changed next. This helps your engineers make choices that speed up this feature but add significant complexity for the next step.
- do not worry about the statistical significance of numbers. Just focus on the direction the numbers are going and be sure your CEO knows how smart you are.
Credibility Debt:
- Don't acknowledge things that have gone wrong (with planning or execution) before. The pretense of infallibility is helpful to creating resentment and mistrust among different divisions of your team.
Kool Aid Debt:
- Whatever you do, be sure it is "agile" or "scrum" because then you have done everything right and you didn't need to worry about any of the above forms of debt.
I think this article misses the point that somethings are also completely right or completely wrong. For example, using string concatenation to build HTML and SQL. This is, just about always, a very bad idea. If a team is entrenched in doing this, it's not going to be a "winning battle" to undo it. You're going to anger the devs by changing all their code or making them use new libraries or whatever, but this is the way it needs to be done.
I agree that approach matters, but let's not call it "battle skills," how about "not being a dick to your coworkers" and "interpersonal skills."
If software development teams really are teams, take it from sports. Sometimes the captain needs to say "this is the playbook we're using, end of story" and everyone needs to trust that they're captain for a reason.
"but this is the way it needs to be done."
Actually, I'd disagree. It doesn't need to be done that way and this is a good example of a battle you're likely to lose that won't really cost you anything (other than some unpleasantness hand crafting SQL queries).
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."
Maybe I misunderstood what you had in mind when you wrote string concatenation but concatenating untrusted raw strings and using a library to construct SQL queries are not the only two ways to produce a SQL query.
On the contrary, if you're working with people that dense, it's very unlikely that you'll make any progress on technical grounds. It's hard even among intelligent people.
The reality is that most people do not make value judgments based on objective criteria of any kind. This is true even among technical people, who rapidly build religious precepts around their nearly-arbitrarily-chosen pet technologies and then discard anyone who doesn't present with the tokens and signs of their adopted technical religion, regardless of that person's true technical ability.
People make judgments based on the amount of personal trust and goodwill they have toward the person making the argument. That's the natural status. With a lot of exercise, people can partially limit the effects of this impulse, but very few train at this in any significant way.
The moral of the story is that the way to win arguments is to be well-liked. It's a popularity contest. If you want people to let you do what you want, you have to make them like you. The objective merits of whatever you're arguing about are practically irrelevant.
I suppose my quick metaphor doesn't hold up under scrutiny. The point I'm trying to make is teams don't (shouldn't) let egos and feelings get in the way. Just because someone likes their code getting rolled out isn't reason to make your analysis of it with anything but cold calculation.
This may be redundant with what others have said at this point, but I think this article is wrong-headed: it perpetuates the idea that you will/should have winners and losers.
The biggest barrier I've found to helping improve an idea is that input is perceived as an attack on the author. And, far too often, engineers will say something like "that approach isn't the right one, this one is", effectively substituting their own solution wholesale for the original.
If a team is ever going to be greater than the sum of its members, it must produce output that is better than any single member could produce on their own. That only happens when you move away from "your approach/my approach" to something like "here's a specific concern I have with the existing approach - how would folks suggest we address it? (here's one possibility)"
I think the article is looking for winners and losers in the wrong place. There will inevitably be winning and losing companies. People that put more energy into making sure that they, personally, win over other people in the organization are not focused on making sure the company wins. Asking "How do I win?" is a very different question from asking "How do we make the company win?".
Your experience/talent should dictate how much you press on an issue, and you should do it professionally regardless (e.g. no yelling, and listen to people; calmly state your point of view).
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.
I'm in the middle of this problem and not sure If I'm doing something wrong.
In the next month we are going to launch a new product, I'm full stack dev and I'm bit frustrated with my colleagues. I did all the devops and all developers(5) has his vagrant per branch, each vagrant box is deployed in one box so they can show to another colleague without trouble (I built a server with the subdomain with the $TASK-ID.subdomain) and the workflow is correct for all of them and they are happy. To deploy to staging/prod we have a full terraform + consul so we're in a happy place.
In terms of code this is painful, they didn't make any test, I made around 50 test 1 month ago to show to them how to make test, but in one month, only one test was added in the project. In terms of the code-review they complain about good indention, and each time that they made a Pull-Request (pep8 and pyflakes) is not passed, and they use to complain about it. They use to mark task as resolved before code got merged, things to weird that I can't explain.
I tried to explain why things need to change, I made a workflow in plantuml and they are complaining that it's too difficult. I'm the only one that made commits in the docs folder.
Nowadays I'm thinking to switch to another company, but I'm happy with my manager (He is too honest), but the team is killing me, and I don't feel comfortable with them, I rarely learn from them and they don't want to do things better, they only want to work to raise money.
You can fix it but it will take time and you will need to be very patient.
(1) let go of your frustration, it is not helping you, if you can't GOTO 3.
(2) pick the best of your colleagues and try to lift him/her up to your level with arguments, not with force (this will take time and oceans of patience)
(3) if that does not work, start looking for other employment, no matter how much you like your boss
(4) if it does work, then now you have a buddy, who already knows your method works, rinse and repeat at (2) until you've either had enough of it or you find that you now have a well oiled team.
Good luck! (You'll need it, this is not an easy thing to do). And if you manage to make this work you are management material yourself.
I think it's not clear if he is the project manager or not. If he has a project manager, then we have to ask why he isn't helping focus the team. Or are they are product a team that is expected to organize themselves.
I agree strongly with #1.
#2 I think it might be good to approach it by asking more questions. If people say it is hard, ask how can we achieve the goal of writing more tests without it being a burden? Maybe OP is perceived as pushy if he's not the manager, or he doesn't allow for enough input on how the process evolves if he is the manager.
Not I'm not project manager, I'm single remote dev. My manager try to the other devs write test, but they said to him that is impossible or too complex. So at that time I spend 2 days and I wrote the test and I wrote a long email with links, howtos, benefits, etc.. Nowadays they still say that it's too complex and no value added. My manager can't say test in all places: they complain about it and I tried the #2 but it didn't work.
#2 worked well with the vagrant box, at first days was too complex, now they loved.. but with test and pep8 code style is a long battle. I think that I'm trying to change how they use to work, and they don't want to change how they work.
I always use to explain that, as a friend, is good for all, but I can't get it.
#1 Yes, me too, but when you reviewed 18 PR in 2 days without good code indention, half of them didn't work and 70% was mark as resolved in the task-manager I need to run a marathon every morning to keep away my frustration. Maybe was that last week I was on holidays and these days I only fixed problems.
I didn't realize it was remote. I think that changes things, since it's difficult to nail the relationship-building part as a remote worker. I think communication is going to be the biggest challenge, particularly if different people don't speak English as their first language.
An email with links and explanations might just fly over the head of a lot of people. One approach I used when working remotely is making short videos, or walking people through things using something like TeamViewer.
Tools are an important part to help a team execute a process, and you even seem to have devised processes ("a workflow"), but obviously you've got no buy-in from the team.
Aim lower. Take your colleagues with you. Step by step. And yes, at first it won't be all "good" in your opinion, simply "a little bit better".
But it seems to me you're trying to impose your ideas in a dictatorial style on everyone else, and at that point you'll meet lots of (ultimately unnecessary) resistance, just because they are uncomfortable with you bossing them around.
I don't think you're going to get a satisfactory answer from HN but I'll try.
It's probably easiest to start with your manager and talk over these problems. Consider how your manager works:
Is he a data kind of guy? Show him how writing tests reduces bugs in the future and speeds development time. How will your changes allow you to ship more features or fix more bugs in the future?
Is he trying to make everybody on the team happy? Ok, see if you can get a few of the more senior people together on the team and talk over the problem in meeting and get everyone to agree on an incremental plan moving forward.
Is your team the kind that tends to hang out together after work? Go out with them once a week, see if you can bring this up in the group casually.
Maybe your boss thinks everything is fine and will only listen if you make more noise? Go into his office and be more direct about the problems you're having.
This also applies to the rest of the team. Consider that they may not see the problems with the project in the same way as you. That's not a bad or good thing, it's just that all people are different. You sound like you're frustrated because it's clear from the facts that there are not enough tests and your team's processes are not being followed. The rest of the team might think that "good enough" is all that is required, and adding more work (even if it reduces workload down the road) isn't a "nice" thing to do.
> I rarely learn from them and they don't want to do things better, they only want to work to raise money.
This is an opportunity for you to learn from them! It's just in areas that you may not be thinking about.
If something is the best way to do, then the one who is proposing it has to convince others usually. More often its about showing them how it can save lots of time in the future. But the reality is that people don't want to spend time unless it has a big business impact and the time it takes to learn/modify is justified by the cost.
Interesting article, I like the focus on interdeveloper relationships. Software is a team sport, there should be more articles on this underserved area. We probably have more text dedicated to tabs vs spaces.
There's nothing caustic about self-censoring when your view isn't worth the headaches it might give others. In terms of development, you have to respect the views of your teammates and the effect of your position on overall workflow.
Edit: for clarity, there's basically one guy here who's made it some sort of vendetta to object to the entire concept of a "battle," as though using that word for a disagreement is the issue. There's no such thing as a "perfect" team, but it seems his idea of that involves consensus.
Consensus is an abstract, reality is defined by multiple viewpoints.
At my current job we have a prima-donna software engineer who wins 90%+ of all battles simply because he throws a giant tantrum whenever a disagreement comes up. People (including the boss) usually just give in to shut him up.
It's to the point people won't critique his work because he gets defensive and throws a giant hissy-fit if you suggest his explosion-at-the-pattern-factory nightmare of a module isn't just the most awesome piece of code ever created.
tldr: We would like to think that all disagreements can be solved by rational reasoning, comparing alternatives and coming up with the best plan of action together. In an ideal world, yes, that would be the case. True, there are teams with perfect chemistry, aligned attitudes and views, no interpersonal friction, etc, but these teams are rare. It is naive to expect that every team to be perfect. We are not robots, and we are not working on some conveyor of code, moving from one to ticket to another, coldly and indifferently. Placing yourself into a position of other person, trying to understand their sometimes irrational motivations, and combining it with assuming the best intentions will go a long long way.
When someone says "there's a better way to do it", aren't they actually saying "[I think that] there's a better way to do it"?
I think I understand that saying, simply, "I don't like the way this is done" isn't helpful, but I don't see how it's necessarily "personal", or rather, that any critique can be anything other than personal. Anything you say is expressing a thing you think. How can it be otherwise?
I have definitely fought hard-lost battles, and everyone came out the worse for them... but it's still hard for me to understand why they happen, because anything you express is, by definition, something you think is true. Leaving out the words, it seems to me, just makes your expression less genuine.
Author here. I like to say 'this way would be better because...' as much as possible. Providing a business case to back up your claim makes it less personal. Receiving feedback is never fun, but IMO it's easier to weather when there's a reason for that feedback being given that's more than someone else's opinion.
Also having coding guidelines/linters is important from transitioning the conversation from 'I think it should be this way' to 'our coding standards say it should be this way' and removing some ego from the conversation.
I am all on-board with reasons with critique. I guess I'm asking about the difference between:
"I think this is good/bad because..."
and
"This is good/bad because...."
The latter one is just dropping words; it's still a think you think, whether you acknowledge that or not.
The hardest battles I've had are dealing with legacy code. The majority of teams want to improve the overall code base and correct past mistakes, but you can never fix everything right now. Deciding when to let the nasty thing lie and when to pay the cost of fixing something is a tough decision to make. Fixing costs are large and immediate but the cost of leaving a problem area is spread unknown across the future. Couple that with fixes that don't actually provide system value except for standardization and you can have all sorts of fun arguments.
This is something you have to decide organizationally. For our part as a frontend team, we've decided when we implement a new feature, it won't be in our old framework. Ever. We've built a way to integrate React into our old world areas of our code. Furthermore, the portion of the old world code that this new React code interacts with will also be converted into React. This way, our code has a sort of 100%+1% movement toward the new framework.
The point is, you need to figure this out as a group and then just implement it as a rule. It can't happen during the code review.
Most of Amazon's corporate principles are a bunch of management buzz words, but situations to apply one of them pop up fairly often in design discussions. "Disagree and Commit"
You're not always going to think that the design the team settled on is the perfect, but if you've laid all your evidence on the table and the team goes the other way, then you go the other way.
Honestly, if there are that many battles in a developer's day, it's a sign of mismanagement. Some bad company leaders think that the right thing to do is constantly have people negotiate over silly details.
I think it's important to keep in mind that the OP is a consultant not a developer at a product company. I'm sure they end up working with external development teams that can't simply be dismissed (or fired), but must be worked with for the good of the customer.
Simply saying "bad management" or "bad hire" takes too narrow a view on software development. The OP is a developer trying to get work done with the team, not a manager with authority over the others.
"He observed that a committee whose job was to approve the plans for a nuclear power plant spent the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the proposed design of the plant itself, which is far more important but also a far more difficult and complex task."
Maybe. The article outlines some behaviors that a good manager would immediately squash. Most people will conform themselves to the prevailing culture. When bad behavior is confronted honestly, squarely, and articulately by a manager, the offender usually conforms to the healthier cultural norms as articulated by the manager. Only if the bad behavior is confronted and still persists can you call it a truly bad hire. In which case it should be dealt with. No amount of productivity justifies being a jack-ass.
At our company code reviews are my way or the highway. Raising objections only gets you negative feedback. It's mostly for coding style, spaces, variable names.
I've been thinking about the word "ideology" lately. What does it mean?
My grandfather was imprisoned by the Nazis and later fought for a Trotskist partisan militia. He hated "communists." According to him (as far as I understood), the defining feature of "communist" was fanaticism. The communists at that time, fighting Nazi & Fascist occupations or orchestrating revolutions under their ideological flag were ideological devotees. We remember Nazism and the madness that took a hold of Germany but I think we forget the context. Other ideologies of the period were less of an evil archetype, but not less devoted ideologically. Often they were just as bloody, if not in the same cold way. The communists that played the archetype role in my grandfather's experience (I assume his comrades, but IDK) must have been very fanatical. "A communist is someone who would sacrifice his mother for the cause" was how he'd describe it. This didn't (as far as I know) have much to do with what we might call "socialist" policy now. This wasn't an opinion about economics or social policy.
Anyway... in a software context, the word ideology gets thrown around, often in a derogatory way. It's surprisingly hard to define it. I think a lot of the conflict points (losing battles) alluded to here are likely to have at least one person pissed off at the other's stupid ideology.
"Agile" is the obvious one to bring up. This is mostly because it has a name, it's been successful enough to have beeen bastardized and tortured many times and it has a manifesto. But there are a lot of things like that.
I haven't come up with a good definition, but I think a good chunk of it has to do with this: Ideology is contextual. When you're argueing for 'X' ideologically, you can't explain your reasons without going into a lot of abstract preamble. This is annoying to the people who disagree with the background reasoning and to those that have never looked into it. To them it sounds like you're saying "just because." Ideological bullshit.
In a political context, one might be a libertarian. This has implications about the legal status of recreational ketamine, minimum wages, building codes, school funding and the approval process for new pharmaceuticals. It all ties in logically to the Libertarian perspective. But, if a libertarian is trying to be centrist, pragmatic, get elected or convince others to make laws then they have a choice. They can be "ideological" and talk about non-coercion or emergence or whatever forms the base of their ideological position. This then becomes about the ideology, not the specific thing. Or, they can talk about the specific thing, the law or policy. They can point to some study on minimum wages and unemployment or innovation and regulation in the pharmaceutical sector or whatever. This often feels contrived. That study isn't what convinced the idealist, the ideology convinced him.
I don't know how this gets solved. I do think that it's important to keep a record though. what ideology do I subscribe to. Realize that when you disagree for ideological reasons, that you are entering tricky territory.
As a side note, common ideologies are great for cooperation.
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.