> 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.

So yes, you have to pick your battles.

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.

Trouble shooter, smaller projects where the output is very well defined (for instance: tuning and optimization), indie games.

> By definition it can't.

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.

The Ramones did almost all their great music before Joey and Johnny stopped talking.

Before that it was a bit of a madhouse, but they got a ton done. Which I guess confirms your point.

It definitely casts the lie to "culture fit." You don't have to be lunch buddies to do good work together.

> > Even a great team can be dysfunctional.

> 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?

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).

Your "(1)" is, by the very definition of the concept, "picking your battles." This is because you aren't pushing issues.

The whole article is about making a way more important, but also recognizing that valid concerns deserve to be addressed.

Balance.

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.

So you don't report bugs?

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.

You're not bonkers, but jayzus you're weird.

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 :-)

Conflict is the end of the line. Disagreement is fine (as is agreeing to disagree), conflict is not.

Disagreement is conflict.

> > Even a great team can be dysfunctional. > By definition it can't.

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.