Week of 2021-06-28
Note: I am on vacation for the next 2 weeks, and I am taking this newsletter with me. Gotta let it feel the sand, smell the ocean, and squint at the sky while deep in thought. So you won’t see it pop up in your inbox for a bit.
Mindset transitions and coherence
I wonder if in the framing of organizational mindsets, there’s a pattern with transitions across playing to win and playing not to lose. It seems that all teams that I’ve been on and worked with struggled through these transitions, and there appears to be a relationship between these transitions and the presence of the challenge of coherence. From this observation, a wild 2x2 popped out, and the following story with it.
Given the axis of degrees of coherence (high and low) and the axis split between mindset (playing to win and playing to lose), there are four quadrants.
In the upper-right quadrant, the organization experiences very few challenges of coherence and is playing to win. The teams are clicking, leads are high-fiving each other in the hallways, and there are so many congrats being sent over email that someone even wrote a program to do that. A common practice in this quadrant here is specialization, which allows teams within the organization to focus on their bits of the problem space and excel at winning within them. Unfortunately, it is my experience that this practice also leads to more opportunities of misalignment. Specialization necessarily brings fractured awareness of the overall problem space, which decreases coherence -- and eventually shifts the teams leftward.
In this quadrant, the challenges of coherence are manifesting a lot more, but the organization is slogging along, continuing to play to win. However, it is becoming less clear what the “winning” is about. Specialization focuses the definition inward, towards the team’s objectives, away from the objective of the larger organization. Specialization grows into polarization, with mutual distrust, blame, and cynicism as the forebearers of another shift. Friction and a sense of unease begins to spread across the team. Why is everything so hard? Why did it take us so long to do <blah>? Slowly but surely, the organization shifts downward.
Here, the coherence is low, and it’s mostly about staying alive. In a polarized environment where the life source (funding) keeps the units together, winning becomes about survival. Few are thinking long-term. Why would it matter? Tensions escalate to turf wars, threatening to tear the organization apart. And in some cases, they do. Yet, to continue our story, sometimes, there’s a unifying call that’s not like the others. There’s a leader, a cause, or an event that acts as a catalyst. I’ve seen it happen several times and honestly, if I knew the recipe, I’d be sitting pretty. But I don’t. All I know is that the battered organization bands together and begins to believe in something bigger, moving to the lower-right quadrant.
In this last quadrant of the story, it’s all about perseverance. It’s all about sticking with that bigger vision and grinding through the problem space, to learn to let go of the existential dread of playing not to lose and pop back up into playing to win.
In different organizations, these transitions happen at different severity. For some organizations, they feel like a mild flu, an annoyance that everyone can sense, but knows they’ll be okay. For some, the transitions are lethal. I am not yet sure why, but I am really curious to learn.
🔗 https://glazkov.com/2021/07/02/mindset-transitions-and-coherence/
Polarity-based API layering
While discussing API design, one pattern that caught my eye was polarity-based layering. It’s something that I’ve learned to do intuitively, but thought it might be worth capturing.
A symptom here is the tension around different qualities of API, like flexibility and ease of use. There’s this undulating dynamic that arises from this tension. Developers start with wanting an easy-to-use call that does all the work. Then, they tend to progress toward something more custom, wanting more flexibility. In many cases, the developers return from their custom solution back to the simpler APIs, seeking reliability and/or trying to shed their technical debt. Through this journey, the providers of the API will hear multiple seemingly conflicting requests from the same developer: make the API more easy -- no, make it more flexible -- no, go back to easy. With multiple developers at different points in the journey, this might feel like a cacophony, but a systems thinker in you will spot the polarity in the undulation: the moving back and forth is a process of seeking a dynamic equilibrium.
What helped me here is the understanding that as API providers, we are better off not trying to “solve” this polarity for our customers. Instead we try to design APIs to be layered: provide two self-coherent stories that speak to each side of the polarity. The lower layer usually focuses on flexibility, exposing raw capabilities (here’s everything that’s possible), and the upper layer focuses on ease of use, incorporating best practices (here is a safe, efficient, and resilient way to use all those capabilities). Each tells its own story. The story of the flexibility APIs is as dry and to-the-point as possible, but with no bumpers to protect you from sharp edges. The story of the ease-of-use APIs is poetic and intuitive, but it also simplifies and elides some nuance.
When well-designed, these two stories don’t intersect. This helps reduce the chances of a developer who’s just looking for ease to wander into the woods of raw capabilities. But most importantly, it allows the stories to remain coherent, so that developers can tell between these different stories and make good choices in their journey to find that equilibrium.
🔗 https://glazkov.com/2021/07/02/polarity-based-api-layering/
The nature of the challenge
While working on a strategy this week, I realized that one of the most common missing bits from a well-designed strategy is a discussion of the nature of the challenge.
There are degrees of strategy design quality (that I probably need to write about someday), and at the higher end of the spectrum are strategies that include a problem statement. The problem statement usually briefly describes the challenge that the strategy seeks to wrestle with. For me, this is usually a good sign. I have seen so many docs/decks that call themselves strategies, but are actually just plans or inventories of projects that having a cogent description of the challenge is breath of fresh air. It’s an indicator that the author invested time reflecting on why their set of proposed actions might lead to addressing the challenge.
What would help make a strategy even more effective is capturing why the problem is hard. What is the nature of the challenge? What are the forces at play and which ones of them do we intend to rely on -- or contend with -- to overcome the challenge? Think of the nature of the challenge as drawing your best approximation of the map of the upcoming quest: here are the tall mountains, here is the dragon lake, here is the fairy meadow. Then, the approach you’ve taken is a path that weaves through this map.
By painting that larger picture around the proposed path, we allow others around us to see it. They might point out that they are seeing a slightly different picture. “There’s no dragon lake here. And the fairy is actually a witch.” They might also point to a different path: “Why not skip visiting the castle? It smells musty and the old duke is not fun to be around.” This might be uncomfortable, especially when so much work went into putting the strategy together, but in my experience, describing the nature of the challenge tends to act as a unifying force: once articulated, it pins down at least one mental model of how the future events will unfold, and this catalyzes sharing and aligning of other mental models -- dramatically increasing the overall chances of the strategy succeeding.