When to go from collaborative modelling to coding? Part 2

Part one is available here.

Part II: It is a polarity, so what do we do now?


So now that we know what a polarity is, how to think about them and know how to visualize and manage it, it is time to dive a bit deeper. In this part, we will talk about what can go wrong when managing a polarity, the self-fulfilling prophecy, but we will start with how to recognize one.

How to spot a polarity in the wild

Unmanaged polarities within teams or groups can lead to conflict. That is why we often mistake a polarity for a conflict. Conflict in itself is not a bad thing, as long as you’re able to manage that conflict properly. Conflict often arises when there are underlying dilemma’s that result in opposite views. Key to handling these carefully is to first figure out if you’re dealing with a problem that needs to be solved or a polarity that needs to be managed. When you’ve found the underlying key dilemma’s there are two questions you can ask to determine if it’s a problem or a polarity1:

1. Is the difficulty ongoing?

If the dilemma is solvable and has an endpoint, you’re dealing with a problem. “Where are we going for dinner?” for example, is solvable (although can be a very tough choice), and it has an endpoint: we’re going to place X or Y and we’re going tonight. It’s an either/or decision. A polarity, on the other hand, is ongoing and has no clear either/or decision. It requires interaction between several solutions. We need both/and thinking here.

2. Are there two poles that are interdependent?

The solution to problems can stand alone. The decision for restaurant X doesn’t require restaurant Y to be effective. When it comes to polarities, both solutions depend on each other to work well.

If we apply these questions to our example in our previous blog post—collaborative modelling and just start coding—we can argue that we’re dealing with a polarity and that we thus need to go with both/and thinking. The difficulty is ongoing and the two poles are interdependent; they depend on each other to work in the best manner. Going back and forth between these solutions depending on the situation we’re in will help us get the best results.

A heuristic that we would recommend to add to your repertoire is the following: ‘when you find yourself in conflict, then try to figure out the underlying key dilemmas leading up to this conflict, and determine if it’s a problem or a polarity. And remember this: if you’re dealing with a polarity, you can manage that and get the best of both opposites while avoiding the limits of each. Polarities come in all shapes and sizes. We listed some common examples that we see within groups and teams below.

Examples of common polarities

Planning (Collaborative modelling)

Action (Coding)

Individual responsibility

Organisation responsibility

Word

Deed

Stability

Change

Conditional respect (Earned by doing, measuring)

Unconditional respect (Given Freely)

Thinking fast

Thinking slow

Centralized

Decentralized

Autocratic

Participative

Hierarchical

Egalitarian

Market-driven (Customer)

Product-driven (Organisation)

Chaos

Structure

Power

Love

Universal rules

Situational rules

Part (for instance Individual)

Whole (for instance Team)

 

Completeness versus accuracy 

Collab-Modelling-To-Coding-9

Now you know how to spot a polarity, what can go wrong in managing them? Well, our human tendency to be right, for starters. What do you see in this picture? A rabbit or a duck? Whichever one you see, you are right. One person could say ‘duck’, another could say ‘rabbit’, and they’ll both be right. Being right is the easy step. Both are accurate, neither is complete.

Incompleteness combined with our conviction of being right (accurate)—fed by cognitive bias—is an important source of a potential problem when managing polarities. We can argue for days about the duck/rabbit; about who’s right. The question is, do we want to be right or complete? In most cases, and especially with collaborative modelling, it would help to strive for completeness, so we’re able to include all relevant and minority perspectives. The hard part is that you have to let go of your own view to see the other view and thus be complete. You cannot see the duck without letting go of the rabbit. You cannot manage a polarity properly without being complete.

The problem we see very often in organizations is that conflicts arise because a both/and polarity is treated like an either/or problem that can be solved. The question ‘when to go from collaborative modelling to coding’ is such a both/and polarity. It’s not either/or, we can move back and forth. However, we often see people contradicting someone’s accuracy. This will create unnecessary resistance and won’t get you anywhere near managing the polarity.

Once you’ve seen the accuracy from the other view, it becomes easier to go back and forth between the views. This means it’s very important to know how to move through the polarity map, and how you’ll be able to get the minority on board. 

Why crusading goes wrong

Think about hanging up a toilet paper roll in the bathroom for a second. What is the right way to do it, under or over?

Collab-Modelling-To-Coding-10

The truth is, there is no "right way" to do it. You may try to convince us otherwise with hard evidence if you wish to do so, but in the end, it is about personal preference.

(One of our writers does not even have a preference, imagine that!)

Yet, many evenings are spent discussing this with friends and family, and those discussions can get very heated sometimes. And the topic is not even that serious. (We apologize, we understand under or over toilet paper issues are very serious).

Imagine having a completely, you may even say opposite, view on a topic. There will be a lot of conflicts trying to convince the other people involved that your view is the only correct one.

We refuse to see the whole picture and refuse to try and understand other perspectives but our own. Often there is an unwillingness to walk a mile in each other's shoes.

We believe there is a right way and a lot of wrong ways to do something, and that our way is the only right way. But a polarity, just as toilet paper, doesn't work that way. The poles are on opposite sides, but a polarity needs both poles to exist, and we need to find a balance between those two poles because one pole cannot exist without the other.

Yet crusaders, and tradition bearers, fail to see the positive side of the other pole. They can only see the downside of the opposite pole and the upside of their pole.

That is why crusading goes wrong: the goal of managing a polarity is to stay as much as possible in the upper quadrants of the polarity, not to shift from left to right or visa versa.

If you want to manage a polarity, and you want to manage it well, you need to create clarity for everyone, including yourself, and make sure people understand both sides of the polarity. If you don’t do this, you will have a hard time managing the polarity and get stuck in some anti-pattern despite your good intentions.

How long do we need to manage the polarity?

So one dire question remains, how long do we visualise and keep managing that polarity. We can find that answer in psychology with the four stages of competence, or the "conscious competence" learning model. Below you can find a representation of that model that can help you with that question. Before you start doing polarity mapping you are in stage 1, unconscious of the problem and incompetent to deal with it. Once you become aware of the problem and do the first part of a polarity map, you as a group become conscious of the problem, but still Incompetent to deal with it. Finally when filling in the signal and observations plus the actions, you have your tools for becoming competent. At some point in time you will notice that balancing the polarity becomes a second nature, like breathing in and out and thus the function of the map will be redundant, until! Until there will be a new polarity to manage.

Collab-Modelling-To-Coding-11

The self-fulfilling prophecy anti-pattern

Collab-Modelling-To-Coding-12

A big anti-pattern with poorly managed polarities is the self-fulfilling prophecy. It means that on a rational base, you know you are dealing with a polarity, but your behaviour says otherwise. If you are so invested emotionally and culturally in one pole, people will feel and know that. If you are, let’s say that coder by the hearth and your company is heavily invested in the coding pole. Now rationally, you know you need to invest more in collaborative modelling so you set up those workshops, it will only set you up to fail. Because the tradition-bearing force will now look for any signs of the R- pole, and the crusader-force will not take you seriously as the person wanting to make this change. You are trying to be the bridge builder, but bridge builders will always become the scapegoat if you aren’t managing the polarity first.

Collab-Modelling-To-Coding-13

Polarity map, Barry Johnson

We call this a poorly managed polarity, and the first thing you should do is when you see a poorly managed polarity, is find a neutral party to help you with polarity mapping. First, hold a session where you discuss both sides with a neutral facilitator. This way, you can stay in your role, and people will see you as part of the polarity. When the stakes are too high, be careful doing the polarity map yourself, ask someone from another team to first take off the edge.

Roundup

In this blog post, we had a look at the difference between a polarity and a problem and the difference between accuracy and completeness for a polarity. We had a look at why crusading goes wrong, and highlighted the most common anti-pattern, the self-fulfilling prophecy.


1Johnson, Barry. Polarity Management: Identifying and Managing Unsolvable Problems. Amherst, Mass: HRD Press, 1996.


Photo of Kenny Baas-Schwegler, Evelyn van Kelle and Gien Verschatse

Kenny Baas-Schwegler, Evelyn van Kelle and Gien Verschatse

Kenny Baas-Schwegler - Socio-technical and Domain-Driven Design architect @Xebia. Facilitator of visual and collaborative modelling using #DeepDemocracy #DDDesign

Evelyn van Kelle - Strategic Software Delivery Consultant | Optimist | socio-technical complexity | Public speaker | Books | Linguistics | Golf |

Gien Verschatse - BlunderingGoddess<'T>; Some say I am: Master G, Slinger of F#, Don't F* With Me Verschatse, Thought Leader of One