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.