Conflict often feels persona. However, the source of conflict is often not. Different goals and priorities create structural conflict– which can then spill over into acrimony and blame. People focus on personal differences rather than the real source of friction. Let me illustrate with a story.

I recently talked to two groups who were feuding. On one side were the development teams, tasked with delivering new functionality every two weeks. On the other were the operations folks who were charged with keeping the environment stable and available. Simmering resentment was getting in the way of working together. People were talking through proxies. Both groups made insulting comments about the other.

This is not the first time I’ve seen development and operations at odds. They often have different professional points of view, and different goals. Such conflicts are structural. They arise from the way work is organized, not from any personal animus. But, when people don’t realize the source of the conflict, it tends to feel personal. People on each side of the conflict start talking about “those people,” as if the people on the other side are stupid, bad, or wrong.

Welcome to the fundamental attribution error. The fundamental attribution error is explaining others’ behavior as resulting from personal characteristics and ignore the role of external circumstances. Few people have evil motives, are intentionally blocking progress, or are as dumb as dirt. Most people employed in software development  are reasonably intelligent, well-intentioned, and come to work wanting to do a good job.

Given the build in nature of this particular conflict, how could I bring these two groups together?

Structural Conflict

Differences can be a source of strength and creativity rather than conflict. Many structural conflicts dissolve when people re-organize around a shared goal. Harmonizing different professional concerns for complementary action, recognizes that each is essential.

In this specific case, the structural conflict between the development (dev) and operations (ops) groups wasn’t going away. Their work had different rhythms and needed different skills. However, these two groups did need to find a way to dial back the conflict, appreciate each other, and work together reasonably well. (At the time, the concept of DevOps hadn’t yet become widespread.)

I needed to find some bridges.

Acknowledging Differences and Finding Similarities

In cases like this, I find it helps to look at how the groups are similar and different. So, I asked the groups to work together to make a list of their similarities and differences.  

As the list of differences grew longer, I worried we wouldn’t find some area for negotiation. They’d listed differences inherent in the work or related characteristics that differed between them.

The Same list is usually where people find common ground. But in this case, everything they’d listed was abstract and Mom and Apple Pie. There wasn’t enough to bridge the chasm.

Then, one of the ops specialists busted loose. He started listing all the ways the dev teams failed to prepare for production turnover. It was a “you don’t care about quality” moment.

It was also (with a little reframing to get the blame out)— an area where the two groups could work together. Redefining “done” and making a production checklist gave them a chance to work together on a small, bounded project. As they worked together, they got to know each other as people. Both groups gained valuable understanding of the others’ challenges. They can to understand their different concerns added up to a similarity: “Our work is critical to the business.”

Conflict resolution in the workplace can be made easier with the right tools. If you find your group in conflict with another, try this exercise to bring some needed coherence.

Running the Same And Different Exercise

1. Discern that it is a structural conflict

First, discern that it is a structural conflict. Everyone in a company may have a goal of “producing valuable products profitably,” but at a department level, groups may be at odds. In the example above, one group focused on creating a stable production environment. The other aimed to put new features into production every week. In another company product development sought innovative partnerships, while the legal department wanted to eliminate risk. When the common goal (company success) isn’t visible in the day to day work, it can show up as conflict. Both developers and auditors want the company to be successful, however their roles in meeting that goal, which often feel at odds.

Here’s another check. Some structural conflicts are self-imposed, as when testers and developers report to different managers and are measured differently. Testers and developers do have an interdependent goal: it takes both testing and development skills to deliver a complete and reliable product. If you bring together both on a cross-functional team, the conflict usually dissolves.

If you feel it really is a structural conflict, find someone neutral to facilitate the session. Having a neutral third party present feels more balanced. Get both groups in the room. Avoid recrimination and blame, and establish ground rules to keep the discussion productive:

2. Establish ground rules

Set ground rules at the start. At a minimum, seek agreement on the two below. Then invite the group to add candidate ground rules. Then help them agree on no more than seven.

No labels. That means neither group can say the other group is lazy, sloppy, or a bunch of slackers. Positive labels aren’t much better; they don’t give specific information, and they imply that one side is empowered to evaluate the other. The power-difference message comes through whether the labels are negative or positive.

No characterizations about motives or intelligence. Remember the fundamental attribution error. People (and groups) tend to develop stories that explain other’s actions based on character flaws. This goes into over-drive when in conflict situations. Over time, these stories may evolve into harsh judgments about the others’ motivation, intelligence, and general fitness as human beings. Judgments show up as statements such as “They don’t care about quality,” “They don’t get it,” (and worse). Stepping out of judgement makes resolving conflict easier.

If people in the group fall into a judgement, invite them to reframe. For example, if someone says, “They don’t care about X,” rebuild the sentence as “They have a different perspective on X.” Rebuild “They don’t get it” to “They don’t see it the same way I do.” Which might just prompt someone to think, “And I bet I don’t see it they way they do. don’t.”

3. Make two columns labeled Same and Different

Make the lists. Write down all the ways the groups are the same and how they are different.

Consider these questions to help the group process the list:

• Which differences can be negotiated or changed?
• What differences seem most significant?
• Which similarities and differences help us do our work? Which ones get in the way?
• Would it help us do our work if we were more the same? More different?

4. Discuss and reflect

Not all differences make a difference, and not all differences can (or should) be eliminated. We need different skills, different points of view, and different professional concerns to create valuable products.

Look for common ground. Find was to dampen negotiable differences that are getting in the way. Look for similarities to build common ground or recognize shared interests.

Individual differences can make for stronger teams. Avoiding conflict isn’t the objective. Navigating it effectively is.

How did it work out for the devs and ops teams?

Even the best of conflict resolution methods can’t solve structural conflicts overnight.

These two group haven’t completely healed their rifts–yet. Letting go of the belief “those people” are [fill in the negative descriptor] takes a little time. Their conflict likely can’t be completely resolved–unless their functions start working together much more closely. What’s necessary is that they find a way to cooperate and coordinate in a way that meets the goal of delivery and stability. And that requires recognition that different goals and different work lead to different priorities and arrangements. But that does not imply anything about intelligence or motives.

Finding something that the two groups can work on together starts building connection and trust. Then, when conflict arises again (and it will) they’ll have some common ground to land on (the similarities) and at least one experience of working together.

Sometimes, fate intervenes to give two groups a common goal—like a fire or flood in the office. After fighting fire or flood, groups tend to see each other as real human beings, not the sum of misattributed characterizations. I don’t wish fire or flood on anyone, so look around for additional natural opportunities for to work together—but don’t start fires.