Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Pick Your Battles on a Software Team

spin.atomicobject.com

Post reply on HN
Print view View original

71–80 of 141 posts

Re: How to Pick Your Battles on a Software Team

#71

Post by heartsucker »

jacquesm wrote: post #66
heartsucker wrote: post #57

Earlier quoted context omitted.

>How about some good old consensus? I have never myself seen true consensus work anywhere. It ends with a) one person caving and being resentful, or b) abandoning consensus because everyone realized for important things that it took too long or it never got done. Even on small teams, it's been a goal, but often we have to say "ok, well you're outnumbered, so unfortunately we aren't taking that direction."

A lot of software is produced in a very bad way. But in my line of business (looking at tech companies) the ones that really get it outperform the ones that don't by a very large margin and there are enough of them to make a real difference. The machinery of consensus forming requires that people know what they know, and more critically, what they don't know. If a team is unable to determine the strengths and weaknes…

> In the end the decision was mine

I don't think you're describing consensus. I think you're describing the benevolent dictator who listens to his peers and subordinates.

Or maybe we're using different definitions of consensus here. As the OWS and anarchist groups I've come into contact with used it, consensus means 100% agreement for something to move forward.

Re: How to Pick Your Battles on a Software Team

#72

Post by thwd »

redether wrote: post #25
jacquesm wrote: post #19

How about some good old consensus? Battles are not the way to go, regardless of the stakes. If you feel the direction a project is going in is not to your liking you can always quit. As soon as you start phrasing things in terms of battles, winning, losing and so on you're going to end up very frustrated and potentially toxic to the rest of the team. A good team member knows how to make their objections heard without…

> How about some good old consensus? My concern with consensus, is that most teams are comprised of a single or two senior people supported with a larger number of less senior people. If consensus is the protocol-de-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving).

I understand your logic. But I think it's not that simple: Part of being a senior engineer (at least for me) is to educate my less senior peers. And in a sneaky, non-condescending way, that is.

It's usually thursday or friday evening that my team will pop some beers and talk conceptuals. In those informal discussions information just flows, sentiments are shared and fruitful decisions are reached.

Winning and losing battles implies that battles exist. That's bad enough for me.

Re: How to Pick Your Battles on a Software Team

#73

Post by [deleted] »

jacquesm wrote: post #20
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.

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

[deleted]

Re: How to Pick Your Battles on a Software Team

#74

Post by awinder »

jacquesm wrote: post #62
weberc2 wrote: post #59

Earlier quoted context omitted.

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

Re: How to Pick Your Battles on a Software Team

#75

Post by jacquesm »

arielweisberg wrote: post #70

People (and I include myself) are lazy and will present that laziness via technical arguments and pretending not to understand/remember what you are saying. It's the steady string of previously debunked straw-man arguments or orthogonal unrelated objections that is the tell tale signal. If you keep pushing you are just burning relationship currency. If you dig in for every single little thing your going to be the bad…

> Discussion isn't free.

Exactly, that's the key insight to have. Making the discussions more important than the project is a pretty good way to derail anything, there has to be some sense of proportionality.

Re: How to Pick Your Battles on a Software Team

#76

Post by boundring »

jacquesm wrote: post #62
weberc2 wrote: post #59

Earlier quoted context omitted.

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.

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

Re: How to Pick Your Battles on a Software Team

#77

Post by awinder »

jacquesm wrote: post #33
samlikescode wrote: post #26

Earlier quoted context omitted.

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…

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

Re: How to Pick Your Battles on a Software Team

#78

Post by jacquesm »

boundring wrote: post #76
jacquesm wrote: post #62

Earlier quoted context omitted.

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.

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

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.

Re: How to Pick Your Battles on a Software Team

#79

Post by boundring »

jacquesm wrote: post #33
samlikescode wrote: post #26

Earlier quoted context omitted.

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…

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.

Re: How to Pick Your Battles on a Software Team

#80

Post by jacquesm »

awinder wrote: post #77
jacquesm wrote: post #33

Earlier quoted context omitted.

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

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.
Post reply on HN