- Defining polarity
- Polarity or problem?
- Real world polarities
- Product and Engineering prioritization
- Bias towards action vs bias towards preparation
- Long term vs near term focus
- Leveraging polarities
- Polarity mapping
- Wrap up
Like fences, polarity thinking is a mental framework for taking ownership over entropy. Just as the north pole of a magnet doesn’t “beat” the south pole, recognizing polarities in life and work allows us to recognize when we need to approach challenges by bringing balance to the forces at play rather than beating them.
From Melinda Butsch Kovacic’s TED talk, What is Polarity Thinking?
– Melinda Butsch Kovacic
In other words
- Forces/priorities/realities that need to be balanced rather than fixed
- Coexisting opposites
Polarity or problem?
Signal of a potential polarity: “if you have a cycle of problems and fixes and your fixes just don’t seem to fix and over time problems keep arising, then consider that you have a polarity and not a problem” – Melinda Butsch Kovacic
Examples of common polarities include
- Autonomy vs alignment
- Short term vs long term planning
- Product quality vs speed of delivery
Real world polarities
Product and Engineering prioritization
When thinking about how to prioritize work, Product Managers often sort primarily by potential impact to key performance indicators.
As an technical leader, particularly as an Engineering Manager, in addition to the quantifiable commitments such as quarterly and yearly goals, I also think about, among other factors
Can we do this with the resources we have and if not, can we secure said resources and when?
ii. Professional development
E.g. I’ll consider doing a lower impact but less complex project ahead of a higher impact, higher complexity project so that the engineer(s) working on the simpler project can build expertise and momentum to carry into the more complex project.
iii. Cost of ownership
Does the impact that this work bring near term and over time warrant the ongoing costs to maintain and support it after it’s built?
A sign that we're over-indexing on the Product perspective is that tech debt accumulates goes unpaid or tech excellence goes unexplored, slowing the pace of progress or introducing unpredictability/unreliability to system ownership. A sign that we're over-indexing on Engineering perspective is that we are able to deliver the current slate of initiatives on time, but there’s no clear sense of what comes next. A sign that our perspectives are in balance is when engineers have clear immediate lanes of focus while they, I as the EM, or a combo thereof are also exploring future opportunities.
Reconciling Product and Engineering perspectives is an important facet of our roles. When our perspectives differ on how to prioritize and explore work, we are able to arrive at decisions that appropriately balance bottom line impact with growth and sustainability of the engineering team and good experiences for users. The net result is that the team delivers on impactful, often organizationally and/or technically complex work.
Bias towards action vs bias towards preparation
- Bias towards action: some folks I’ve worked closely with move fast when it comes to communication.
- Bias towards preparation: I tend have slower, more contemplative style - especially around conversations that I find challenging.
- I should allow myself to be sped up at least some of the time. Having dedicated time already set up serves as a forcing function to both prioritize and time box prep work, allowing us to build and leverage momentum.
- Fast moving partners should themselves to be slowed down. If there are inputs that can go into a discussion to make it a more effective use of everyone’s time, then that’s a worthwhile investment. For instance, the need for multiple rounds of follow up can be reduced or eliminated if folks don’t have to spend collaborative time to review new information for the first time that could/should have digested ahead of time.
For instance, while I might still be writing up the game plan for how to guide a discussion, including anticipating the likely questions and push back and relevant context that should be shared ahead of time, my partner might have already scheduled a follow up meeting.
Long term vs near term focus
Delivering on current work versus either defining future work or defining long term strategy are forces that exist in tension. The farther out you look, the more uncertain things become. Navigating imposed uncertainty (things out of your control) requires indexing more on the near term considerations - potentially at the expense of long term interests. It is hard to think about future strategy if the current state of affairs is not healthy.
However, that period of over-indexing should be time-constrained. The aim is to break out of near term focus before long term direction is impeded. The reward for having a heathy present state is being able to focus on the future.
There is virtuous loop to be found in balancing long and near term focus. If an EM and/or PM runs ahead of their team on a project by gathering requirements, dependencies, stakeholders, etc and getting those forces aligned, then by the time engineers are ready to pick up the project, they can focus diving deep on how to get it done. With engineers taking ownership of how to execute a project that’s been set up for success, the EM and/or PM then has more capacity to run ahead of the next project. Engineers should still be involved in the early stages of up future projects, and EMs should still be involved in the execution of current projects.
And there in lies the polarity: the perpetual dance of keeping these forces in balance. The way to do this is to think about percentage of focus on both poles rather than absolute focus on either (unless there are exigent circumstances that require 100% focus).
In thinking in terms of polarities, the goal is to avoid over-focusing.
- Getting it wrong, you pay twice: once for time wasted on arguing, and once more for over-indexing on the argument winner’s perspective instead of finding a healthy balance.
- Tactics for handling polarities include:
- Map them out, seek out the virtuous loops (reinforcing causal relationships)
- Label the forces that are in tension (often more than two IMO)
- Identify early warning sides of over indexing on one or the other
Benefits of focus on left pole
Benefits of focus on right pole
- Less communication overhead means more potential speed - Decisions may optimize for unique needs
- Prior work and resources can more readily be shared
- Potential duplication of effort - More difficult to share resources including staff, knowledge, prior work
- The more people there are to align, the more time and effort it takes to wrangle them, reducing potential speed
Negatives of focus on left pole
Negatives of focus on right pole
Based on materials by Barry Johnson
- Ralph Stacey: Complexity and Paradoxes
- Managing complexity entails taking experience seriously. Taking experience seriously entails paying attention to power and the ideologies that govern our behavior, generally stopping to reflect on why we do things the way we do.
- Why we do what we do includes what we measure and optimize for. Those things become the poles in our polarities.
Although the default approach for many is framing challenges as problems with solutions, polarity thinking offers an alternative lens. It helps reconcile opposing forces such as autonomy vs. alignment, short-term vs. long-term planning, and bias towards action vs. bias towards preparation. By identifying and balancing polarities, technical leaders, be they formally designated or informal, can make decisions that harmonize bottom-line impact with the intangible aspects of building and running healthy teams such fostering growth and sustainability within their teams