When Conflict Is Baked In: Bridging Structural Conflict

[article]
Summary:
No two people or groups are the same, but their differences don't have to force them apart. In this column, Esther Derby uses the example of feuding operations and development groups to explain how focusing on the source of structural conflict can help build a bridge across the disagreements.

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.
 

Same:
We both...

Different
Ops
Different
Dev

Want to do what is best for the company.

Our job is 24 x 7. Someone is always on call. Sustainable pace rules 8 a.m.-5 p.m., Monday through Friday, unless
there's a production problem.
Value the people we work with. We understand infrastructure needed to run customer-facing applications. We understand development for customer-facing applications.
Care
about our work.

 
We have different skills. We have different skills.
Have pride in our work. Our age demographic tends to be older. Our age demographic tends to be 20s-30s.
Believe our work is critical to business success. We have a tech school background. We have CS degrees, mostly.
Know that if something goes wrong, customers see it right away. We learned on the job. We have advanced study.
  We have a continuous stream of tasks, daily work, and monitoring. We work in iterations.
  We work on infrastructure upgrade projects. We work on products our customers use.
  Our work is invisible until something goes wrong. Much of our work is visible to the customers
 

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 importantthat's the common ground where people can land when conflict arisesbut 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.

About the author

Esther Derby's picture Esther Derby

A regular StickyMinds.com and Better Software magazine contributor, Esther Derby is one of the rare breed of consultants who blends the technical issues and managerial issues with the people-side issues. She is well known for helping teams grow to new levels of productivity. Project retrospectives and project assessments are two of Esther's key practices that serve as effective tools to start a team's transformation. Recognized as one of the world's leaders in retrospective facilitation, she often receives requests asking her to work with struggling teams. Esther is one of the founders of the AYE Conference. She co-author of Agile Retrospectives: Making Good Teams Great. She has presented at STAREAST, STARWEST and the Better Software Conference & EXPO. You can read more of Esther's musings on the wonderful world of software at www.estherderby.com and on her weblog at www.estherderby.com/weblog/blogger.html. Her email is derby@estherderby.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Aug 25
Aug 26
Sep 22
Oct 12