When Conflict Is Baked In: Bridging Structural Conflict

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 and hurling insults.

This is not the first time I've seen development and operations at odds. Conflicts like this are almost always structural. For example, the conflict may arise from the way the company is organized to accomplish work, different and conflicting goals, and different professional points of view. But, when people don't realize the source of the conflict, it tends to get 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. Humans tend to explain others' behavior as resulting from personal characteristics and ignore the role of external circumstances. It's seldom true that people have evil motives, are intentionally blocking progress, or are as dumb as dirt. The people employed in our field are reasonably intelligent, well-intentioned, and come to work wanting to do a good job.

Some structural conflicts dissolve if people are organized differently or when professional concerns are harmonized for complementary action, such as working together to create a software feature. When testers, GUI developers, database developers, and middleware developers come together in a cross-functional team, their differences can be a source of strength rather than conflict.

But, the structural conflict between the development (dev) and operations (ops) groups I was working with wasn't going away. Dev and ops do fundamentally different kinds of work, with different rhythms and needing different skills. However, these two groups did (as they do in most organizations) need to find a way to dial back the conflict, appreciate each other, and work together reasonably well.

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 chart listing similarities and differences.
 

As the list of differences grew longer, I felt a niggling worry that there wouldn't be a difference the two groups could negotiate. So far, the differences they'd listed weren't going away; they were inherent in the work. The items in the Same list were important—that's the common ground where people can land when conflict arises—but this list was very abstract and "Mom and Apple Pie." There wasn't enough to bridge a gaping chasm.

Then, one of the ops specialists busted loose. He started listing all the ways the dev teams failed to prepare for production turnover.

And, there it was (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. Working together on a shared goal would help each group understand the other's context, know each other as people, and understand how their different concerns added up to a similarity: "Our work is critical to the business."

There's some wrangling yet to come before these two groups stand down, join hands, and sing "Kumbayah." Some people may even be reluctant to give up their belief that "those people" are idiots. It is convenient to have someone to blame rather than recognize that some conflicts can't be resolved, and it doesn't imply anything about intelligence or motives. It's not likely—or desirable—that the two groups become of one mind on all things. They do different work; what's necessary is that they find a way to cooperate and coordinate in a way that meets the goal of delivery and stability.

If you find your group in conflict with another, you can try this exercise to bring some needed coherence. First, discern that it is a structural conflict. Conflicts of this sort tend to happen when there are different departments or goals, different professional interests, different types and rhythms of work, and when the teams do not have an interdependent goal at the level where they do their work. Everyone in a company may have a goal of "producing valuable products profitably," but at a department level, groups may be at odds. For example, both developers and auditors want the company to be successful, but they have different roles in meeting that goal, which often feel at odds, i.e., structural conflict.

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. Get both groups in the room. Avoid recrimination and blame, and establish the following ground rules to keep the discussion productive:

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 that are in conflict develop stories about the "others." Over time, these can evolve into harsh judgments about the others' motivation, intelligence, and general fitness as human beings. The judgments show up in statements such as "They don't care about quality," "They don't get it," and worse.

When you catch yourself saying something like "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 you to think, "And I bet I don't see it they way they do. I wonder what they see that I don't."

Make the list. 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?
• Which ones are 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?

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.

The point is to find something that the two groups can work on together to build a bridge. 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.