How to Pick Your Battles on a Software Team • Hacker News Board

Re: How to Pick Your Battles on a Software Team

#31

Post by alistairSH » Tue, Jun 21, 2016, 2:45 PM UTC

whack wrote: post #17

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…

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.

Re: How to Pick Your Battles on a Software Team

#32

Post by dj-wonk » Tue, Jun 21, 2016, 2:48 PM UTC

whack wrote: post #17

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…

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.

Re: How to Pick Your Battles on a Software Team

#33

Post by jacquesm » Tue, Jun 21, 2016, 2:50 PM UTC

samlikescode wrote: post #26

nilved wrote: post #18

Earlier quoted context omitted.

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

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.

Re: How to Pick Your Battles on a Software Team

#34

Post by afarrell » Tue, Jun 21, 2016, 2:50 PM UTC

samlikescode wrote: post #26

nilved wrote: post #18

Earlier quoted context omitted.

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

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

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.

Re: How to Pick Your Battles on a Software Team

#35

Post by jacquesm » Tue, Jun 21, 2016, 2:50 PM UTC

gwbas1c wrote: post #22

Honestly, if there are that many battles in a developer's day, it's a sign of mismanagement. Some bad company leaders think that the right thing to do is constantly have people negotiate over silly details.

> Honestly, if there are that many battles in a developer's day, it's a sign of mismanagement.

Or a bad hire.

Re: How to Pick Your Battles on a Software Team

#36

Post by arethuza » Tue, Jun 21, 2016, 2:52 PM UTC

gwbas1c wrote: post #22

Honestly, if there are that many battles in a developer's day, it's a sign of mismanagement. Some bad company leaders think that the right thing to do is constantly have people negotiate over silly details.

"He observed that a committee whose job was to approve the plans for a nuclear power plant spent the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the proposed design of the plant itself, which is far more important but also a far more difficult and complex task."

https://en.wikipedia.org/wiki/Law_of_triviality

Re: How to Pick Your Battles on a Software Team

#37

Post by dj-wonk » Tue, Jun 21, 2016, 2:52 PM UTC

samlikescode wrote: post #26

nilved wrote: post #18

Earlier quoted context omitted.

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

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

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.

Re: How to Pick Your Battles on a Software Team

#38

Post by mathgeek » Tue, Jun 21, 2016, 2:53 PM UTC

nilved wrote: post #18

whack wrote: post #17

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…

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

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

Re: How to Pick Your Battles on a Software Team

#39

Post by afarrell » Tue, Jun 21, 2016, 2:53 PM UTC

whack wrote: post #17

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…

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

Re: How to Pick Your Battles on a Software Team

#40

Post by heartsucker » Tue, Jun 21, 2016, 2:53 PM UTC

Klinky wrote: post #28

heartsucker wrote: post #12

I think this article misses the point that somethings are also completely right or completely wrong. For example, using string concatenation to build HTML and SQL. This is, just about always, a very bad idea. If a team is entrenched in doing this, it's not going to be a "winning battle" to undo it. You're going to anger the devs by changing all their code or making them use new libraries or whatever, but this is the…

What if the captain is the one who says you have to use string concatenation for HTML and SQL?

I suppose my quick metaphor doesn't hold up under scrutiny. The point I'm trying to make is teams don't (shouldn't) let egos and feelings get in the way. Just because someone likes their code getting rolled out isn't reason to make your analysis of it with anything but cold calculation.