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.
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.|
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 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.