Consensus and Compromise

June 4, 2018

Consensus and Compromise

Getting the most from a software development team depends on the ability to build technical consensus among the professionals on the project. But why should it matter whether you and your office mate agree on the layout of an entry form or the best way to report error messages? Technical consensus is not about getting along together or feeling close to your fellow programmers. (Not that there is anything wrong with getting along or feeling good about each other.) Technical consensus is about taking full advantage of all the skills and experiences of every team member. It’s about building better software.

Technical consensus is not about getting along together or feeling close to your fellow programmers.

Software professionals may understand good software, or at least claim to know it when they see it, but technical consensus is a lot less well understood among developers. Probably most software developers have had some bad experiences with what they thought was design by consensus. They’ll tell you tales of brilliant ideas being lost in discussions, about compromising their artistic integrity, about six-month projects that took years, and about groups that settled for less than the best. Listen carefully and you’ll realize that what they are talking about is not consensus at all, but compromise. What’s the difference?

Unpromising Compromise

Compromise is neither one thing nor another but something halfway in between, which often means in the middle of nowhere. Consider this variation on a classic example. Your team is designing a graphical user interface. One group strongly advocates placing the control buttons across the bottom of the screen, another is pushing for a panel down the left side. Between these horizontal and vertical extremes, a perfectly objective compromise can be struck: just place the buttons along a diagonal across the middle of the screen!

A compromise, like this one, is frequently worse than any of the original alternatives, but a consensus solution can be better than all of them. Technical compromises often fail to account for the merits in each of the alternatives, and their advantages are lost by taking some kind of average position. True consensus is not based on compromise, in which everyone and every position loses a little, but on synthesis, in which everyone wins big. The payoff, of course, is better software.

Technical compromises often fail to account for the merits in each of the alternatives, and their advantages are lost by taking some kind of average position.

A synthesis is something original that incorporates essential features of each contributing idea or proposal. In the interface design example given above, it’s easy to see a creative synthesis in which the placement of the button panel is an option selectable by the user. Not only does a consensus based on synthesis incorporate the best of the alternatives, but new features or capabilities typically emerge from the combination. Out of the synthesis of horizontal and vertical button panels might emerge end-user customization. The product thus incorporates the best of both worlds, not the worst. Building real consensus is not easy, as politicians and labor negotiators know all too well. Building a technical consensus is a little different from building political consensus, but it has some of the same elements. Both take a commitment to working things out; both require a certain faith in the process.

Consensus Is Neither Compromise Nor Coercion

Confusing consensus with compromise may be the great “wives' tale” that undermines the collaborative nature of meetings. The Thomas-Kilmann conflict mode instrument provides clear differentiation between the compromising individual and the collaborative individual. This is useful when considering a definition of consensus for an organizing tool:

Individuals who have some ability to cooperate while remaining somewhat unassertive engage in a compromising conflict mode.
The very assertive and very cooperative person uses the collaborating mode of conflict resolution.

True consensus, therefore, relies on a collaborative mode of reaching decisions versus a compromising mode.

True Believers

Team members need to believe that it is possible to reach a technical synthesis incorporating the best elements and aspects of everyone’s contributions. Believing this, they will stubbornly look for something better, rather than settle on compromise or cling needlessly to personal favorites. By persisting, they build their understanding of the problem and the nature of the strengths and weaknesses of each approach. From this, they enhance the odds of finding that creative something that exceeds them all. Consensus design also works best when each of us believes that building a better piece of software is more important than getting our own favorite ideas into the result in some predetermined form. This investment in the quality of the outcome makes it easier to see the merits of whatever ideas emerge from the group process. It helps, of course, if teamwork is applauded over individual pyrotechnics. Companies that reward individual performance instead of group success, or those that promote the lone wolf programmer over the team player, typically end up with a staff of uncompromising loners who probably will not and cannot play team sports. Such companies will rightly conclude that the best software is produced by their frontier-type geniuses. What they don’t realize is that they’ve set it up to come out that way. Other outcomes are possible, of course.

One essential rule in building technical consensus is: No horse trading! Trading votes or support or influence is one of the classic tactics for political success, but it can destroy technical effectiveness. For example, we might work a trade in the interface design. I’ll agree to your stupid idea of having the button panel across the bottom, if you agree to my clever design for icons without labels. The result is an interface that is less than the best in not one, but two features. Horse trading is just compromise in another disguise, but compromise made worse because decisions in one area contaminate those in another. Good technical consensus must see each issue as a separate problem, to be resolved on the merits, not as part of a point scoring system in which concessions in one area can be traded for obstinacy in another.

Just the Facts

One likes to think that technical decisions are made on the basis of technical issues—facts, measurable quantities, practical considerations. The truth is that feelings, opinions, intuition, and just plain biases are part of any decision-making or problem-solving process involving people. This is the reality of what it is to be human, and although some people try to deny, control, or suppress these nonrational aspects, it never works completely. An essential skill of any team that hopes to build technical consensus is to learn to separate fact from opinion. If the group, collectively, is to make the best decisions and solve problems creatively, they need access to the best information and to know what kind of information they have. Opinions aren’t bad; team members should be able to express them freely. Opinions can even be useful, especially when weighted by hard-won experience, but they must not be confused with facts or data or analyses. Facts, too, have their limitations. In the areas of aesthetics or marketing appeal, facts may be in short supply. Unfortunately, once some group members have made up their minds, they do not want to be bothered by facts. Calling something a fact doesn’t make it so, and groups have to learn to cut through the bull and agree not to abuse the language.

Consensus: I Can Live with That and Support It

A collaborative meeting strives toward highly participatory decision making. But what constitutes agreement about decisions? And how much agreement must a team have to move forward comfortably with other work? Consensus-driven decisions form the most sustainable agreements a team can use to create action. Therefore, a collaborative meeting includes a posted definition of consensus as one of its organizing tools. We can use a definition that removes the binary or black-and-white connotations from the notion of agreement and instead reinforces the notion of agreement without compromise and without violent dissention. Simply stated, consensus means: I can live with that and support it. This helps participants understand that collaboration can be achieved in a team without everyone being wildly enthusiastic about the choice. The choice reflects a shared understanding by the team. The choice is good enough to live with and support. The choice is adequate to help us move forward. The choice has enough of a team sense that no one feels completely left out of it. Teams that agree to work in a consensus-driven mode make a few implicit statements to one another as they begin a meeting: “We believe that any decision made by the team is better than a decision made by an individual” This does not mean that the team cannot have experts that give very strong recommendations to the team about how to proceed. Experts often provide the necessary rocket fuel to help teams move forward and maintain focus on the larger collaborative issues. This is especially true in our technical environments in which we have to rely on specialists in a variety of domains in order to converge on our complex “righteous solutions” for our “wicked problems.” Experts ensure that the team has accessed its greatest wisdom in order to build the best overall solution. “We understand that gaining consensus can take more time”. Because of the work and commitment it takes to gain consensus in a highly charged issue, a team has to understand at the start what is required of them. They may choose to reserve consensus for critical, high-risk decisions only. “We may not seek consensus for all decisions” Some conflicts are not so important as to warrant the time to resolve it to a consensus level of agreement. Therefore, once meeting participants truly understand the meaning of consensus, they can then more knowledgeably choose when to use less time-consuming forms of decision making. Trina Hoefling (author of Working Virtually ), a facilitator who specializes in conflict resolution, leads teams through a decision process at the very start of any meeting to help them decide explicitly about their consensus organizing tool:

“When will we use consensus to resolve conflict? When consensus is not warranted, what other decision-making process will we use?”

By making these clarifications at the very start of the meeting and posting them, Trina helps the team move along at a pace that works for them with regard to consensus building. In sum, teams decide which decisions are important enough that they should only be resolved in consensus, and which decisions can be taken through a less enduring approach. Teams who believe in consensus and use it appropriately are teams that are able to work more and more collaboratively.

References:

Image credits

Photo by Fabian Burghardt on Unsplash
Photo by Kevin Gent on Unsplash
Photo by Joshua Clay on Unsplash
Photo by rawpixel on Unsplash
Photo by rawpixel on Unsplash
Photo by mike-erskine on Unsplash
Photo by Saksham Gangwar on Unsplash

Photo by Providence Doucet on Unsplash