How to Pick Your Battles on a Software Team

Creating software is an emotional process for the team members who all want to see it succeed, and this can create tension. The phrase “you have to pick and choose your battles” is commonly used. But, how do you make those decisions?

A photo of Jeanette Head discussing software using a white board at Atomic Object

Winning and Losing Scenarios

When a team is working together, but they are “battling” one another, I like to define “winning” a battle as effectively persuading the other party that your idea will make the software product better. Conversely, there are several different conditions that constitute “losing.” The team can lose if you make a teammate feel like their contributions aren’t valuable. The product itself can also lose by missing out on early critique of its features, or by missing an opportunity to have its features developed less expensively.

A winning scenario:

In a planning meeting, a developer points out that there’s a pre-built charting tool that can do most of the chart’s required features quickly, and the product team says they’re willing to compromise on how the chart labels appear.

A losing scenario:

In a code review, the reviewer pressures the coder to make changes that make a big performance improvement, but the reviewer doesn’t explain to the coder the benefit of making the change, and the coder resents the reviewer for making them do the extra work.

When picking a battle, ask yourself a few questions.

1. Can you win?

If you’re going up against a set direction of the product that’s already been hashed out, and you’ve already raised your concern, maybe it’s time to step back. You probably can’t win.

If you’re a technical leader on the project ramping someone in and they’ve opened a code review that doesn’t follow the standards you’ve set for the project, step forward—but carefully. A conversation is going to be much more effective than tearing apart their code review line by line.

2. Is it worth it?

How severe is the issue to your product? If you want to push back against the business requirements to get the feature done in a more timely manner, take a moment to think about how much time you’re saving. If it’s less than a few hours (and within the estimated complexity), the business requirements aren’t worth changing. If it could save a week of work, though, it’s definitely an option worth bringing to the table.

Imagine in a code review, another developer opens a good PR, but it’s stylistically different from the way you would do it.

Ask yourself:

  • Is your feedback specifically identified as the best practice for your codebase?
  • Is there a non-trivial performance reason to change up the approach?
  • Is the code’s readability a problem?

If none of the above is true, it might be better to let it go. This lets the other developer feel a deserved sense of pride about the good code work they completed.

3. What is the noticeable gain of raising the stakes and challenging someone else’s approach?

In every good battle, the participants fight for something bigger than themselves. While it may not be as epic as a war movie, your reasons for engaging your teammates should also be worthwhile.

When challenging the business side of your project, your goal should be to add value to the product’s reliability and viability.

When challenging other developers, your goal should be to improve the quality of the code that your team is creating, so that the product will be more stable and maintainable.

Choosing Losing Battles

With those questions in mind for picking battles that you can and should win, sometimes starting a losing battle is also important. A losing battle can be a step toward broadening a team’s shared understanding of something that needs improvement.

A losing battle with the product team might be proposing an alternative to a UI you think is difficult to use. Your alternative may not be accepted as the path forward, but on the journey toward realizing that, your team might express interest in doing some user testing to get concrete design feedback and improve the usability of the product going forward.

A losing battle with another developer often manifests itself as a learning opportunity for both parties. Your code may not be as efficient or effective as you thought it was. In some situations, the discussion and research may lead to an even better third option.

Hard-lost Battles

We’ve all seen battles that haven’t gone well. Usually, that happens when someone makes it personal with some variant of “I don’t like your code/design/approach.”

It may have even been you, especially if you were caught on a day that wasn’t your best. We all do it. Just step away when you realize what’s happened, and then come back later with an in-person conversation and try to smooth it over.

If someone else made it personal against you, the best thing you can do is take the time to be angry. Later, when you’re calm, engage them in a personal conversation, and respond to any concerns objectively.

Developing Your Battle Skills

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?

  • Marcus C says:

    Great advice!
    On a practical front, agreeing on a coding style and having the build system automatically enforce it can help mitigate that particular issue.
    No-one likes being on either end of the style police, but people seem to take criticism from automated style checkers less personally.

    There are of course still many other battles to be fought, including the “which coding style shall we enforce” question ;)

    • Andrei says:

      That’s a great idea.. I’m just looking at the jenkins checkstyle plugin right now :D

    • Jeanette Head Jeanette Head says:

      Thanks Marcus! I agree – documenting a coding style and having automatic feedback enforcing simple things is hugely valuable for keeping coding standards up without any of it feeling personal. That’s a great point, thanks for sharing it.

    • Liam Dawson says:

      Part of that, of course, is the consistency. Nothing irritates me more on a personal level, than being subject to criticism and watching others get away with it scot-free. If an automated tool applies the rules, there’s no hypocrisy to worry about – the juniors and seniors are subject to the same standards.

  • Brian says:

    Bullshit. And her github is very poor. But she had been adviced. What??
    The argument simply does not hold water.

    • Bob Loblaw says:

      Thanks, Brian

    • Ell says:

      Sure, what a horrible github, I bet author’s TTL and Neo4j optimisation skills also prevent her from understanding team dynamics.

      I think I would benefit from a bit more examples but it was great to read that battles are just a normal part of the process and fall under the same ‘do what you can do best, accept you won’t always be right, learn, iterate’.

    • Miguel says:

      Brian – I fail to see the relevance of you comments. github certainly isn’t *the* marker for being a role model, a great software developer, or a fantastic contributor to the community. Also, calling something out as bullshit isn’t quite specific enough either. Can you please elaborate? Perhaps write a blog where you share your own perspective?

      • bharath says:

        The problem is what a lot of people do is just talk and talk. Brian, you are an idiot.

    • Tim says:

      Brian, dude, shut your mouth.

    • A Different Brian says:


    • Dan Wiebe says:

      What’s the matter with her github?

      She doesn’t test-drive, sure, but there are a still a lot of folks who don’t. Her repo list shows a willingness to learn new things, which is about as positive as a github account gets, I think.

  • David says:

    Thanks for the helpful post.

  • JoeJack says:

    One thing that worked well on a team I was on was, if two people find themselves arguing an issue, have them give a number from 1 to 10 on how strongly they feel about it. If one person is a 3 and the other a 9, end of discussion.

    • Jeanette Head Jeanette Head says:

      What a great idea – I’ll be trying this one out in the near future. Thanks for sharing!

    • That’s brilliant. Did you have any issues when with who said what and in what order they said it? I could see someone saying “this is a nine for me” and the person who also felt is was a nine for them backing down and saying “three for me”.

      Is there a way to quantify the number with metrics? Now I’m just thinking out loud, but as another commenter said: “what would the app say?”. Granted, this is very case by case, but I’m curious your thoughts on if there was a way to create a number that the “code/application” might say if it could talk.

  • BCovi says:

    Good article but I have to admit that the opening put me off a little bit. Winning is defined as something personal which, in a work place I believe it never should be (“effectively persuading the other party that YOUR idea will make the software product better”) while losing is on a product or team level. It kinda set the tone to me as an “I win or we lose” feeling.
    I’d have to say that its important to know that you don’t have to be the one winning the argument to win the battle. If you walk away having learned something valuable (and are humble enough to learn from it) then you have won something infinitely more important than a battle, you’ve gained experience and knowledge.

    Other than the opening though I found it a good read.

  • Mike says:

    Shame on you @Brian… a public github is not a reflection of an engineer’s background, experience, or skillset. It simply reflects either your generation or your likelihood that you’re working with popular opensource web frameworks. Plenty of organizations run their own github enterprise, or gitlab, or bitbucket. Furthermore, looking at something more important – her LinkedIn… she’s early on in her career but not a neophyte – 4 years in is plenty of time to experience the push and pull between product and engineering teams.

  • Jack says:

    Pretty sure Eli was being sarcastic about Neo4J and team dynamics!

  • Connor Davison says:

    I sincerely worry that you find so much conflict in, what should be, a collaborative process.

    • Jeanette Head Jeanette Head says:

      Hi Connor! I think challenging the opinions of others is part of every collaboration. Certainly the term ‘battle’ is an exaggeration, one that in this case comes from the cliche of “pick and choose your battles”. I hoped that in reading this you would take away a new perspective to use next time your opinion differs from a teammate.

      • Steve says:

        I find this article jumps around a bunch, is the battle member vs member? Member vs team? Team vs project outcome? I am not sure.

        I agree with Connor. “Creating software is an emotional process for the team members who all want to see it succeed, and this can create tension.”, creating software is a logical process for team members who all (should) have researched and collaborated to determine the best approach to solve the problem.

        “I think challenging the opinions of others is part of every collaboration”, data should always be challenged, especially if it’s an “opinion”. I expect my teammates to rip my opinion apart if I don’t have anything to back it up. Don’t be nice about it. Even more so if I don’t have anything to back it up. To feel you contributed is earned.

        Why should I feel I contributed if all meeting or development I supplied nothing but opinion? I don’t want a participation trophy.

        If you have done your research and collected your data then you don’t need to “Pick your battles”. You provide your results to your team, if it’s correct and added great, if not, well, that’s life. You have an obligation to express your findings if it would benefit the project.

        Passion is good but egos have no place, my teammates are not my opponents. I am not going to battle them.

  • Ernest says:

    “Creating software is an emotional process for the team members who all want to see it succeed”. Nice sentance and better post.

    As developers, we have to be the voice of the application. No matters you as a individual. I follow this rule: Would the application complains about this situation if it could talk?

    • Mendevoshkes says:

      I have actually gone ahead and made a feature enabling the application to talk, this feature was rejected by the team as “being completely unrelated to the product”. I now hate everyone.

    • Zvika says:

      +1000000 on
      “Would the application complains about this situation if it could talk?”

      Amazing way of looking at it!

  • Kelly Carter says:

    Great article. So glad you didn’t stop at the proverb “Pick your battles” as if it’s only smart to fight when you can win. To me, that’s a little cowardly. I appreciate your going on to explain that sometimes losing a battle is a movement forward. Sometimes that “battle” is really just planing a seed for a future victory. Sometimes arguments need to be made, positions need to be challenged, even when the cards are stacked against you. And, of course, sometimes you may discover that YOU are the one that’s wrong (or simply have something to learn). And being man/woman enough to realize and admit your mistake is also progress.

  • Nicole Homeier says:

    Great post. Our software team is still small enough that “battle” is thankfully not an apt description. We have “discussions” that have gone well so far. But I have been involved in larger teams where it was a useful metaphor. I love the insight of software creation being emotional for developers as well, it helps explain some otherwise odd behavior. People, even developers and engineers, are not as logical and rational as they sometimes think they are.

  • When picking up battles, which can go either way, playing to your strengths matter a lot. In code reviews, sometimes the reviewer is less knowledgeable than you are, still insists on a change. A really strong developer will be able to see the compromise and “agree to it”, if it is not a harmful change. Whereas a not-so-strong developer, might pick up a battle with the reviewer.

    On the other hand, if the developer is a learner, for any review comment, he should think of it as an opportunity to spend more time and developed himself and address the comment.

  • Andrew says:

    The information provided in this 1000 word blog (and lets face, how much depth can one put into 1000 Words) are terrific. I particularly like that you identify people as having emotions, and that we really need to think about if what we are saying and or doing is adding value to the team / project, or just plain nit picking and decreasing the overall value of the project.

  • Zvika says:


    Great writing!
    I agree with the comments about an automated-style checker, having any automation around code reviews is highly recommended as people tend to take computer-made comments much lighter and conform to those being part of a pre-defined process rather than a personal, possibly ego-driven, opinion or feedback.

  • Comments are closed.