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.
Having done a bit of work on researching and sketching out strategies this week, I realized that there are some commonalities in their theories of change, a few patterns that I start seeing.
The first pattern is what I want to call a “motor.” Every effective theory of change seems to have a means for sustaining the process of change. When drawing out boxes and arrows in such theories, eventually a motor pops out as a cycle of causal relationships: if we do more of this, more of that will happen, which will allow us to do more of this, etc. It can be something that involves network effects (aka flywheel), or it can be something as simple as “if we deliver <blah>, we get funded to deliver more <blah>.” In either case, there’s something that serves as a source of energy, allowing us to keep going. There doesn’t have to be just one. Just like in any reliable ship, several motors are useful for redundancy. Conversely, if our theory of change is just linear sequences of steps, chances are that it’s not a very durable one.
The second pattern is a “rudder.” Now that we’ve powered the tiny ship of our theory of change with a motor, we need a way to steer it. A rudder manifests as causal arrows that interact with the object of change. They also look like a cycle, but here, they will look more like an OODA loop: ship something, get feedback, adjust, ship something again, etc.
Rudders are critical to a sound theory of change. Change rarely happens in one big splash, and our ideas about the effects of the change tend to seem naive and silly when they make contact with reality. For example, back in the Web Platform days, I kept trying to build more rudders: from Origin Trials to Web Confluence to Lighthouse.
Next time when you’re in a strategic thinking mood, consider your theory of change, be that the one of your organization, your team, or your own. What are its motors? What are its rudders? How do you power and steer the ship of your destiny?
I had a super-insightful conversation this week with a colleague about approaches to resolving pace layering confusion. For those of you who haven’t heard of it, Steward Brand’s concept of pace layers is something I’ve often applied to layering in software engineering: the lower the layer, the more stable it is. The higher the layer, the faster it innovates. For a canonical example, Web sites innovate faster than JS frameworks. JS frameworks move faster than browsers. Browsers typically get updated faster than the operating systems they run on. The pace layering confusion refers to the situation when a project is scoped to span more than one layer. These projects typically encounter constant friction and a shearing force that is caused by the pace layers moving at different pace.
We’ve been looking at a project that is currently caught in this trap, and found a peculiar tension: there seems to be forces that are both trying to split the project up along the pace layer and forces that are trying to keep it together. These forces are distributed quite evenly: the same team members who advocate for a “more platform-like” approach (a proper splitting up at the layer boundary) are skittish about taking the step. And it makes sense: monoliths deliver. From the tougher time to land commits to the lesser degree of control, one more API boundary adds a not insignificant cost. What’s even more troubling, once separated, it might not be clear where the lower layer code will live. Especially when a project is facing tight shipping deadlines, the work of extracting out and maintaining the bits of the layer that doesn’t directly contribute to the product is unlikely to have any mindshare. Why would a product team have a sub-team that’s making a framework? So the project gets stuck in this twilight-zone mode of “we want to move faster, but something is holding us back.”
If you find yourself in a situation that feels that way, it might be a good use of your team’s time to have a pace layering discussion. Is there a weird force that tries to pry your team apart along a yet-invisible seam? How much energy are you spending on counteracting the force of the pacing layer confusion? What might be the code that wants to live at a lower pace layer?
If you’re lucky, there might already be an adjacent team that makes its living at that lower layer. In this case, a conversation about a strategy for transitioning the lower-layer bits ownership to them might be a good first step. Otherwise, it might be worth it to go looking for a partner who could play that role.
A recurring theme in my conversations is the question of platforms. How do I get one? Do I have one? How do I know? Platforms — especially developer platforms — are a really exciting topic for me, so I tend to see opportunities to build platforms in every software project. For engineers who’ve worked with platforms, it’s a common affliction. So here’s a note to self (and y’all who have the same “platform bug”): watch for platforms to emerge.
It’s healthy to be ambitious, but the problem space, especially at the start of the project, might not be platform-shaped. Platforms are two-sided markets, and all vibrant two-sided markets begin with one-sided markets. First, there needs to be something that we offer that the users want. Until that exists, a talk of a platform is premature. Even after we have a great one-sided market going, the problem space might still not be platform-shaped. So… how do I know when it is?
My intuition is to look for exaptation as signs for an emerging platform-shaped hole in the problem space. If there are users of our product who are trying to tweak it, publishing hacks and tutorials, maybe even writing companion scripts that do something other than we originally intended for the product — that’s exaptation. Watching “the street find its own uses for things” is rather uncomfortable, because we all have ideas on how our products should evolve. It takes a certain flexibility of thinking to view exaptation as the ecosystem hinting at the platform opportunity, but that’s exactly what will get you to a thriving two-sided market. Put it differently, platforms aren’t built. Platforms emerge.