People fight about all kinds of things. The desk near the window. Spaces versus tabs. Whether you can play more than three Sex Pistols songs in a row over the office hi-fi.

People are people, and there is always going to be conflict. Sometimes conflict is just noise (see above). Since I’m responsible for the output of the team, I try to end pointless conflict. But sometimes conflict is the most direct path forward. Here are some examples of things worth fighting about.

Business Case Alignment
At the beginning of the project, suppose you have two business stakeholders arguing about whether to build and try a subscription mechanism first, or a one-time purchase model. Well, you need this decision, and it would be foolish to try to address both cases at the same time, since if you test one and it works, then you don’t need to build the other one. So you want them to fight about this early, and have one of them win, so that you aren’t dividing your development capacity in half.

Agreeing on Principles
Suppose you get to the last design review, and one reviewer loves it while the other reviewer hates it. At this point, rather than have a personal conflict over the design, it’s better to go back to the design goals, and determine whether the candidate designs meet the design goals. And if there is going to be conflict, it’s better to collect energy around aligning on design goals (rather than designs). Typically, it’s easier to agree on goals and then measure / evaluate how well a design meets those goals.

Advocating for Users
When we fight about which features to build, sometimes we’re really talking about which users to serve. It’s always a good idea to fight on behalf of your users. It puts everybody in a position to consider the real people that are served by a product, and how to best meet their needs.

Standards and Processes
Developers argue about process all the time. Some things they argue about are religious arguments: such as whether to use spaces or tabs for indentation in code. The only point in fighting about this is to adopt a single standard. So it’s better to have a dictator in this case than a democracy. But when one developer wants to deviate from the standard stack because of a client’s unique needs, this is a debate worth having. These types of conflict are unavoidable and should not be deferred. Deferring a decision just makes the conflict more expensive.

Tools
At Lab Zero there is a healthy struggle for mindshare around valued tools. A Pivotal advocate brings the best plug-ins to round the feature set up to that universal behemoth Atlassian, and we're all better off for it. One designer becomes a fierce advocate for Figma, and leads the migration from XD for her client. During our kickoffs, we settle on a tool set and move forward together. But around the lunch table, on any given Tuesday, the debate is fierce about whether a particular startup really needs Angular, or can get by with React.

We’re always going to fight. Because I know my team is aligned on values, I know they are mostly fighting about things that lead to forward movement and greater value. Let’s learn to connect to healthy conflict so that we fight about the right things, and produce better solutions.