How to Pick Your Battles on a Software Team

https://spin.atomicobject.com/2016/06/21/pick-battles-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?

这种争论在软件开发团队里面确实很常见.

Winning and Losing Scenarios 第一个问题就是, 如何定义win/lose.

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. 开干之前先问自己几个问题.

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.

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:

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?