As a manager, one of the trickiest situations to handle is when you and a team member clash over a technical or business issue. What do you do? Do you override them, at risk of crushing their motivation? Do you get into a heated argument? Do you let them go their own way, only to silently stew as you watch them screw up the project? Do you give some mealy-mouthed suggestion, e.g. “I feel like we would be better off if you did it this way…”? This predicament also arises when arguing with peers or supervisors.

A revelation came to me a few years ago when I read an article suggesting that arguing is not about truth. Humans evolved our talent for arguing in order to win allies:

Now some researchers are suggesting that reason evolved for a completely different purpose: to win arguments. Rationality, by this yardstick (and irrationality too, but we’ll get to that) is nothing more or less than a servant of the hard-wired compulsion to triumph in the debating arena. According to this view, bias, lack of logic and other supposed flaws that pollute the stream of reason are instead social adaptations that enable one group to persuade (and defeat) another.

I have noticed this behavior at work. I start a discussion. The discussion turns into an argument. I sense myself becoming defensive. Suddenly I am justifying my own existence and abilities. Opposing arguments are coming into my brain, almost reflexively, outside of my own control. It is like my subconcious is feeding me ammunition for a war. I notice the person I am arguing with doing the same thing, and now I am locked into a hard fight that has strayed far from the goal of figuring out the best solution for the team.

These kind of arguments are poison. It gets even worse in a group meeting when I feel like I am defending my competence in front of an audience.

So what to do instead? Here is a “magic” technique I have discovered for resolving disputes in a productive manner:

Bring up your concern in a non-accusatory way.

Here is a bad way to voice your concern:

Why did you use framework X for this project? I think framework Y would be better.

Here is a good way:

Do you have strong opinions about using framework X for this project? I’m thinking that using framework Y might have some advantages.

The first phrasing forces the other person into a defensive mode. Even if they did not have strong opinions about using framework X in the first place, their subconcious will rally to meet the threat and start generating rationalizations on the spot. The person will feel an instinct to justify their intelligence and decision-making abilities.

The second phrasing allows for an easy out – they can just say they do not have a strong opinion. Nor does the phrasing challenge their abilities, so you avoid putting them on defense.

As soon you sense defensiveness, stop and change tactics.

Once I start discussing the pros and cons of X versus Y, the discussion still might become heated. As I sense myself or my teammate becoming reflexively defensive, I back off. The argument has changed tone and will no longer be productive.

Huddle together and collaboratively examine options.

When the argument becomes heated, I stop and say, “OK, this debate is getting too complex for me to keep straight in my head. Let’s huddle.” We both sit in front of the same computer screen and I open up a text editor. At the top of the document I write the problem that we are trying to solve. For example, “Problem: our web application only supports 1,000 concurrent users and we need to support 10,000”. Then I say, “Let’s brainstorm. What are the ways we can solve this problem?” We enter the options we were arguing about previously, but also generate new ideas. Then under each possible solution, we each list pros and cons. For each con, we go one level deeper and offer ideas on how serious the con is, and how the con could be worked around.

The key is that we jointly create pros and cons for all solutions. In this way, it is no longer “My solution versus their solution.” We both own the solutions, and neither of us risks losing face.

At the end of the brainstorm we have quite a long outline. Sometimes the answer is obvious to both of us once we have enumerated the pros and cons. Sometimes the right answer hinges upon a critical assumption. The next step might be, “Let’s spend a day and run a trial that will test our performance assumptions if we choose option A. If performance is sufficient, we will do option A.” Other times we might remain conflicted.

Search your mind for data points you have not shared.

Sometimes during an argument, I pause, step back, and think, “What is the sticking point of our dispute? Why am I seeing things in a different way than my colleague?” I may realize that I have some unspoken data point in the back of my head that I am relying on. Perhaps I recently talked with a friend about why framework Y was so cool. Perhaps I was on a forum where I saw that a bunch of people were looking to work at a company using framework Y, and I had some vision that we could use Framework Y as a way to attract top talent. It is surprising how often a dispute arises from one person having data points they are not sharing. The solution is simple: Take a moment, think deeply about why you feel the way you do, and share your data points.

Making the call

I have found that after using the huddle-and-collaborate technique, about 90% of conflicts simply melt away (hence me calling the technique “magic” – the dispute simply disappears). The original dispute usually happened because one person had data, perspectives, or work-arounds that the other person was not aware of. Once the pros and cons are visible to all, the right answer is usually obvious.

What about the other 10% of the time when you are still at odds? When in doubt, defer to the person who is actually doing the work. The person doing the work has their head in the problem and is in a better place to make a decision. Furthermore, if you pull rank and then turn out to be wrong, you will crush their morale. Whereas if they make the call, and turn out to be wrong, they will put in the extra effort to make amends. They will learn from the mistake and develop better judgement in the future. Do not compromise for the sake of compromise, as that makes no one happy and only leads to mediocrity.

The cases when you need to pull rank are when 1) being wrong incurs huge strategic costs to the business or 2) you sense that interests might not be aligned between the employee and the company. For example, in software engineering the employee has a personal incentive to try new frameworks and tools. New tools are fun and build the résumé. The company has an incentive to use tried-and-true tools. The company wishes to standardize across teams so that employees spend less time learning and more time doing. So if you sense the engineer wants to try a new tool purely for the sake of learning something new, then you might have to say no.¹

I hope you find this technique useful and good luck with your next argument!