Month: May 2021

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.

I have the most amazing job. In my role, I get to talk with many teams across Google, learn from them and help them find how their ideas fit together. Through this adventure, I notice that teams have a variety of mindsets, different ways of approaching their work. Over time, I’ve organized these mindsets in a loose hierarchy that I want to share with y’all. I am borrowing some of the framings from a book by Alan Laffley and Roger Martin. 

At the bottom of the hierarchy is what I call the “playing not to lose” mindset. In this mindset, the team is mainly concerned with survival. Defensive posture, “table stakes” conversations, looking at peers on the market and adopting their strategies is a common symptom of this mindset. When playing not to lose, there’s a strong sense of a reactive strategy: “we must do this or <insert catastrophe>.” More likely than not, playing not to lose is a self-fulfilling prophecy, because this mindset leads to strategic myopia, foreclosing on the opportunities that could take the team out of “not losing.”

In the middle, there’s the “playing to win” mindset. Organizations that have their mindset typically know what they want. They are less beholden to “what will <competitor> do?” thinking and are instead focused on creating value. They are usually playing a few moves ahead, able to hold their strategies and have this distinct proactive sense. Playing to win feels good. Teams with this mindset have this spring in their step and a contagious sense of purpose. They build. They sculpt the future: theirs and of those around them. One downside of this mindset is that the teams are often unaware of the second-order effects of their work, and the value they create is limited to a small group of beneficiaries. It is my experience that over time, the burden of those second-order effects gets to the point where playing to win is no longer feasible. The organization either collapses into playing not to lose, defending what they’ve built, or they seek another option.

This is where the third mindset comes in. It’s a lot more rare than the first two. I find that there are teams that “play to change.” They have mastered playing to win and learned to notice the unintended consequences of their value-creation. So they are asking themselves: “what is the change we’d like to see happen in the world as a result of our actions?” The focus shifts from direct value creation to second-order effects. The indirect consequences become part of the theory of change. Strategies are based on them. Teams who operate with this mindset are keen on systems thinking. The purpose of innovation shifts from “being the most/best/awesomest,” to something much deeper and nuanced, connected to the fate of humanity. Organizations with this mindset tend to garden, rather than sculpt. There’s a certain gentleness and awe that comes with it, as well as a sense of detachment from the existential dread.

Chatting with one of my coworkers, we recognized that there’s a pattern that is the inversion of the somewhat popular “strong opinions, weakly held” framework. 

This pattern is most commonly found in situations where the power dynamics are severe, like in a meeting between a VP and a junior engineer. While the VP might be sharing some thoughts they find interesting, the engineer will be having a hard time not interpreting them as directions. And if unable to resist that temptation, they may find themselves executing on a poorly-formed idea with the full conviction of the reporting level differential: weak opinions, strongly held.

Google has several early-day legends, possibly apocryphal, about its founders’ idle musings turning into projects overnight, then hurriedly cancelled in embarrassment. “Larry said he wanted <foo>, so that’s what we’re doing now.” Nobody’s happy in this situation: the executive is frustrated in their inability to contribute nuanced perspectives, and the team loathes marching in resentment toward the destination they know is futile. If they’re lucky, there will be that one engineer who goes “Whaaat? This is bonkers!” despite the shushing of the colleagues. Or if not, the leading while sleepwalking trap gets set.

In my experience, this pattern pops up more often in teams that struggle with the culture of examining ideas. To examine an idea, one needs to be able to hold it apart from people (and their power) associated with it, to turn it this way and that. Given how quickly we humans embed ourselves in our ideas, this mindset requires ongoing practice. The practice might be part of the process. When designing Blink governance, we wanted all feature proposals to go through a transparent, public process, with a forum for the proposal discussion to take place. The practice might also look like leads regularly sharing their missteps and reflecting on them. Whatever form it takes, this practice is often uncomfortable, feels like friction and something to be optimized away. 

My colleague and I had this observation about companies who are in partner-like relationships (be that a standards organization or an open source project): there tends to be this weird unhealthy dynamic that keeps playing out. Concepts or proposals of one partner are met with allergic reactions from others. If we study the source of reaction very carefully, it comes from the dismay over not being included earlier in the process, rooted in an often-earnest desire to contribute productively and participate in the idea formation. However, the strength of the allergic reaction perpetuates the fear of rejection of the proposing participant. The offered proposal was already a product of the anxious worry: is it good enough to be considered? Have we thought through all the angles? Are our pros and cons beefed up enough? And so the vicious cycle locks in. Partners gravitate toward closed processes, only surfacing things they must, and there are inevitable heated debates. The partnership deteriorates.

We noticed that this fear of rejection has a fractal-like quality. It happens at individual, team, organization, and industry level. For example, back when I still wrote code, a common challenge that I helped junior engineers overcome was the “black hole CL” problem. There’s so much early hesitance to just publish a patch that the engineer finds themselves adding a bit more to the change… and then a bit more… and a week later, they have a massive change that a) can’t land as is, because the codebase has already moved on, and b) who’s going to review that? And when I finally find time to review it, will I be annoyed and irritated? Yup. Notice how much this echoes the partnership dynamic above.

I wonder how much of our failure to connect with others stems from the fear of rejection, from our attachment to the perceived value we’ve created? One trick I have here is something I borrowed from Brené Brown, and it’s super simple. I gently detach “my Self” from “what I made” by adding the word “Crappy” to it and sharing as early as possible. I find that I produce “cappy design docs,” “crappy decks,” and “crappy prototypes.” For example, it took me 10 minutes to write this crappy little piece. Most often, these artifacts are indeed crappy — but they help others understand what I am doing and start contributing. And that’s not crappy at all.

Picking up on last week’s 3P insight, I want to share some insights I’ve learned about a common trap of working in two-sided markets. I call this trap the “productification trap”, and it appears in two different varieties. 

The first variety is more common at companies and teams that have accumulated expertise of building consumer experiences, mastering the 1P-2P relationship and elevating consumer experience as the product. This expertise tends to create blindness toward the other side of the market. These organizations tend to underestimate the potential of nurturing a relationship with developers and treat them as annoying gnats, or at best tolerate them. A common sign of the 2P productification trap is an ecosystem whose developers endure high costs of participating. I once used the metaphor of “crawling over crushed glass to just ship something.” Many mobile developer ecosystems began their journeys from this trap.

Another variety occurs with companies who excel at 1P-3P side of the market. Their products offer amazing developer experiences, yet tend to not pay attention to the consumer outcomes. As long as developers are happy, we’re good, right? The developer experience becomes the product. A common sign of the 3P productification trap is an ecosystem where user experiences are bloated and unwieldy. When thinking of ecosystems in this trap, I am reminded of enterprise tools and at many points in its life, the Web.

In both varieties, the trap springs when we lose sight of the two-sidedness of the market — and it’s incredibly tempting. The two sides introduce a polarity, a dynamic tension that is only resolved through the death of the market. And polarities are challenging for us humans. We tend to want to collapse the tension and veer to one side. “Just tell me, are we about users or developers?” is a question that we pondered a lot when I was TL-ing the Web Platform team. Turns out, the question reveals a thinking error: this is not an either-or kind of problem. W3C tried to answer this question through layering, which is valiant, but is also an attempt to evade the dynamic tension.

In a two-sided market, the organization can be exceptionally effective if it has capacity to navigate this polarity, to understand the interconnectedness of the relationship between consumer and developers. More often than not though, it will find itself trying to escape one trap and swing wildly into another, unable to tolerate the tension.

The unclear theory of change often haunts conversations about strategy — especially the longer-term strategy. It may be worth pointing out the ghost: “what’s our theory of change?” If you look up the basics of the theory of change, this might seem simplistic. However establishing a shared understanding of the causal links between short-term and long-term goals is an exercise that almost always yields productive outcomes.

One of my vivid memories is that of my former colleague, a then-newcomer, making their first presentation to the team leads. In a few slides, they outlined the theory of change based on what they learned from talking with the team. Though it was merely a summary of already-existing embodied knowledge, the reaction varied from “omg this is brilliant!” to “this is not at all what we’re doing!” The sudden apparition of the theory of change was startling. The team was months into the project, yet didn’t have a shared understanding of how their daily work shaped the path to their long term ambitions. Though that particular example was particularly dramatic, I’ve now seen this scenario play out many times.

A common symptom of unclear theory of change is endless contentious conversations between tech leads that the typical “disagree and commit” tactic can’t seem to allay, or sub-teams slowly but surely diverging and building duplicate bits of the stack. In these situations, we’re better off pausing to wonder: are there different theories of change at play? And what they might be? It may seem silly to sit down as a small group of leads and draw some boxes and arrows — this stuff should be obvious to anyone, right? Yet, if you’re experiencing the symptoms, the silly exercise might be just the thing to bring some peace to the haunted team.

Complex adaptive systems tend to make it difficult to make guesses about precise shifts and movements. Unlike in complicated systems, accurate call shots are rarely a thing. However, if we pay close enough attention, we can spot patterns (events that keep repeating) or forces (tendency to move toward certain kinds of outcomes). In a conversation with my colleagues, we uncovered this possible pattern. It appears that in an organization of technically-minded people (like an engineering team), there’s an almost impossible-to-overcome force toward optimization.

Engineers tend to love to hang out in complicated spaces. Writing code feels like this perfect mix of unconstrained creativity within fairly stable constraints. It feels like flying, because there’s enough unchanging laws of physics to support the flight. Optimization is the zenith of the complicated space (can you make it go faster? in fewer lines of code? using less memory?) and optimization work tends to emerge spontaneously all over the place.

Unfortunately, in complex spaces, it is very hard to tell what needs to be optimized. So the emergence of optimization efforts tends to be guided by the surrounding forces. Folks who are happy in complicated spaces will look for constraints that are stable and optimize around them — sometimes to ill effect.

For example, if I direct my team to embrace innovation and encourage novel thinking, but forget to adjust performance management structure, I might be unpleasantly surprised that the stream of innovations comes as a barrage of tactical tweaks rather than a few bold ideas. It’s helpful to remember that the gravity-like force of optimization is always there and worth reflecting on where it’s propelling your engineering team.

Talking with one of my colleagues, we arrived at this interesting insight. There’s a certain kind of trap that a leader might find themselves in. We named it the “sleepwalking leadership.” It seems to disproportionately afflict leaders who hold a lot of power while facing immensely complex, wicked problems. The vast scope of the challenge can be disorienting and anxiety-inducing, and a leader might find themselves in a position where they demand that their team do something impossible: to make complexity simple. By delegating sitting with complexity in this way, the leaders unwittingly start the process of peeling away from reality. The reports will conjure up well-polished plans and provide crisp updates, striving to deliver something that makes sense to the anxious leader. And given that they are effective and brilliant people, they will succeed. There will be long-running programs in place that deliver on clearly-defined metrics and dashboards that show progress. Except the picture they continue to paint will look less and less like what is actually happening. And since they’re the people facing the reality, the team will know it, but be afraid to wake up their sleepwalking leader.

Having been on both sides of this trap, I am learning that the leadership in a complex environment might come down to my capacity for non-anxious presence. No matter how hard, it is the leader’s burden to endure the nature of the challenge.  I might be saying all the right words, and doing all the right kinds of things, but the overly sharp response in a crucial meeting, or even tension in my voice can produce a shift in what mission the team embodies. Is it what’s on the first slide of our decks at the all-hands? Or is it more about protecting the anxious leader from all the complexity?

I hear folks using the terms “3P,” “1P,” and even “2P” or “0P” often in my line of work, and I am realizing that many times, these words have subtly different meanings for those who use them. So I figured: hey, maybe I could write a blurb capturing my understanding of this. So here goes.

The term “3P” or “third_party” typically enters the scene in two-sided market setups, when there are three parties at play. Two-sided markets are exciting to me, because they have these additional opportunities of indirect influence. With the typical one-sided market (not to be confused with a similar term from investment lands), it’s just producers and consumers. I sell you stuff and you buy it. In a two-sided market, there’s an additional side to the market: the category of users I’ll call developers. 

A two-sided market unlocks fascinating possibilities of non-linear effects. If I, as a first party, can influence my developers to create products that lead to outcomes that add to both our bottom lines, it may feel like I suddenly gained a massive new team that works for my organization. What’s even more exciting is that more beneficial outcomes within the ecosystem leads to more satisfied customers, which in turn attracts more developers. If I am lucky, I might even find myself in a self-sustaining ecosystem, where most of my ever-growing bottom line is generated by developers.

With this understanding at hand, here’s a disambiguation cheat sheet: when you say zeroth-party (0P), you probably mean a subset of first-party (1P). When you say second-party (2P) and you’re not talking about users/consumers, you probably mean a first-party partner (1P). And certainly, when you’re saying third-party (3P), you’re discussing a two-sided market setup.