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

101–110 of 141 posts

Re: How to Pick Your Battles on a Software Team

#101

Post by shawn42 »

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.

I think it's important to keep in mind that the OP is a consultant not a developer at a product company. I'm sure they end up working with external development teams that can't simply be dismissed (or fired), but must be worked with for the good of the customer.

Simply saying "bad management" or "bad hire" takes too narrow a view on software development. The OP is a developer trying to get work done with the team, not a manager with authority over the others.

Re: How to Pick Your Battles on a Software Team

#102

Post by jacquesm »

boundring wrote: post #95
jacquesm wrote: post #78

Earlier quoted context omitted.

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 .

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.

Re: How to Pick Your Battles on a Software Team

#103

Post by jacquesm »

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…

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

Yes, the dictionary term is related to armed conflict and it clearly wasn't in that sense.

> Wow. Much of your comment reads like this to me - "This what a good team looks like, if you aren't on one, find another team or quit your job"

You could also interpret it as 'this is what a good team should look like, try to steer your team in this direction or alternatively, build your own'.

Leaving is a last option, but it is much better for your health in the longer term if you are happy at what you do and being part of teams that approach their work in the manner described is a great recipe for either a burn out or other serious problems.

See the advice I gave another poster elsewhere in this thread.

Re: How to Pick Your Battles on a Software Team

#104

Post by jacquesm »

hinkley wrote: post #92
jacquesm wrote: post #29

Earlier quoted context omitted.

> If consensus is the protocol-du-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 don't believe that is true. Junior people are only junior people if you treat them like that. If you are the lead dev and you work together with people junior to you (in experience, possibly not in years) then the fastest way to get them to grow is…

I think he's talking about the support aspect. When a group decision is made, the actions taken are often not a group effort. If the group decided to do X but most of the people capable of acting wanted to do Y, you're going to have problems. Nothing makes me bristle more than having to clean up after mistake that I warned the team not to make in the first place.

> Nothing makes me bristle more than having to clean up after mistake that I warned the team not to make in the first place.

I call those learning moments. Then I engage the people that made or caused the mistake and I'll help them clean up, rather than that I'll clean up for them. That way the lesson gets learned and the next time around it will be easier, and works a lot better than 'I told you so'.

Re: How to Pick Your Battles on a Software Team

#105

Post by jacquesm »

kbenson wrote: post #98
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…

> > Even a great team can be dysfunctional. > By definition it can't. Only if you assume that dysfunction is either a steady state and does not fluctuate, or that there exists two binary states of function and dysfunction, and nothing in between, or both. If either of those are true, then it's possible to be on a great team (which is itself relative), and still either have aspects that are dysfunctional, or periods w…

This is why it is important to keep meeting minutes and do a post mortem in case something goes wrong. Not to lay blame but to be able to figure out how a wrong decision was reached so that similar decisions can be avoided in the future.

Re. whether teams are steady state or not:

I don't think every team can be fixed and I'm pretty sure that a single toxic new hire can potentially derail any successful and well oiled team.

Even so, many teams that do not perform well can usually be salvaged and teams that already work well are best left alone (and should do their own hiring if the org allows it).

Re: How to Pick Your Battles on a Software Team

#106

Post by delecti »

Most of Amazon's corporate principles are a bunch of management buzz words, but situations to apply one of them pop up fairly often in design discussions. "Disagree and Commit"

You're not always going to think that the design the team settled on is the perfect, but if you've laid all your evidence on the table and the team goes the other way, then you go the other way.

Re: How to Pick Your Battles on a Software Team

#109

Post by st3v3r »

jacquesm wrote: post #80
awinder wrote: post #77

Earlier quoted context omitted.

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.

Disagreement is conflict.

Re: How to Pick Your Battles on a Software Team

#110

Post by st3v3r »

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

That's not true.

Post reply on HN