Use Conflict Creatively

Brush that sand out of your face, take a lesson from Charles Atlas's dynamic tension, and learn to use conflict creatively to beef up your management approach.

By J.D. Hildebrand

If you grew up reading comic books, then you no doubt remember the ads for Charles Atlas's bodybuilding program. The most memorable ad featured a bully who kicked sand in the face of a 97-pound weakling. The tables are turned in a subsequent panel, in which the weakling, transformed into a paragon of muscled manhood, gets the girl and the bully is sent home sobbing.

The Atlas program was based on the notion of "dynamic tension," in which individual muscles and muscle groups were pitted against each other in a series of exercises. Atlas believed that setting two muscle groups in opposition made both groups stronger.

In business, enlightened managers avoid setting individuals and groups in opposition to each other; conflict among team members is almost universally acknowledged to be destructive. We've all heard horror stories about managers who set up candidates for a promotion by giving them overlapping responsibilities and vague guidance, with the Darwinian expectation that whichever candidate takes charge will get the job. Such managers are still among us, but the practice has been so thoroughly discredited that attrition is quickly weeding them out of most organizations.

However, I think management abuses have given dynamic tension a bum rap: I've come to believe that conflict between individuals and departments is not only harmless, but valuable.

Real-World Conflicts

The development organization you manage is part of a real world in which conflict is as undeniable as gravity. There's an inherent conflict in the trade-off between software features and development resources. And there's an inherent conflict between quality and timeliness. These aren't trumped-up tensions designed to stress staff members until one emerges victorious, but rules of nature.

Consider the relationship between quality and timeliness. On the one hand, you've got the QA team. The more they test, the more bugs they discover and fix. From a QA point of view, you want to delay an application's roll-out as long as possible—software in testing, like wine in casks, continues to improve.

On the other hand, you've got the deadline. Someone has made a commitment to users about when the app will be ready. Someone has to free up development resources to start work on the next job in the queue. From a pure workflow-management point of view, you want to roll out the new application as soon as possible so you can start work on the next project.

According to 1990s-style management-by-encounter-group canons, the proper response is to raise everyone's consciousness. You hold meetings and deliver PowerPoint presentations to give the team the big picture. The QA guy will understand that there's a backlog of other jobs. The project manager will understand that QA is just interested in making the app as strong and reliable as possible. Everyone holds hands and sings while someone strums a guitar. Oh, please.

The result of this consciousness-raising is that each team member gets his own view of the project's priorities—and each feels empowered to execute and defend his own view. The QA guys will continue to press for more time. The deadline managers will continue to push for immediate roll-out. But now, everyone's argument will include the assertion that they're arguing for the one solution that's best for all.

Been there? Done that? Me, too. You can have it.

Counting on Conflict

Here's the thing: Your QA team has its hands full running tests and fixing bugs. They lack the time and probably the skill to juggle deadlines and resources. They're most valuable when they insist that they need more time to push the application to acceptable quality levels. That's their appropriate role. And, as the manager, you need that input.

The deadline manager has his own job. He's quite properly focused on chipping away at the development backlog. He can tell you the cost of a week's delay in roll-out of the current project, and he can argue that it's time to move on to the next job. As the boss, you need to hear those arguments, too.

Your power to make informed, intelligent decisions comes largely from the quality of the input you receive from staff members who represent points of view that are inevitably in conflict. Whisk the conflict away with a consciousness-raising exercise and you wind up with all your staff members diluting their own voices, trying to second-guess the input from other departments. The information you get from them will be muddled as they compensate for the advice they anticipate receiving from others.

You're better off acknowledging and embracing conflict. It's an inherent reality; let your staff structure and procedures reflect that reality.

Resolving Deadlocks

The existence of conflicting priorities implies—demands—a management role. In time, most conflicts are resolved according to routine conventions. The deadline manager knows that apps must spend time in QA, and will have no quarrel with two or three weeks of testing. QA knows that it has a reasonable amount of time to solve problems, as a regular part of the development cycle. No management intervention is necessary.

As a manager, you're there to mediate conflicts when the situation is no longer routine, when project management and QA are unable to negotiate a resolution on their own. QA focuses on QA, deadline managers focus on deadlines, and as the manager, you focus on the big picture. That's the contribution you're uniquely positioned to make. This is the perspective necessary when QA insists it needs more time and the deadline manager insists it's time to move on. You can hear both arguments, collect the facts and come up with a solution.

A note of caution: It's tempting to codify conflict-resolution principles in a set of rules. "QA may, upon failure of a certain threshold of tests, delay roll-out for up to two weeks for further testing and debugging." On the face of it, such rules make sense, but the problem with rules is that they have a chilling effect on cogitation. In fact, the entire purpose of rules is to prevent thinking.

That's not always a bad thing. When the fire alarm goes off, you don't want to debate how to respond. It's smart to short-circuit the debate and get everybody out safely. For routine events and some emergencies, rules are fine.

It's in the middle ground—the trade-offs, the judgment calls, the places where a big-picture viewpoint is essential—that rules are damaging. They prevent you, as the manager, from weighing the facts and making an intelligent choice.

One of the things you must manage is the number and range of decisions that you'll reserve for yourself, and the decisions that you'll codify with rules. My caution is that it's easy, especially for those who think like programmers, to err on the side of too many rules.

Supporting Self-Sufficiency

Over time, the QA specialists, deadline managers, developers, documentation writers and other specialists who work for you will learn to manage many of the inherent conflicts that arise. Your workload will lighten as they become more self-sufficient, and you can turn your attention to staff training, climbing the CMM ladder, negotiating with management for more resources, and the other tasks on your to-do list.