Month: June 2021

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.

Cognitive Behavioral Therapy folks consider mind-reading as one of the cognitive distortions, and it’s been puzzling for me: on one hand, understanding that another person has thoughts and feelings and trying to sense them feels like an important skill. On the other hand, I can see how this can go South real fast. Scratch that, I’ve gone there. So many times. One of my more painful memories here was me derailing a Web standards meeting with a rather harsh reply to an innocuous question. I assumed that the person asking the question had some ulterior motive — of course they wanted to just keep jerking me around and delay the progress! — and unfortunately, acted out a self-fulfilling prophecy.  We made no more forward progress on this item that day. I made assumptions about what the other person was thinking and jumped to conclusions, foreclosing on much of the space of other available choices. It feels like there’s a very delicate dance of guessing what the others are thinking and acting on those guesses. 

Here’s how I made sense of this tension so far. I tell myself: “In the first half of your life you’ve learned how to mind-read. In the second half, you’re learning how not to do that.”

When we’re young and still learning to socialize with others, mastering the theory of mind is crucial in becoming a functional adult: to empathize and to take the perspectives of others.  Somewhere along this journey, we usually arrive at the point where we feel pretty good about this ability and assume that we can mind-read: know what other people are thinking. This discovery can be quite intoxicating. All I need to do now is get even better at reading minds! And it feels like it works: a subtle shift in posture, a voice inflection, or facial expression are good-enough clues to let me know what’s happening in that other person’s mind.

Except they aren’t. They tell me that something is happening, but the full extent of the story is inaccessible to me. All I have is a guess based on my own experience. And that guess is just as much informed by the others’ furrowed brow as by that burrito I had for lunch.  Even more confusingly, what I am reading might be true: that other person is thinking something that I fear. However, that thought is a part of a large, conflicting mess of being. We are not one-threaded minds. If we believe Numenta’s research, there are thousand brains in each of us, trying to come up with viable strategies for navigating this complex world. Some of these brains are thinking beautiful, kind thoughts. Some of them aren’t. If we only let ourselves judge others only by their non-beautiful thoughts, we’d arrive at a rather bleak reality. We are much better off treating our mind-reading skills as tools for generating initial guesses, something to hold lightly.

Part of my work involves spotting challenges across teams within Google. Over time, I’ve learned to notice different kinds. Sometimes they are engineering challenges, sometimes they are product or leadership challenges. I even learned to recognize UX and UXR challenges. Once spotted, each of these has a decent chance of being addressed: there are experts who built careers around overcoming these kinds of challenges. Recently, there’s a different kind of challenge that has been intriguing me. I call this kind the challenge of coherence.

The challenge of coherence emerges when it’s clear that all parties involved in the project are doing their best to get their bits right, yet the total outcome isn’t greater than the sum of these bits. I call this phenomenon “the confetti of innovation:” everyone does amazing work and the end result is quite sparkly, but has little lasting progress toward the intended mission. Everybody stands around, covered in shiny bits, wondering what happened.

My experience with challenges of coherence is mostly with large organizations, though I believe that all teams face them. If a few friends try to build something, but have different ideas on what this “something” is, they will experience the challenge of coherence. At a small scale, the solution looks fairly straightforward: establish a shared understanding (a leadership challenge) of what is being built (a product challenge) and how (an engineering and/or UX challenge). As the scale grows, the complexity of the challenge of coherence does as well. With more layers of organizational indirection, there are more opportunities for hidden misalignment and fractal-like divergence of what is “shared understanding” in name only. People genuinely feel like they are leading, engineering, or managing products in the right way and giving it their best, and are frustrated to see just more confetti pop out at the end.

My intuition is that the challenge of coherence is a different beast than any of the other kinds of challenges that I am already familiar with. Recognizing and facing this challenge requires a different kind of thinking, a way of seeing at a larger scale and beyond conventional horizons — yet at the same time, working in the moment, sensing tensions and forces at play. It’s about having a kind of fluidity that allows recognizing the multiplicity of perspectives and not getting overly attached to any of them — yet at the same time, not getting lost among them and retaining a sense of direction. The challenge of coherence requires a sort of patient strategic gardening, the gentle bending of arcs of multiple projects toward a common outcome. Learning to do that well is one of the most rewarding experiences for me these days.

While processing a difficult conversation with a colleague, we found this insight. As leaders, we bring power dynamics into our interactions. Whether I want it or not, my title has sway, and that itself can close or open my opportunity space. How I show up in a conversation has an impact, despite our desire to keep things rational. In my job, having authentic, rich conversations is essential and the trap of leading while sleepwalking is ever-present. A 1:1 of pleasantries and avoiding difficult topics is not just a waste of time, it’s a reinforcement of a habit that makes getting back to the thick of it more challenging.

To me, this means that I need to be able to sense the tension during an interaction, even if it is a carefully concealed one — and be able to tolerate the discomfort of that tension. This capacity of sitting with discomfort has been a quest that developed into a practice for me. There’s something very significant about being able to sense a rising emotion, and instead of our habitual ricocheting it outward (“that guy is a jerk!”) or inward (“omg, I am so bad at this!”), to be able to turn toward it, face it — and befriend it.

It’s really weird, but I am learning that for a leader, that feeling of discomfort is good. It’s a signal that there’s something really interesting happening that they aren’t yet able to see or turn into a conscious thought. It’s an invitation to learn and to explore, an adventure that awaits. And the more we’re able to sit with our discomfort, the better we can answer the call of this adventure.