What Should IT Experts Know from “Getting to Yes”?

The book “Getting to Yes” discusses the dangers of positional arguing. By focusing on your position, every compromise feels like a loss and leads to loss aversion. By focusing on a mutual solution, people remove themselves (mostly) from the emotional investment in their positions and can open themselves up to solutions other than somewhere in between two opposing positions. Positioning the negotiation as a problem solving session is the only solution when there are multiple parties involved and necessary to develop true objective criteria for a solution instead of simple consensus.
There are several take-aways IT professionals can draw from this book.
• Always devise several solutions so that you can analyze the merits and flaws of each solution. Even if the originally proposed solution is selected, now you know that it is, indeed, the best choice and the weaknesses of the solution.
• When scheduling down-times or selecting software changes, focusing on the problem instead of each person’s position (no downtime this weekend!) improves the odds of a workable solution. Several parties all screaming “Not now! You’ll ruin my shipment schedule!” can delay fixes until catastrophic failures occur, though that is something no one wants.
• Separate software problems from the people reporting them. Don’t assume an ID10T is the problem, no matter how emotional or lacking their explanation of the error.
• The 10% of users who report 90% of the problems may be configuration managers discovering problems due to their higher access level or greater use of the system. See them as beta testers, not annoyance.
• Research how others solve the problem, instead of charging ahead to devise a fix yourself and be the hero.
• Limit negotiations in software projects to the true stakeholders, and don’t forget that a user representative like a project lead for the customer is one of the stakeholders.
• Debate solutions on their technological merits and resource demands, not what is hot in the industry right now.
• Set objective criteria to justify software changes, not keeping up with the latest software practices barring IT security.
• Realize that frustrated users will ramp up the priority of their problems, making them emotionally invested parties in any negotiation. The fact that they’ve had to put in a change request is a guarantee that they are already in a positional negotiating position.
• Software projects are ideally long term. Don’t fight for a stance today for the next release when the dominance struggle hurts the working relationship for the next three releases.

Filed under: An IE in IT

About the Author

Posted by

Tamara Wilhite is the IE in IT blogger for the IISE. She is a Six Sigma green belt with experience in IT, PDM software, the defense industry and recycling industries. She currently works as a freelance technical writer.