I recently discovered polarity mapping, a brilliant tool to facilitate good conversations about complex topics.
See if any of these tensions sound familiar:
- Should we do more Learning or start Building?
- Should we focus on Innovation or Efficiency?
- Should we prioritize Deadlines or Quality?
- Growth vs. Consolidation?
- Short-term Gains vs. Long-term Organic Growth?
- Centralization vs. Decentralization
- New Features vs. a Stable Codebase?
- Generalist or Specialist?
We could go on, listing more of these tensions. And if we’re like most organizations, we’d rush to analysis to determine the best or right answer. I’d argue we should first stop and ask a more fundamental question: Is this A Problem… Or a Polarity?
Too often, we treat conflicts — like those listed above — as problems to be solved, when in reality they’re “polarities”.
Problems vs. Polarities
A problem is something that can have a right — or best — answer. A solution exists. If we’re deciding between two incompatible tech stacks, this is a problem to be solved. We do our analysis. Weigh the pros and cons, determine which is the best choice, all things considered, then commit. Problem, solved.
This is approach is fine, if there truly is a decision to be made.
- Which tech stack do we commit to?
- Which department should I move to?
- Where should we shift our funding?
But, when we level this same problem-solving mindset at things that needn’t or can’t really be solved, frustration follows. “Should we focus on delivery or quality?” Yes. Yes we should focus on these things. That is the honest answer. But this doesn’t sit right; it doesn’t feel resolved. That’s because these aren’t resolvable. These are polarities, “dilemmas that are ongoing, unsolvable and contains seemingly opposing ideas“.
Problems give us two ideas that are directly opposed and in conflict.
Polarities give us two ideas that are complementary and interdependent.
Problems push an either/or mindset.
Polarities push a both/and mindset.
Problems need decisions, and resolution.
Polarities do not.
Here’s the rub: Polarities are not a problem to be solved, but rather a paradox to be balanced. Here’s an elegant analogy:
“Think of it like breathing. Breathing isn’t a choice between inhaling or exhaling. If you inhale to the exclusion of exhaling, the negative results show up quickly. And the reverse is also true. The polarity approach says, we must both inhale and exhale.”
Here’s where the polarity map enters the picture.
On the surface, it looks like a simple “pros/cons” matrix. But, as with most things, the devil is in the details.
First, this little loop is vital. It says we are constantly moving between these four quadrants.
Second, the language: You have two poles, yes. But you’re not evaluating the ‘pros’ and ‘cons’. Rather, it’s the Benefits and Unintended Consequences. Language matters.
The Tool in Action:
When we treat a polarity like a problem, looping back and forth is what inevitably happens over time (often over a very long, agonizing, period of time!). For our explanation, let’s use the tension of “planning” vs “building” a new software app.
- We’ll be able to make faster decisions, when we do move into building
- We’ll generate deep context / insights that are more useful to ops.
This is all well and good until months later, our zealous focus on “learning” has led to some unintended consequences:
- Teams are stuck in analysis paralysis
- And hey, competitors beat you to market. Bummer.
So what do we do? We swing to the other extreme! We double down on jumping into building. Insert some lean-slash-agile-slash-design sprint Kool-aid here.
At first, things go great.
- We’ve got something built and released into the market that we can iterate upon.
- We’re delivering real customer value
But then…
- That new feature you want, it’ll take a ridiculous amount of time, because we didn’t plan for anything like that.
- Oh, and we were so busy building things that we forget to do any real customer research. Turns out no one wants this thing we built.
- And who knows what better ideas we missed out on, as we sped along with our first idea.
We didn’t intend for any of these things to happen. And so the pendulum swings back to the other extreme. Most of the folks that would remember the previous extreme have moved on, so few people recall the follies of the other extreme.
And on it goes.
Polarity Mapping let’s us explore all these issues and concerns in an afternoon, setting teams up to work together, with a shared sensitivity to all these issues. You get the benefit of discussing all of these tensions upfront, before living through them. The goal isn’t a decision, but rather recognition of all these simultaneous Benefits and Unintended Consequences — on both sides. And reconciliation, as a team. And the valuing of competing perspectives. And… we could go on listing the goals. The conversations I’ve seen as a result of this activity have been quite remarkable. Aside from bringing Product Managers and Designers together, it’s also broken down stereotypes about what ‘“the other side” values.
“Are there any actionable outcomes from this?”
While I’ve focused on the core of Polarity Mapping, mapping the Benefits and Unintended Consequences of two polarities, there is more to this tool. Once you’ve identified this core information, you can move out into the margins to address:
- What are the Action Steps to gain or maintain these Benefits?
- What are the Early Warnings of unintended consequences?
Done as a group, and pinned to a wall, this should set up teams to successfully navigate many difficult conversations. Hopefully, you’ll find this tool as useful as I have.
The Polarity Map in action!
Downloadable Files:
Further information:
- “Are You Facing a Problem? Or a Polarity?“ — Center for Creative Leadership — a great introductory article
- The Polarity Map — there are lots of versions of the polarity map; I prefer the clarity of this version, as you may have noticed! (PDF)
- Polarity Thinking, Polarity Mapping — a longer overview with more examples (PDF)
- [BOOK] Polarity Management: Identifying and Managing Unsolvable Problems Yes, there’s a book on this topic, authored by the creator of this tool, Barry Johnson
You can also get more detailed information and consulting services directly from Polarity Partnerships, co-founded by Barry Johnson Ph.D., the creator of The Polarity Map® and Principles