Week of 2021-06-07
The challenge of coherence
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.
🔗 https://glazkov.com/2021/06/11/the-challenge-of-coherence/
Align on interop
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.
🔗 https://glazkov.com/2021/06/11/align-on-interop/
Letting go of mind-reading
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.