7 ms·

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 be

by whack 10y ago

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.

nilved 10y ago
> 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.
- jacquesm 10y ago
  Applying this advice could quickly turn a functional team into a non-functional one.
  - hitekker 10y ago
    Which advice are you referring to, the OP or the parent comment? Little confused.
    - jacquesm 10y ago
      OPs
  - weberc2 10y ago
    Really? It seems like picking your battles can only help make a non-functional team a little more functional.
    - jacquesm 10y ago
      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.
      - awinder 10y ago
        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
      - boundring 10y ago
        "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?"
        jacquesm 10y ago
        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.
  - deleted 10y ago
    [deleted]
- samlikescode 10y ago
  Even a great team can be dysfunctional. It's crazy to pretend like a software team will not have disagreements from time-to-time.
  - jacquesm 10y ago
    > 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.
    - zeveb 10y ago
      > 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.
- mathgeek 10y ago
  I've found that being a parent teaches some of the best lessons about how you can be functional without everyone agreeing.
alistairSH 10y ago
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.
dj-wonk 10y ago
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.
- jacquesm 10y ago
  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.
afarrell 10y ago
> 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.
Spooky23 10y ago
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.
rhizome 10y ago
The key is not to think of an organization in military terms, hence my opinion here: https://news.ycombinator.com/item?id=11919593 https://news.ycombinator.com/item?id=11919593
RangerScience 10y ago
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".

by whack 10y ago

nilved 10y ago

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

jacquesm 10y ago
Applying this advice could quickly turn a functional team into a non-functional one.
- hitekker 10y ago
  Which advice are you referring to, the OP or the parent comment? Little confused.
  - jacquesm 10y ago
    OPs
- weberc2 10y ago
  Really? It seems like picking your battles can only help make a non-functional team a little more functional.
  - jacquesm 10y ago
    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.
    - awinder 10y ago
      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
    - boundring 10y ago
      "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?"
      - jacquesm 10y ago
        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.
- deleted 10y ago
  [deleted]
samlikescode 10y ago
Even a great team can be dysfunctional. It's crazy to pretend like a software team will not have disagreements from time-to-time.
- jacquesm 10y ago
  > 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.
  - zeveb 10y ago
    > 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.
mathgeek 10y ago
I've found that being a parent teaches some of the best lessons about how you can be functional without everyone agreeing.

alistairSH 10y ago

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.

dj-wonk 10y ago

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.

jacquesm 10y ago
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.

afarrell 10y ago

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

Spooky23 10y ago

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.

rhizome 10y ago

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

RangerScience 10y ago

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