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.