8 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. This is true, but p
by 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 agoApplying this advice could quickly turn a functional team into a non-functional one.
- hitekker 10y agoWhich advice are you referring to, the OP or the parent comment? Little confused.
- jacquesm 10y agoOPs
- weberc2 10y agoReally? It seems like picking your battles can only help make a non-functional team a little more functional.
- jacquesm 10y agoNo, 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 agoI 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 agoThink 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.
- boundring 10y agoI'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.
- jacquesm 10y agoYou 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.
- boundring 10y agoWhat strawman?
- mixmastamyk 10y agoMy 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.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- samlikescode 10y agoEven 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 agoI've found that being a parent teaches some of the best lessons about how you can be functional without everyone agreeing.