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

111–120 of 141 posts

Re: How to Pick Your Battles on a Software Team

#111

Post by mathgeek »

jacquesm wrote: post #52
zeveb wrote: post #46

Earlier quoted context omitted.

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

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…

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

Re: How to Pick Your Battles on a Software Team

#113

Post by dasmoth »

jacquesm wrote: post #52
zeveb wrote: post #46

Earlier quoted context omitted.

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

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…

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?

Re: How to Pick Your Battles on a Software Team

#114

Post by dbcurtis »

ryanmarsh wrote: post #69
dbcurtis wrote: post #63

The article strikes me as immature responses to immature behavior from others. It's a How-To for creating a caustic environment. Try this: def leadership(): while true: have_clear_goals() articulate_goals_clearly() There is other stuff to good management, sure. But this will go a long way. The section on "when someone makes it personal" really irks me. It should never be personal in a healthy organization. You can vi…

This! I have observed at least 100 teams over the last 5 years. At any given time I'm coaching 4-10 teams. Every six months or so I get new teams. The number one problem I see is a lack of clear consistent communication of leadership's intent and values. Disclaimer: I might be hypersensitive to this because of my military experience. Complex adaptive systems of humans are always searching for systems with which to si…

It is interesting that you mention military experience. The best manager I ever worked for had been an Israeli commando officer during the military service portion of his life. (If you remember the rescue at Entebbe, he was in the "Plan B" unit that was staged and ready to go in without the element of surprise should Plan A fail. Happily, Plan A worked.)

So what made him a great manager? 1) You never had any doubt in your mind whatsoever what he wanted and when he wanted it. 2) He then asked you if you had everything you needed to get the job done. And then he listened to what you said until he was certain that he understood, and got you what you needed or adjusted the plan.

When you think about it, failure to do those two things as a commando officer means having to write unpleasant letters to parents.

I mentioned this to another friend, also ex-commando (Royal Navy Special Ops Diver "We taught the SEALs how to do it.") He told me he often spent days thinking about exactly the right words to articulate the goal to his unit.

Re: How to Pick Your Battles on a Software Team

#115

Post by dbcurtis »

alarge wrote: post #87

This may be redundant with what others have said at this point, but I think this article is wrong-headed: it perpetuates the idea that you will/should have winners and losers. The biggest barrier I've found to helping improve an idea is that input is perceived as an attack on the author. And, far too often, engineers will say something like "that approach isn't the right one, this one is", effectively substituting th…

I think the article is looking for winners and losers in the wrong place. There will inevitably be winning and losing companies. People that put more energy into making sure that they, personally, win over other people in the organization are not focused on making sure the company wins. Asking "How do I win?" is a very different question from asking "How do we make the company win?".

Re: How to Pick Your Battles on a Software Team

#116

Post by [deleted] »

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…

[deleted]

Re: How to Pick Your Battles on a Software Team

#117

Post by boundring »

jacquesm wrote: post #100
boundring wrote: post #93

Earlier quoted context omitted.

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.

Re: How to Pick Your Battles on a Software Team

#118

Post by boundring »

jacquesm wrote: post #102
boundring wrote: post #95

Earlier quoted context omitted.

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?

Re: How to Pick Your Battles on a Software Team

#119

Post by specialist »

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.

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

Re: How to Pick Your Battles on a Software Team

#120

Post by cookiecaper »

ksk wrote: post #89
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…

>If you feel the direction a project is going in is not to your liking you can always quit. Sorry but that is terrible advice. Most people would be out of a job with that kind of attitude. >But leave the war and associated terminology and attitude out of it. Nobody brought it in in the first place. The terminology was in quotes, to explicitly indicate that its not used in the dictionary meaning of the term. > A good…

>Sorry but that is terrible advice. Most people would be out of a job with that kind of attitude.

I agree, and I've had to learn this the hard way after leaving 4-5 separate gigs that went fine for several months until someone new came on, or until an issue came to a head, etc. As software engineers, we have a lot of mobility and it's almost too easy to throw in the towel and move on; in any career, there are going to be conflicts, and you have to learn to confront and neutralize them in a positive way that doesn't involve the departure of yourself or the person with whom you're conflicting. "I'll quit" is too often the go-to and can stifle the development of individual professional conflict resolution skills. That option should stay off the table practically up until the point of complete collapse.

>Sure, that looks excellent on paper, but I have found that it doesn't work with actual humans who are actually very _human_ with all of the associated (incl. negative) traits that humans have in varying amounts including pride, pettiness, jealousy, egotism and others.

Right on again. This is another thing that I had to learn in the crucible after years of reading idealistic navel-gazing in trade outlets and message boards. There was a time I believed that while it required being highly selective, you could get a team together that would hold these values and function without pettiness. I now believe that's not really possible long-term and we must accept the petty and political nature of man as a fact of life (and we should be aware of this nature within ourselves as well, instead of naively claiming that we are above all of it; only regular rigorous self-analysis can reveal the influence of these natural tendencies). Not only is that political nature a fact of life, but it is exacerbated and brought to the forefront by the economic structure and corporate culture that we've developed in the West (which is not to say those things are necessarily bad).

I'd really like to see more content about coping with the reality of what we have in the real world, instead of the fantastic idealistic drivel that makes some tech writers popular.

Post reply on HN