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.

References:

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
  • Photo by Maarten van den Heuvel on Unsplash
comments powered by Disqus