Getting to Yes: How to Negotiate Agreement Without Giving In
The negotiation classic Getting to Yes: How to Negotiate Agreement Without Giving In introduces something called "interest-based negotiation" and presents it as the ultimate power tool for adversarial negotiations where the other party has the upper hand. And it may well be that power tool, but some of the best mileage I've seen has been in friendly negotiations, and business world problem solving.
Getting to Yes opens by discussing two main styles of negotiation that occur to people: hard and soft negotiation. Hard negotiation is a matter of taking a position and insisting on it: playing hardball. Soft negotiation, more characteristic of friendly negotiations, still involves taking a position, but being very flexible.
Getting to Yes presents a third option, that of interest-based negotiation. Individual positions taken by either side of the table are ordinarily poorly suited to the interests of the other side; and interest-based negotiation involves uncovering what the basic interests of the two sides of the table are, and then problem solving to, as best as possible, satisfy the interests of both sides of the table. Getting to Yes speaks of being hard on interests, soft on positions.
Examples from the world of information technology
It's obvious, in the context of a negotiation between bosses and stakeholders on the one hand, and information technology on the other, that a stakeholder or boss has interests involved in negotiating what information technology professionals will do for them. What is less obvious is that information technology professionals also have interests. These interests include interests that amount to good engineering concerns, including a realistic solution, avoiding technical ways of painting themselves into a corner, and solving the problem in a way that will work well for stakeholders. (If a cobbler makes a shoe that fits comfortably, the customer will make fewer requests for adjustments than if the shoe pinches.)
On this last point, it might be remarked that initial solutions (positions) proposed by stakeholders should be viewed with suspicion. When someone non-technical tries to design a technological solution, there is a real danger of a solution that looks good on paper, but amounts to a shoe that pinches. One time my brother, then a database administrator, commented that on his team there was a system administrator who, when he was asked something that amounted to, "Is there a way to—", would rudely cut the person off and say, "Stop. Tell me what you want to have accomplished." And he gave an excellent example of interest-based negotiation, even if it is a better way to avoid being curt.
The example he gave was, if there was concern about a disk filling up, someone asking, "Is there a way to run [the Unix command] 'df' every five minutes and send it to the system administrator's pager?" And there are several things wrong with that position. First of all, this was a little while ago when there weren't smartphones with high-resolution screens. The Unix 'df' command is designed around a full (text) screen, producing half a page or a page of text (probably more given their environment), and decidedly not optimized to quickly give useful information on a pager. It would require scrolling to see if the 'df' output represented a problem or not. And constant messages that require digging to see if they mean anything important amount to spam from the system administrator's view: the fact that one more verbose message was sent to the pager means nothing particularly interesting to a system administrator. And that spam risks a real "boy who cried wolf" syndrome, with the system administrator having no clue when a real problem is occurring.
Not that there is any need for helplessness if disks fill up. There might even be a better solution that would use pagers. For example, there could be some monitoring tools that page a system administrator if a disk reaches some threshold of being too full, or if disk usage is growing too quickly. The basic issue is one that people can take steps to deal with. But the system administrator's blunt "Stop. Just tell me what you want to do," was almost kindness in disguise; it was meant to pursue the mutual interest of solving a problem as well as possible, as opposed to a solution that amounts to, "I've solved the problem badly; now you go implement it."
The system administrator's blunt response when he sensed positional negotiation was, "Stop. I don't even want to hear your position. Just tell me your interest and let me address that."
For another, slightly more technical example, there was a system administrator at our company who had written an asset tracking program, and later on I was charged with writing a purchase order system. When the system was shaping up, he said he wished his asset tracking system could simply go away, superseded by the new purchase order system.
The general consensus was that the order tracking system was tolerable, and the CTO consulted with some people from other companies and said nobody had really done better than tolerable like our asset tracking. The system administrator wanted me to replace his asset tracking program, and my expectation was that I might be able to do a little better than him, but not a lot better. And I think he was modest about the solution he had pulled off given what he was dealing with. I told him, at a social meeting, "The reason my program is crisp and clear and your program is messy, is that the problem my program solves is crisp, clear, and simple, and the problem your program solves is messy and hard." And I could see a smile and shining eyes on his wife's face, but my remark was not intended as a merely polite statement. As we did business, the problem of purchase orders was cut and dry, and I didn't have to make any especially hard judgment calls: mostly it was straightforward adaptation as requests came in. By contrast, the tracking system covered assets and components, venturing into territory the purchase order didn't touch, and the territory of assets and components came with genuinely fuzzy and difficult border cases, where you had to draw lines about what was an asset and what was a component and deal with subjective factors that the purchase order system never touched.
Once the two systems were up and running, it looked like that meant duplicate data entry. It would have been an option for me to write a replacement asset tracking system, but I think my co-worker was being genuinely modest about a real achievement, and it did not seem obvious to me that my replacement for a working system would work better. We looked at publishing data from the asset tracking system to purchase orders, and then set things so that entries in the purchase order system were automatically carried over to the asset tracking system. That solution was one that was stuck with: it did not involve, as had originally been suggested, that the asset tracking system would be superseded by the purchase order system, but it did address the basic interest: no need for duplicate data entry. The asset tracking system was made aware of entries in the purchase order system, and the solution addressed the various interests. Including, one might like to add, that the company would lose none of the benefits of a respectable, solid existing system, which would now be working better than ever.
An example from private life
In one family I know, the parents decided that their son could own a pocketknife (he owns a couple), but not carry anything dangerous. That may be a sensible decision, but it was annoying to the son, and I understood his frustration: I know what a Swiss Army Knifemeant to me when I was younger, and still to some extent means to me now. Besides being practical, a Swiss Army Knife is a nifty device, dipped in coolness. And I could identify with his being frustrated that his parents would not let him carry either pocketknife: not because he specifically wanted something dangerous, but because he wanted coolness.
For Christmas I gave him a Leatherman multi-tool designed to be useful and cool while still being something you could carry through TSA-approved airport security. It only has a few features as far as multitools go, but it has enough, and he greatly appreciates the gift. It satisfied both his desire for something cool, and his parents' concern that what he carry not be dangerous, and so he carries it now.
In a non-work interaction at work, my boss received a copy of Hello World! Computer Programming for Kids and Other Beginners, a book that introduces the powerful language Python with pirates and ninjas, and I asked him if I could borrow the book for a few minutes to copy bibliographic information. His reply was "Let me send you an email," and forwarded me a promotional email with a coupon code worth $20 off the book's price if you ordered by such-and-such a date. In this friendly negotiation, I took a position and my boss responded in a way that would address my interests better than my initial position.
Step one: Identify the interests
Step two: Problem solving
All of these negotiations have an element of problem solving. The first step is to identify interests. If someone comes to you with a position, which happens 99.9% of the time, it is a position motivated by interests, and you need to appreciate those interests. Anthropology-style observation, if you know how to do it, helps. Being empathic and trying to see what benefit someone's position will bring them helps. As much as possible, bring interests out into the open so they can be addressed.
A win-win solution may not always be possible; the pie may not be big enough for everyone even if they cooperate. (Getting to Yes may be of some help here.) But a win-win outcome will be more often found by trying to address interests than simply starting with positions, staying with positions, and only doling out who makes what concession to the opposite position. And creative problem solving can help address those interests once they have been identified: for my brother's workplace, system administrators can be automatically notified, including by pager, when any of several identified red flags is tripped. Being dangerous is not intrinsic to being a cool multitool: therefore one can search for a safety-friendly multitool. Is there a hidden opportunity in interests that have been identified? Check and see.
Conclusion
Interest-based negotiation is not always easy; Getting to Yes provides few examples: one of these few has two sisters arguing about an orange, splitting it, and then one sister ate the inside of her half and the other sister used her half of the rind to bake a pie. And the introduction states that stories are hard to find. Part of my effort here has been to provide examples, taken out of my experience because that's what I know, even if it would be best to have third person stories and avoid stories that present me as a hero. But the rewards for at least trying for interest-based negotiation are worthwhile. And, as stated at the top, Getting to Yes may present interest-based negotiation as the central power tool for a hostile negotiation where the other party is more powerful than you, some of the best mileage I've gotten out of it has been in friendly negotiations with other people who share some of the same goals. And this is true inside and outside of the business world.
It's worth recognizing negotiation as negotiation: not all negotiations have a dollar amount. And once a friendly negotiation is recognized, identifying interests can be a powerful tool to obtain win-win results.
Is there a place where you could use friendly, win-win, interest-based negotiations more?