Consensus and Compromise

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.

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

Two simple ways to negotiate consensus in a software development group

Two simple ways to negotiate consensus in a software development group

You can’t reach consensus unless you recognize it when you have it in your grasp. This means that software development groups trying to reach collective decisions are wise to agree, in advance, on the criteria by which technical matters will be decided. What is important? What matters? What is “good” and what is “bad” within the confines of this particular project?

Many times, when a group gets bogged down trying to reach a conclusion on an analysis or design problem and says, “We can’t decide which way to go,” We can ask them, “How will you know which approach is better?”

Engineering is about trade-offs—trading off a little more of this for somewhat less of that.

Resolving trade-offs requires knowing something about the value, within a given project, of whatever is gained or lost in the trade-off.

In almost all engineering, projects are driven by competing criteria. It is not possible to meet all of them equally well in every detail at every juncture. Most projects pursue a mixture of technical and economic objectives. They want on-time delivery, run-time efficiency, ease of use, marketability, extensibility, and maintainability, along with a host of other goodies next to godliness. How are these to be weighed?

Straight Priorities

It helps to have your priorities straight. The metrics mavens will probably push you to reduce the decision criteria to a mathematical formula with weights and exponents for each factor, but this is generally neither necessary nor particularly useful. A simple rank ordering of the criteria is sufficient. During analysis and design, when most trade-offs are and should be resolved, we seldom, if ever, have enough data to quantify our assessments with any precision or confidence anyway. Plugging a bunch of seat-of-the-pants “guesstimates” into a bogus formula can give the dangerously deceptive appearance of disciplined objectivity. It can even become an escape hatch by which development teams avoid accountability.

“Well, we just did what the formula said we should; it’s not our fault that each screen update takes 17 seconds.”

Accountability is promoted when development teams participate in establishing their principal goals and, on the basis of these, rank the criteria by which issues are to be decided. Once agreed upon, the criteria and their ordering are no longer open to debate. Most of the time they won’t even enter into technical discussions. It is not necessary to analyze every little trade-off in terms of seven or eight criteria. The agreed-on list of criteria is taken off the shelf only when needed to help resolve a decision that is unclear or is taking too long.

Debate and Dialogue

Lack of clarity or agreement on criteria is not the only thing that can hinder negotiation to technical consensus. Free-wheeling discussions are not only the heart of consensus teamwork, but they’re fun. Vigorous discussion, however, can cross the line into rancorous debate. Neither the courtroom nor the political podium offers a good model for consensus-based teamwork. Whether or not the adversarial approach works in the justice system, it is essential that design and development groups not end up as debating societies.

It is very common to see members of a team complaining about their group was getting nowhere. They were repeatedly getting bogged down in seemingly endless wrangles. Even what little progress they were able to make was seriously substandard compared to other teams in the same class.

If one watched them work—or try to work—we can realize that the discussions were being dominated by one man who was an arguer par excellence, but his ideas were not up to his debating skills. Some other members of the team had a sense of the shortcomings in his thinking but, outgunned by his argumentation, kept falling back on opinions and feelings:

“I don’t think so.”

“It just doesn’t feel right.”

The original complainant had the motivation to see it work better, so that we can ask him to be group facilitator. His job had two parts: to make sure that no one person or side dominated the discussion, and to help the less active or less aggressive members articulate the real content and logic of their ideas.

If you are trying to build the best systems, you don’t want to reduce technical solutions to whichever side can argue better, any more than you would want to base them on who has the most power or can shout the loudest. To avoid this, the power of logic and argumentation should belong to the group collectively, not to individuals or factions in a decision. The goal is to level the playing field so the merit of ideas and analyses in themselves carries the weight, not the cleverness of the argument or the loudness and long-windedness of the advocate.

If people can’t seem to find a common ground arguing their own positions, one useful technique is to have advocates reverse roles and argue each other’s positions. Or strong debaters can be assigned to argue the case of technically interesting but weakly defended notions.

“Look, Mavis, you’re good at this, so see if you can convince us about the real advantages of Greg’s idea.”

Yet another twist is to say,

“Let’s apply this same line of reasoning to the other proposal.”

Technical consensus is better thought of in terms of dialogue and negotiation than in terms of debate and argumentation. Some of the things that have been learned about negotiation in other areas can be very useful. Two excellent books from The Harvard Negotiation Project are highly recommended: Getting to Yes and Getting Together . A perennial problem in negotiations is that the negotiating parties often come to the table already committed to a position, a proposal in which much thought and consideration may already have been invested. Instead of being genuinely open, each arrives with a predetermined solution. Negotiating from a position is thus a problem in itself. It tends to promote compromise at best, rather than consensus, and it is all too easy for things to degenerate into a shootout of one approach versus another.

Some of the simplest devices can make a big difference. The Harvard Negotiation Projectlearned that negotiations progressed better when disagreeing parties sat side-by-side, facing “their common problem,” rather than facing each other over a table. It is found that placing factions in a technical dispute together facing a whiteboard or display screen can facilitate more productive discussions and speedier resolution.

Putting It Together

Sometimes starting from a set of prior proposals or already worked out solutions cannot be avoided. Two parts of the same company may have done prior work that we would not want to discount or waste, for example. Some companies even promote design competition in a kind of internal free market of ideas. When the time comes to build one system, usually the authors or competitors make their own pitch, introducing and describing their approaches. It can facilitate consensus building to have one person, someone who is less invested than the proponents, present all the alternatives before inviting the proposers into the discussion. Setting the right tone for what follows can help progress toward a consensus design. Participants can be encouraged to look for the strengths and advantages in other proposals before moving on to any critique. Realism about the starting positions can be encouraged:

“Since it is more important for us to know about technical weaknesses in our systems than to pretend to have everything perfect, would each of you tell us about the weaknesses of your own approach?”

Where distinct subgroups or teams have been involved in preparing proposed solutions, after the initial discussions each subteam can be invited to go back and improve their own proposal by incorporating what they think are some of the best features of opposing approaches. This means that the next meeting starts with the opposing positions already moved closer together.

In general, technical consensus is built from alternatives by finding ways that combine or even transcend the best features of each. Instead of starting with positions, with specific technical proposals, it is often more efficient and effective to start with issues. The team’s first job is to explore and settle on what are the essential technical issues represented in the various possibilities, the underlying reasons and technical rationale that are reflected in stated positions or proposed solutions.

The stage for creative synthesis is set even before the first meeting. Instead of having team members think about approaches to, say, the file structure, they might be asked to come with a catalog of the issues involved in designing an efficient file structure. They might list and prioritize specific decision criteria. They may even have to be discouraged from coming up with design ideas or proposed solutions. With many of the more maverick software developers, the problem is not so much spurring them on as reining them in before they stampede.


Image Credits

  • Photo by Jakob Owens on Unsplash
  • Photo by Kelly Sikkema on Unsplash
  • Photo by rawpixel on Unsplash
  • Photo by Violeta Pencheva on Unsplash