Once upon a time, I had just joined a new team. I was excited to solve problems and scale new heights with them!
My manager handed me a problem. The team had a bug backlog of fit-and-finish bugs to address. Not a large one, but one that needed attention. The type of stuff that routinely gets dropped on the floor when we are sprinting to launch features. All the corners that are cut when we are too busy as a team. Yep, I was on it, and I was going to fix it!
I got my team together. We made a plan and organized a big fix-it, putting some of our OKR work on the back burner to make space. There were donuts for all and a reward for the one who fixed the most bugs. There was also me equally cheerleading and dragon-fire-breathing my team to CLEAR THAT BACKLOG! So yes, we got it all done. Vanished! Gone! Down to a big ol’ zero!!
Except…
A year later, my manager handed me a problem. The team had a bug backlog of fit-and-finish bugs to address. 🤯
The clichéd sense of déjà vu hit me. Was I stuck in Groundhog Day? Or did I somehow fail to solve this problem well the first time??
This was a pivotal moment in my career when my manager introduced me to a coach who taught me about Polarity Management.
Defining a Polarity
The concept of a Polarity is best explained by an example - breathing.
You start by inhaling. You inhale deeply and feel great as the oxygen enters your system.
But at some point, you stop feeling great and feel the pressure building in your lungs.
You quickly reach a point when you just can’t take in any more air! Now, even if you stop inhaling, you’ll still be uncomfortable. The only way to start feeling better is to exhale. You start doing that, let out air, and start feeling good again.
But now you reach a point again when you are feeling low on air. Soon you reach a point when you’ve exhausted all your air! The only way to start feeling better again is to inhale. And the cycle continues!
Inhalation - Exhalation is an example of a Polarity. The diagram below shows how we can visualize the two poles and the butterfly cycle between them.
Polarity Management
There is a key difference to remember between Polarities and Problems.
Problems can be solved once, and they go away forever.
But Polarities need to be managed; they cannot be solved.
Problems are also static. Polarities should be seen as moving systems that cycle between two poles.
Polarities require…
…that we embrace change as the only constant.
…us to use the power of AND to integrate both poles of the polarity into our plans instead of choosing just one.
Here are a few tips for managing polarities using a polarity map.
Identify the poles
This is an underestimated but important part of polarity management. In my bug backlog example, I originally identified my poles as “too many bugs in the backlog” and “zero bugs in the backlog”. But the real polarity was Speed vs Quality and the bug backlog was one (clumsy) mechanism to track it. Once we knew the true polarity, we could manage it better in our development lifecycle.
Map the dynamics
Figure out what the upsides and downsides are for each pole. Understand how the poles interact because, remember it's a moving system! Visualize how things might look if you try to pick either pole exclusively. This will give you an idea of what tradeoffs you’ll have to make to reach the AND state.
Find the sweet spot
An interesting learning for me was to avoid solving a polarity like a linear equation. The “sweet spot”, or equilibrium point as I like to think of it, is not exactly in the middle of the 2 poles. Sometimes you may want to lean the bit more towards one pole by design. For example, at Google, we prioritized Quality in Ads, our older product. In newer areas, we leaned towards Speed.
Once you decide your sweet spot, you’ll know if you want a balanced loop, a left-pole-leaning loop or a right-pole-leaning loop in your system.
Here is a Google Slides template you can use for your own polarity mapping! I have also included examples for a few of the polarities discussed here for reference.
The template is available for purchase to anyone. Just click the link below to access it!
Additionally, if you are a paid subscriber of ChaiTime, you can get this and all such templates in future for FREE! If you are already a paid subscriber, you can access the product catalog and the paid subscriber download code here!
As the ChaiTime templates library grows, the total value you get from a paid subscription will far exceed what you pay for it. Don’t forget to check if you can reimburse the subscription through your company’s learning program!
Polarizing Stories
Here are a few stories of my own related to polarity management. And a few more from recent news where I saw everyone pick a side and hunker down when Polarity Management could have helped us all reach better answers.
Ask - Tell
I had a high-performing report. She was amazing at her job, so of course I wanted to challenge her with bigger jobs. Harder projects, new domains, larger leadership responsibilities. She was always up for a challenge and always ready to learn!
That meant that at any given time there were some things she was excellent at and some she was just learning. She was also rapidly changing her skill level for any given thing. This kept our manager-report relationship constantly in the ask-tell polarity. Sometimes I could be at the Ask end, being the coach and relying on her to drive the conversation. Sometimes, I had to be on the Tell end. I had to be a prescriptive manager and tell her exactly how to proceed. She was new to that task and learning on the job was too risky.
In every 1:1, we cycled through the Ask-Tell polarity. I also noticed that the polarity loop shifted. It changed from Tell-leaning to Ask-leaning as she grew from junior to senior engineer.
Innovation - Standardization
My team had a lot of cool ideas they wanted to prototype. Some were quite good and could be the next big thing! But they also came with a lot of risk. Risk of wasting time and resources. Risk of causing outages that led to more time/money waste, or eroded customer trust.
But sticking to the well-trodden path would not give us any 10x wins. Yes, we'd deliver what was needed. But it would kill the bottom-up intrapreneurship culture that made my team an exciting, energetic place to work. It also wasn’t clear if we’d continue to exist as an organization long-term if we just stuck to what we did best here and now.
Most mid-sized organizations, especially within larger companies, face the innovation-standardization dilemma. Your leanings could change based on your company culture and risk appetite.
Monolith - Microservices
This may seem like a non-polarity if you are firmly on one side. And indeed it is a clear-cut answer in some technical designs. But I have also seen my fair share of designs that went through cycles of being monoliths, then split into microservices and back again. Just like other polarities, both poles here have their benefits and downsides. Treating them as a polarity allows you to integrate both into your system design. You can do this to the desired degree.
RTO - Fully Remote
There are strong benefits to everyone being together in the office and to teams being co-located. There are also downsides. They include higher costs for the business and employees, and difficult commutes. Fully remote work may be a dream for some employees. But, it could harm an organization's cohesion and function if everyone is too dispersed.
This polarity shows how the equilibrium point may vary. It depends on your company culture, leadership, industry, and other factors. Some companies have interpreted the equilibrium point as 3 days in-office / 2 days remote. Some interpret it as allowing hiring anywhere in a region (e.g. anywhere in the US). But, the employee will be tagged in-office or remote based on their location.
Founder Mode - Manager Mode
"Founder Mode" means the person at the top makes all the decisions and goes deep into every area of the business. Those could be great benefits of this polarity. But, it could also lead to slow or stalled decision-making. Worse, it could result in wrong decisions due to the founder's lack of understanding of the domain's depth. The founder's desire to be involved everywhere could distract the team. They would need to spend time educating the founder.
In contrast, "Manager Mode" would be to delegate every decision. It means trusting others to run your business. It can speed things up if the people you delegate to are great domain experts, strong owners, and have aligned incentives that work for them and the business. Often, many of these conditions are not true and the manager becomes a figurehead. They add no real value to the business's goals.
This example shows a polar system's constant, cyclical movement between the two poles. Most business leaders (CEO, GM, etc.) must switch between these two modes regularly and smoothly to help their company succeed.
Readers, what polarities have you faced in your job?
Insightful write-up!
Absolutely loved this one, great mental model. Never thought about it that way.
And great stories!