Evaporating Cloud: Conflict Resolution
Last updated
Last updated
Arguments. Fights. Politics. Enemies. Compromise. Loss.
We have all encountered conflict, and most of us try to avoid it whenever possible. Conflict is seen as unhealthy and unpleasant to the point that many people will attempt to ignore it even after realizing that doing so may actually be contributing to a worsening situation. Or both sides treat the conflict as a zero-sum game: “Either I go, or he goes!” Or perhaps worse, both sides compromise: they “split the baby” and nobody goes away happy.
It turns out there are better ways to resolve conflicts: ways that result in the creation of solutions that completely satisfy everyone involved. From one remarkable perspective, it is even possible to entertain the idea that conflicts don’t actually exist except at the superficial level of our positions: what we say we want.
When two wants appear to be mutually exclusive, we say there is a conflict. The way forward is to recognize that our wants (also called positions) are motivated by underlying needs (also called requirements.) For example, the two wants could result from children fighting over a toy: in this case they both want to possess the same limited resource. However, they are motivated by underlying needs, which may not be the same for each of them: one child may feel the need to assert their ownership of the toy, while the other child may feel the need to incorporate the toy into their play. Furthermore, the children are united in a common objective: to get along and have fun. To achieve this common objective, satisfying both children’s needs is necessary. Notice that as we have passed beyond the boundary of the apparent conflict presented by their wants, a recognition of their needs and common objective begins opening the door to creative solutions that may leave everyone happier than they thought possible.
When the connection is made that conflict stems not from some kind of pathology, but from legitimate needs and common objectives, it becomes obvious that the best approach is not avoidance but prompt communication and the creation of options for mutual gain.
Often, after producing a Current Reality Tree (CRT), it is possible to recast the Core Driver as a Core Conflict, containing two mutually exclusive positions. So whenever we find ourselves faced with conflicting wants, which often happens as the result of creating a CRT, but even more frequently just happens on its own, the Evaporating Cloud is the tool to use. (It is so-called due to its ability to “evaporate” conflict. It is also known as the Conflict Resolution Diagram.)
Since the basic form of a Cloud is always the same, the easiest way to start a Cloud is to select the File ➡ Open Examples... command and open the included template file Cloud.logic-t template located in the Documents/Conflict Resolution folder. Template files open as new, untitled documents to which you can make changes and save without fear of accidentally changing the template file itself.
The following paragraphs describe how to set up a Cloud document from scratch. You can skip to the next section if you are using the template.
A Cloud is based on Necessary Condition Thinking. Since Flying logic documents are set up for Sufficient Cause Thinking by default you will want to set the Operator popup menus as follows:
Entity Operator: Fuzzy And (AND)
Default Junctor Operator: Fuzzy Or (OR)
Clouds are read from left-to-right, starting at the Common Objective. However, this means the flow of the edges (arrows) must be towards the Common Objective or right-to-left: so you will want to set the Orientation popup menu to Right to Left.
Clouds are created using the entity classes in the built-in Conflict Resolution domain, and use the following classes: Want, Need, Common Objective, Conflict, and Solution.
If you’re using the template mentioned above, then the diagram is already drawn for you; you only need fill in the text. But the steps below assume you are drawing a cloud from scratch.
Create two Wants entities and give them titles that succinctly summarize each of the conflicting positions. Traditionally the two Wants are called D and D’ (“D Prime”).
Create a single Conflict entity and make it a predecessor of each of the two Wants. If you’re using the right-to-left orientation typical of Clouds, the Conflict entity will be to the right of the Wants.
Give the Conflict entity a title that summarizes why the Wants conflict.
Finally, right-click (Mac or Windows) or control-click (Mac) one of the two edges leading from the Conflict entity and select Set Selected Edge Weights: Negative in the popup menu that appears. This causes the edge you negated to turn red. By doing this, our model accurately reflects the mutually-exclusive nature of the two wants. To see this, click the Show Confidence Spinners switch in the toolbar, then adjust the spinner on the Conflict entity from its maximum (True) to is minimum (False). You will see how the spinners on the Wants entities cannot both be true at the same time, due to the negated edge.
Create two Needs entities, each one a successor to one of the Wants entities. The purpose of a position is to fulfill an underlying need. Give each need a title that summarizes the immediate need that its side in the conflict is trying to fulfill by asserting its position (the Want.)
The difference between a Need and a Want is simple: fulfillment of Needs are conditions considered necessary to fulfilling the overall objective, while Wants are particular actions chosen to fulfill the needs.
Create a single Common Objective entity, and make it a successor of both needs. In a left-to-right orientation, the Common Objective will be the left-most entity in your diagram.
If the two sides in the conflict have no common objective, then there isn’t really any conflict because the two sides could simply go their separate ways: they have no reason to cooperate. Thus, in every situation identified as a conflict, there is always a common objective. The Needs identified in the previous step are both considered necessary to achieving the common objective. In other words, both sides of the conflict would agree that unless their needs are met, the common objective cannot be met.
The Common Objective is also usually at a “higher level” than the Wants or the Needs. In the case of the children fighting over a toy, the Common Objective might be for them to “get along and have fun.” Notice that this Common Objective doesn’t mention the specific toy that is the subject of the conflict, even though the Wants and Needs may all mention it.
Now that the diagram is complete, show the Confidence Spinners, and note that there is only one driver: the Conflict entity. This is the only entity that has no predecessors. If you have set up the document operators and negated one of the edges coming out of the Conflict entity as described above, you will see that by changing the value of the Conflict entity’s spinner, one Want or the other can be satisfied (by becoming True), and yet the Common Objective can never become True. In other words, as long as the conflict exists, the Common Objective cannot be achieved.
Now read and revise the diagram for clarity and accuracy. Clouds are read from left to right, against the flow of the edges, using the pattern:
“In order to satisfy the need we must obtain our want.”
This is the basic pattern of Necessary Condition Thinking. This pattern applies to all the edges except the two coming from the Conflict entity. Once we have completed this step, we fix or clarify the wording.
In the pattern from the previous step, there are two blanks for needs and wants. In this step we add a third blank:
“In order to satisfy the need we must obtain our want because of our assumptions.”
Our assumptions are why we must obtain our want, and finding erroneous assumptions is the key to breaking the conflict. Assumptions “hide” underneath the Want→Need edges, and the Needs→Common Objective edges. There are also assumptions that underlie the Conflict entity itself: why we believe we can’t have both Wants simultaneously.
As you surface these assumptions, use Flying Logic’s annotation feature to add text to each of the four dependency edges and the Conflict entity. Take as much space as you need to describe each assumption, and begin each assumption with “...because”.
Sometimes there will be a single assumption under each edge, but often there will be several. Assumptions can be either valid or invalid. Invalid assumptions are often used to link needs to wants, but here you must critically evaluate each of the assumptions to determine their validity. Invalid assumptions can be eliminated, leaving just the valid ones.
If we manage to invalidate all the assumptions on any of our edges, then we have eliminated the necessary condition relationship between two of the entities. If we have invalided all the assumptions on the Conflict entity, then we have eliminated the perception of conflict itself. In either of these cases, the Cloud has “evaporated” and we have discovered there is, in reality, no conflict.
If the cloud is still intact, then we have at least one valid assumption in the five locations. The final step is to construct solutions (also called injections) that let us “break” one or more of the edges in the Cloud. A solution is an “option for mutual gain,” and the most constructive place in the cloud to find creative solutions is in the edges that connect the Wants to the Needs, by asking questions of this pattern:
“How can we satisfy Need without obtaining Want?”
“How can we accomplish Common Objective without satisfying Need?”
“How can we obtain both First Want and Second Want?”
Remember that solutions that you come up with at this stage should not be considered final unless the situation you are analyzing is rather simple; this tool is for brainstorming a new set of options. You can use a Future Reality Tree to solidify the ideas you generate at this stage. Also, avoid the temptation to look for a single “panacea” solution; you will often need two or more injections to implement a truly win-win solution.
To inject a solution into the diagram, first select the edge where you want the solution to appear then either:
Double-click the Solution entity in the class list in the sidebar.
Right-click (Mac or Windows) or control-click (Mac) the edge and select New Entity ➡ Conflict Resolution ➡ Solution from the popup menu that appears.
An OR junctor will be inserted into the edge, and the new Solution entity will be added as a predecessor. Give the new Entity a title that summarizes the solution.
More solutions can be added to the same edge by selecting just the junctor, then using the same command from the popup menu.
By displaying the Confidence Spinners, you will see that you now have additional points of control for every solution you have added, and that it is now possible to make the Common Objective True, even if both Wants (the original positions) are not obtained.
