Hacker News Reader

Comment by whack | Hacker News Reader

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.

View on HN

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

This is true, but practical. Most people will never work on a functional team.

Applying this advice could quickly turn a functional team into a non-functional one.

Which advice are you referring to, the OP or the parent comment?

Little confused.

OPs

Really? It seems like picking your battles can only help make a non-functional team a little more functional.

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.

I'm starting to understand your position a little better.

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.

You keep putting words in my mouth, the parent comment is a classic strawman and I refuse to be drawn out into a debate at this level. Good luck.

What strawman?

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.

Even a great team can be dysfunctional. It's crazy to pretend like a software team will not have disagreements from time-to-time.

> Even a great team can be dysfunctional.

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.

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

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

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.

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

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.

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?

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.

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

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

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

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

I've found that being a parent teaches some of the best lessons about how you can be functional without everyone agreeing.

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.

> how to build an organization where...

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.

Crappy teams build crappy products.

The key is not to think of an organization in military terms, hence my opinion here: https://news.ycombinator.com/item?id=11919593

Reply on news.ycombinator.com