Category: What Dimitri Learned

Growing a well-used platform developer surface is exceptionally tricky work. I’ve heard many stories of the team investing months (or years) into building a new set of APIs or protocols, only to encounter at best lackluster interest. To arrive at a more effective outcome, a practice that I’ve seen (and applied myself) is rock tumbler teams.

Rock tumbler teams start using the new stuff before it’s ready. They become the early consumers of a not-yet ready developer surface, providing continuous feedback to the makers of this surface. Ideally, they do this as part of some broader mandate, and have some skin in the game: they aren’t just prototyping and building interesting demos. Their mission is a composite of questing and scaling: they are to both build something useful and to improve the developer surface they consume.

One thing I’ve learned is that it’s important to set these expectations. A few of my attempts to apply this practice ended up in additional suffering because I either didn’t cogently describe the rock tumbler (“here’s what you’re getting into”) or didn’t continue reinforcing it over time (“don’t forget, y’all are rock tumblers”) I remember one TL cornering me in the hallway: “This crap’s not ready! Why are you selling it to me? Not cool.” I may have been overly optimistic describing the benefits of that particular crap and skimmed over the whole “you’re eating unbaked cookies” bit.

Thriving in a rock tumbler team tends to require a mindset of exploration and change. The work will feel painful, with frequent backtracking and changing direction. The leader of such a team typically builds a strong narrative around the value of the composite mission: “we’re eating unbaked cookies so that when they are ready, they are truly amazing.”

A common pitfall that I’ve seen here is the assumption that every team can be a rock tumbler team, possibly stemming from extending the practice of “dogfooding” to developer surfaces. In my experience, this tends to not end well — the additional pain of implicit rock tumbling causes teams to work around the rough edges they find, including choosing to “screw it, we’ll just build our own.”

I was working on a strategy and helping review another this week, and found this framing helpful. Especially in mature organizations, the challenge tends to reside not in determining how to do something, but rather in finding what makes this “how” difficult for this organization. 

The common symptom here is dust-covered stacks of past plans that look eerily familiar to what is being proposed. There’s a certain Groundhog Day quality to these. “Oh, we’re pitching this thing again? Okay, I guess it’s been a few years since we last tried it.” The “it” might range from product ideas to processes and practices. Having cross-functional communication issues? Let’s start an XFN working group. This time around, it’s sure to bear fruit, right?

Putting our systems thinking hat on, we can see that well-established orgs are held together by forces that animate them. The dynamic equilibrium of these forces tends to also preserve the status quo: the plans that failed will likely fail again in similar ways, if tried once over. Think of it as a cousin of procrastination: just like with us humans, the actual challenge might not be the work itself, but rather the inner organizational tensions and conflicts that make doing that work next to impossible.

A useful shift here might be to focus on why, given these animating forces, we are to expect a different outcome. What’s changed about the situation? How did forces change and in what way since our last attempt? The generative question that tends to help is “why will this be hard for this particular team or organization?” 

A word of caution: it’s easy to land on despair when looking into what animates an organization. Discerning and reflecting on team pathologies asks for heaps of patience and compassion. Perhaps this is why we often fall back just rolling the dice again.

While spelunking my network of assumptions, I often find it helpful to understand what animates my actions. What are the underlying stories that shape how I behave? Over time, I ended up with this simple framework of sorting my stories into three buckets: want, should, and will.

The “want” is the bucket where cravings and aversions live. “I want ice cream. I don’t want to be alone.” The “want” forces are lightning quick. They’re here before I know it, impulsive and somehow innate. “Wants” feel urgent and important, yet they are indiscriminate: there are many specific ways to satisfy them. Ice cream might be swappable for reading a fun book.

The “should” bucket is occupied by stories learned from experience. “I should put away the food before it spoils. I should be a good neighbor.” The “should” stories represent my understanding of the rules that make the world go, identities imposed or uncovered. “Shoulds” feel rigid and immovable, but they are also full of errors and gaps. Some of these were learned very early in life and encased in the amber of my mind. The lack of subtlety in “I should be nice to others,” if left unexamined, can quickly get me into the trap of insincere manipulation.

Finally, deliberate and persevering stories fall into the “will” bucket. “I will work extra time to finish the task. I will do push-ups every day.” The “will” stories feel like exercising agency.  Here’s where I need to pay special attention. More often than not, these stories are animated by other stories. Looking at “I will study hard for the exam… because I should be a good student” reveals that the seemingly deliberate choice to study (will) is animated by conforming to an identity (should). Whenever I find that a “will” is animated by a “should” or a “want,” there’s a chance that I am deceiving myself. There’s less agency in that causal chain than I’d like to believe.

This framework helps the most in situations where I feel stuck or caught up in a vicious cycle. Taking a quick breather and labeling the stories, I can turn each over and apply a corresponding move: discern the animating story behind the “will,” swap for a different outcome in a “want,” examine a “should” to enrich it with subtlety. Each move has potential to open up my option space even in seemingly hopeless situations.

In a couple of conversations this week, this distinction between people management approaches kept popping up. I am pretty sure this is incomplete, but it seems useful, so here goes. In my experience, it feels like competent people management falls somewhere in the spectrum between people-keeping and mission-keeping.

At one extreme are the people-keeping managers who focus entirely on the health of the team. If you are their report, they always have your back. They will make sure that your career needs are taken care of, going to tremendous lengths to find a way for you to flourish. At the other end, the mission-keeping managers are aflame with the big idea and enlist followers to make it happen. They may zig and zag, and have setbacks, but every report knows where they’re going, no matter how long the journey.

I’ve known many great managers, and it doesn’t seem like there’s rightness or wrongness in this spectrum itself. I’ve seen people-keeping managers who over time build loyal followers who feel like they belong, having this almost perfect alignment with the others in their team. They make sound tiger teams, having a great time no matter how they are applied, with mission almost becoming a byproduct of being together. In this way, their specific mission may change, but everything they touch, they leave a little bit better than before.

I’ve also seen mission-keeping managers who set out on ambitious (and sometimes, truly quixotic) quests and attract followers. Regardless of whether they eventually succeed, their determination and clarity of purpose also acts as a magnet. These teams tend to be less cohesive than those led by people-keeping folks, but the folks who stick it out to the end tend to be highly resilient, and those who leave remember their time on the team as formative.

Most managers know intuitively where they are on this spectrum, and they are better off  conveying that to their reports. If I am joining a team led by a manager with a strong mission-keeping slant, I know that my career mentoring will have to come from elsewhere. This is just not something my new manager will be interested in. The people must fit the mission. If I am joining a team of the manager who’s strongly people-keeping, I need to be prepared to have fluidity and uncertainty — the mission will shift and change. Because here, the mission must fit the people.

One of my colleagues shared this metaphor and I was mesmerized by it, expanding into this vignette. They suggested that if we could pretend that teams are playing music, we could imagine the kind of music that we would hear.

A team that’s persevering toward a milestone, gritting teeth and buckling down is likely playing a march: methodical, brash, simple rhythm that keeps them awake and aware of the pace. Bloody calluses be damned — as long as you’re putting your foot in front of the other, you’re doing your part. 

A well-organized team that builds intricate products plays a symphony: multi-faceted, polished, nuanced. There might even be an operatic diva whose voice makes your heart ache from beauty, bending reality and capturing your imagination. Everybody knows their place and time, structure rules everything.

Some teams don’t quite know how their work will come together, but their shared faith in each other, backed by centuries of collective experience, hints that it will be marvellous — and fun. This team plays jazz. Unpredictable, mercurial, brilliant and yes, sometimes frivolous.

Each kind of music asks to be held differently. If I only know that I am a second violin, it might be tough for me to endure a grueling march and be anxiously reaching for a non-existent score in a jam session. I’ve yet to learn how to pick the right marching boots, or let go of the rigid structure and fixed identity.

This metaphor gives me a new lens. When in a new environment (which is often in my line of work), I look around and listen. What music is the team playing? Who is not playing the same kind? Where are the confused marchers stomping on the delicate filigree of the symphony? Where are the sad jazz musicians making monotone sounds in service of a march? Frustrated divas trying to find their opening in the effervescence of jazz? In each mismatch, there’s an opportunity — a starting place for gaining more coherence.

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.