This is true, but practical. Most people will never work on a functional team.
By definition it can't.
> 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.
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.
So yes, you have to pick your battles.
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.
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.
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.
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.
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.
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.
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.
Before that it was a bit of a madhouse, but they got a ton done. Which I guess confirms your point.
> By definition it can't.
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?
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).
The whole article is about making a way more important, but also recognizing that valid concerns deserve to be addressed.
Balance.
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'm not sure what you intend to gain with misinterpreting what I wrote but it makes no sense to me. Enjoy HN.
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.
You're not bonkers, but jayzus you're weird.
I disagree with this logic. Teams are great if their functionality ratio (functional/dysfunctional) is high and the results are good.
Teams change/vary over time, and therefore you need to have some aggregated evaluation of overall effectiveness.
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.
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).
Little confused.
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.
"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?"
As soon as you start phrasing things in these terms everybody loses.
You're against someone being open when they disagree with something, whether or not their position is valid?
That's a little ridiculous. Being Taoist in withdrawal from conflict is one thing, but being a responsible member of a group is another.
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 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.
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.
Crappy teams build crappy products.
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.