Category: What Dimitri Learned

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.

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 2×2 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.

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.

I’ve noticed that my ability to operate in an ambiguous, complex environment depends strongly on my capacity to see a larger space of options and possibilities. There’s something very natural and yet completely unproductive about reacting to complexity with fear — diminishing our capacity for seeing what we need to see to overcome that fear. Working across different organizations at Google, the pursuit for seeing more and understanding my own fears is just as much of a personal development as it is professional. I simply can’t do my job without a continuous practice of expanding my capacity to see.

One kind of practice that I have is spelunking the network of assumptions. It comes from the understanding that our decisions are made on top of a massive network of assumptions: things that we believe are true. It turns out that many of these assumptions are unexamined, and might contain errors.

A child believing there’s a monster in their closet might finally confront their fear and open the closet. Finding no evidence of a creature, the child might decide that there aren’t any monsters, dispelling their erroneous assumption. Or they might conclude that the monsters are only present when the lights are off and the closet door is shut. In the latter case, the “monster in the closet” assumption had gone unchallenged, and instead, new assumptions were made around it. The monster story survives and if anything, becomes reinforced, more resilient, growing larger with each attempt to examine it. Parents can’t see monsters. Monsters only sneak from behind. And so on.

In the course of our lives, our networks of assumptions grow to contain multitudes of these resilient clusters of unquestioned assumptions. No longer as silly as “monsters in closets,” they pin the fabric of our reality in ways that prevent us from seeing more. Especially when these clusters are really, really old, they don’t even feel as conscious thought: instead, it’s the weird increase in heart rate, or the flushing of the face, or the sense of irritation that “just suddenly comes over.” All of these point at something happening deep underneath the veneer of the “rational thinking,” and all of these are the object of the spelunking practice. Why do I feel this way? Is there an inner dialogue going on? What could be the assumption that I am making? And what are the connected assumptions? With enough patience, the clusters of old unquestioned assumptions start to emerge — and become possible to examine and dispel.

I’ve written a couple of takes on this before, but they didn’t feel quite right, so here’s another iteration. Keep that rewrite count ticking! It seems that there are some distinctions that I can draw when looking at the missions of teams, whether hidden or stated.

The first kind of mission is the one I call questing. This is the mission of discovery and pioneering. A questing mission usually involves going into the wilderness with a good chance of never being heard from again. Questing folk cheerfully accept this possibility, soaking up the thrill.

The second kind of mission is scaling. Here, the team is asked to make something go big. There’s usually already some momentum, some flywheel that’s in place, and the team needs to ride it and not fall off in the process. Scaling missions can feel a bit like catnip  — strong feedback loops within the flywheel create clarity and sense of direction, making it a game of skill: challenging, yet ultimately predictable.

The keeping kind of mission is all about preserving the value, to guard and to protect. There’s usually a treasure of some sort, and the team is asked to ensure that the treasure remains intact. Be that a key metric or some critical infrastructure, the keeping folk will make darn sure it stays the way it’s supposed to be.

Each of these missions has a different set of values. Questing missions value learning. You might fail, but you better live to tell us about what works and what doesn’t. Scaling missions value shipping. If it didn’t make the number go up, it didn’t happen. Keeping missions value predictability: “you can promise, but can you guarantee it?”

In a large organization, there are usually teams that contribute in different ways: some are questing, some are scaling, some are keeping. The mix of teams’ missions will reflect the overall mission of the organization. In a keeping organization, there will be fewer questing teams. In a questing organization, fewer keeping. The relationship between the mix and the overall mission seems bidirectional: just like a questing organization will discourage the emergence of keeping teams within it, it might have a hard time changing its mission given its current mix. For example, no matter how hard an organization wants to endeavor on the scaling mission, if most of its teams are questing, it will remain a questing org.

And that’s another twist to the story: team missions shift as they make progress — and these shifts rarely get the attention they deserve. If by some chance a questing team hits the motherlode, it will need to rapidly transform into a scaling team. These changes are often painful, and cause polarization. I once (it was a long time ago) had gotten rather frustrated with a lead on our team. We hit non-linear growth and desperately needed to optimize, to improve quality, performance, add features — and he wanted to pursue a whole new kind of idea! “I am more of a v1 type of guy,” he explained. I was miffed. Back then, I didn’t realize that folks have mission preferences. Just like team missions influence organizational mission, each of us will often have a preference for the mission, influencing capabilities of the team. As the team mission shifts, we are asked to grapple with the question whether this new mission matches our individual preferences. And when it doesn’t, we might be heading for another kind of crisis.

As a software engineer, I often see a struggle that both teams and individuals experience: overcoming the anxiety to “get it right” the first time. And it makes sense! We want to make sure that when our software ships, it does what we want it to do and doesn’t cause harm. 

However, there’s something curious that happens along the way: somehow, this desire morphs into a self-judgement, detaching from the original purpose. If we don’t get right, does that make us good engineers? It’s no longer about the criticality of getting the code right, but rather about protecting ourselves from the possibility of appearing incompetent. Most commonly, I’ve seen this affect the productivity of team newcomers, who agonize over their first patches, and react in anguish when given feedback. It also affects teams who missed their deadlines and/or tackling problems that are much larger in scope than they previously realized. I am speaking from experience here. /me raises hand. Yes, I was–and sometimes still am–one of those people.

A technique that helps me here is to frame my work in terms of the “rewrite count.” I tell myself: “you won’t get it right the first time, so maybe give yourself a number of times that you’re expecting to rewrite this code/doc/deck from scratch. What’s the rewrite count here?” For easy ones, like this article, it’s one. I might finish this or I might let it go and come back to the topic some other time. For more complex bits, I give myself some “ambiguity slack,” setting the rewrite count higher. Sometimes, I set the rewrite count so high, it’s like telling myself: “you’ll probably never get it right.” Doesn’t mean it’s not worth trying, but hey — it probably won’t work.

One way to visualize the rewrite count is with an evolutionary process. In a complex space, to find a new maxima, I need to allocate some time for the churn. I need to walk around, explore the evolutionary landscape, rather than anxiously hold what I have now as the “right thing.” Incrementing the rewrite count is a way to let go, and allow myself to start from a new angle. And most importantly, see all that I made before as a learning experience that prepared me for this new start.

Practicing rewrite counts can feel rather challenging in organizations that value impact as only the code that’s shipped. Yet, this could be the key to effectiveness in these settings. Just like leaning in the opposite direction while steering a racing sailboat, learning to let go of the objective in the objective-driven world might give you that extra flexibility and peace to do amazing things.

Chatting with colleagues this week, I am recognizing that it might be useful to talk here about disagreement. I used to hate disagreement. I would get tense and have this pain around my neck anytime I sensed a situation where people–even not including me–are disagreeing. Early in my career, I even prided myself in being someone who navigated skillfully around disagreements, a disagreement traceur of sorts.

Somewhere along the way, this whole thing shifted. I find that I am excited by disagreement. Not in the “ooh, people are fighting, let’s grab popcorn and enjoy their misery” sense. Not even in the “alright, finally we’re getting this out in the open!” sense — though that might be part of it. My excitement about disagreement comes from the understanding that we all construct our own realities, and though we might believe that we all see the same thing, we rarely do. Our experiences are path-dependent, and it’s frankly a miracle that we agree on anything. From this perspective, disagreement is a discovery of a difference in this understanding of reality, a beacon pointing at an opportunity to learn from these differences, to add more depth to my understanding of reality.

When two TLs are having a heated argument in the comments of a doc, there’s something really interesting happening. They clearly both see something that the other can’t see, some valuable experiences that tell them they’re right. There’s a difference in mental models that’s just waiting to be discovered.

If you’ve worked with me, you’ve seen me use “Here’s what I am hearing. <insert my best understanding of the perspective>. Did I get that right?” technique. It may seem silly, but it helps to communicate that at that moment, I just want to understand what you’re seeing. Not interpret it, not pass judgement on it. I am happy that you’re seeing something different. It’s like a lonely eye finally found another eye — hey, let’s try seeing in stereo! I heard it really adds depth! If I am able to let go of my perspective juuust a little bit, something new is revealed.

Sometimes it’s technical insight. Sometimes a hidden organizational tension. Sometimes, an underlying personal pain. In every case, my understanding of the world becomes richer, more nuanced. And that’s hard not to get excited about.

A couple of this week’s conversations about platform/product team interactions led to this insight. I’ve been noticing a weird tension between teams that are collaborating on certain kinds of projects and it wasn’t until I applied the 1P/3P framing that the nature of the tension started to reveal itself. The symptom here is that the teams are happily collaborating on the project, but the scope and requirements of this project continue to churn a little bit, like something is pulling at it. “I thought we agreed on this?” … “Well, I guess this is right, but …” Sometimes the tension manifests as prolonged and tortured conversations around shared processes and project governance.

 In these situations, it might be good to check and see if the collaborating teams are in different parts of a two-sided market setup: the “1P team” that cares about the first-party side of the market and the “3P team” representing the third-party side of the market. The project on which these teams collaborate usually involves the 3P team providing means to develop experiences for the 1P team and feels like a great fit at first glance.

The tension arises because even though both sides are in a well-fitting customer-vendor relationship, their scopes go beyond that. The 3P team will likely have other customers who look just like the 1P team, but have different requirements and expectations. These customers might even be external to the company to which both teams belong. From the position of the 1P team, they will have this sense of being treated as “just another customer,” opening up space for heated conversations about “what’s really important here?” On the other hand, the “1P team” will likely be experimenting with ideas that are not aligned with the long-term direction of the “3P team”, leading to frustration around the health of the third-party ecosystem.

This seems like a good example of the challenge of coherence. Each team wants the other to be more aligned with them, to prioritize the work that overlaps. At the same time, each team sees their scope as a system where all parts–including those outside of the overlap–play a crucial role. There’s no right or wrong perspective here — it’s a polarity. And like with any polarity, it’s worth keeping it and the tension it represents in sight. Make it part of the project’s charter. Speak about it at syncs and all-hands. Own it — or be owned by it.

I’ve been playing some more with the idea of organizational mindsets in the context of a discussion of a team that finds itself “playing not to lose.” The thing that stuck out to me was that instead of seeing these mindsets as hierarchies–“how do I get out of this mindset to the next one?”–I find more opportunity space when seeing them as developmental. Through this lens, a mindset is a stage that includes and transcends the previous one. To get to the next mindset, the team has to master the previous one. To “play to win,” my team needs to first learn how to “play not to lose” really well. We can’t get to “play to change” if we suck at “playing to win.” 

Each stage is a place to acquire capabilities that will take us to the next one. Overlaying my earlier thoughts on theory of change, the team has to spend a bit of time “playing not to lose” to learn how to sustain itself, to grow a “motor.” Then, this team must learn how to steer–grow a rudder!–while “playing to win.” Only then, the team will have enough capacity to “play to change.” At each stage, different sets of tools will be more prevalent. While learning how to sustain, honing tactics and execution will feel like the most important thing. Several of my dear colleagues got burned out trying to advocate for strategic thinking in organizations at that stage. It was heartbreaking, yet I understand now why this happened: the focus on robust strategy doesn’t come into view until the organization is ready to start “playing to win.” And only after the team has mastered strategy can it start considering concepts like “theory of change.” Until then, it will feel a bit “woo,” something that’s far too detached from the ground.

This stage progression isn’t guaranteed. Like in any hero’s journey, there are plenty of forces that may (and will) hold an organization at its familiar stage. It’s far more likely than not for a team to never advance to the next stage. For me, uncovering these forces and helping teams move forth on their developmental journeys is the most rewarding and interesting part of my job.

A discussion of how to get an engineering project unstuck led to this insight. When examining sources of tension in engineering projects, there’s a common pattern that I see: the struggle to align on architecture. Fueled by the very reasonable desire to get things right, we may end up spending a bit of time trying to figure out how the code will be structured, which team will build what, etc. In one of my previous adventures at Google, I remember us project leads investing an entire day at a whiteboard trying to get all of this drawn out and settled. It felt good, but the durability of decisions made at that session ended up being pretty low: things shifted, requirements changed — and the previously drawn boxes no longer made sense. Argh — anyone up for another all-day session? I had this nagging feeling that there’s gotta be a more effective approach.

The idea was spurred by the plea of one of my colleagues: “just let the engineers write code.” So it dawned on us that maybe we’ve got the framing wrong. Maybe our struggle to align on architecture had a hidden subtext of “reduce duplication of effort.” Underneath our rugged appearance of experienced tech leads lurked the naive assumption that a well-architected project looks like people writing out their chunks of code once and then it all connects together and floats away into some code heaven. The end.
In reality, we all knew that this rarely–okay, never–happens. So maybe we needed to stop worrying about reducing duplicate work. Instead, let the engineers write code and align on interoperability. Find all the APIs where our code comes in contact with our customers and resolve to align on these APIs before shipping decisions are made. No matter how many implementations are in progress, they all need to have these same APIs. Then, make peace that team A will write roughly the same thing as team B — as long as there’s a plausible reason for that (such as resolving the pace layering tension), let them go at it. Who knows, maybe the icky hack that team B put together will end up carrying the day.