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"
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.
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.
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).
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.
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.
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'.
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."
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.
How about it? What do you do when there is no consensus, because people genuinely, honestly disagree? Sometimes consensus is impossible.
And then you move on.
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.