I finally got around to reading Getting to Yes, which several friends have recommended. It is a fantastic crash course in negotiation. I also couldn’t help but notice the similarities between negotiation and design.

Good designs are driven by clear understanding of user requirements, and requirement’s gathering is really a form of negotiation itself.

Let’s examine the similarities for each of the book’s major points

People: separate the people from the problem

The book outlines a method of negotiation that frames the parties as partners, working together for a mutually-beneficial agreement. To be soft on the people and hard on the problem.

The same is true of requirements and design. Frequency of customer feedback is one of the most predictive measures of success for a software project. Effective software development requires an ongoing and trusting relationship between the developer and customer. Positioning yourself as the client’s ally in understanding their problem improves the relationship over time, increasing feedback. Antagonistic customer relationships that fight over estimates and features are comparably likely to breakdown, decreasing feedback.

Interests: focus on interests, not positions

This point rings true on many levels.

At any phase of design, it is unhealthy to get too attached to a single solution. The goal of design is not to complete one particular solution, but to solve the given problem. Problems are often not what they first appear to be. As Fred Brooks said, an experienced designer is more likely to solve the wrong problem to solve the problem poorly. Digging into underlying needs and motivations is the key to surfacing good solutions.

At the planning level, focusing on interests helps to balance the age-old conflict of schedules. The book contrasts “positional bargaining” where each party takes a position and then fight for some mid-point between. However, there is no guarantee a mid-point is a reasonable solution.

Instead, look at it this way

  • the client is interested in a solution to the problem. Likely with certain a budget and timeline
  • the developers are interested in healthy work schedules and attainable goals. If a consultancy, they’re also interested in turning a profit

A healthy continuing relationship can’t be maintained if either side’s interests are failed. Timelines and budgets, in particular, tend to feel like they are in direct competition. Midpoints or unbalanced agreements usually fail both parties.

Instead, directly recognizing and focusing on these interests while planning helps parties to work together to find new solutions. The customer generally doesn’t need every feature they list. Developers, likewise may find simpler technical solutions or other tradeoffs by better understanding the customer.

Options: generate a variety of possibilities before deciding

Generating multiple solutions uncovers qualities of the problem by forcing us to consider why one solution might prevail over the other. One mentor advised me to always generate at least 3 ideas before picking a path.

The book also suggests separating idea generation from selection. This is a generally useful brainstorming technique, sometimes described as flare and focus. Eliminating critical evaluations during ideation broadens the scope and variety of ideas.

Objective Criteria: insist the result is based on some objective standard

Objective criteria narrow the field of solutions. They also prevent multiple parties from slipping into positional arguments. The answer to any disagreement is to measure which design is better. Explorations based on objective criteria are easier to justify, easier to re-evaluate over time, and benefit from the understanding that led to such measures.

BATNA: Best Alternative to a Negotiated agreement

It’s easy to get blinders and only see outcomes in one vein. Building software can feel like the hammer for every nail. However, it’s important to keep in mind alternatives to building a solution. For example: continuing with process as-is, more manual processes, or processes using existing tools (excel?).

Not every deal is worth landing and not every problem has a solution. If both party’s interests can’t be met, then the right solution may be to walk away. Design-wise, creating a solution may not be worth the investment if exploration can’t identify path that meets the problem requirements.

Conclusion

The overlap between this book’s style of negotiation and design process are notable. Though, this isn’t really a surprise. Negotiation is a kind of problem solving, and any interpersonal problem solving requires some degree of negotiation.