Week of 2021-05-17
The ghost of unclear theory of change
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.
🔗 https://glazkov.com/2021/05/21/the-ghost-of-unclear-theory-of-change/
The productification trap
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.
🔗 https://glazkov.com/2021/05/21/the-productification-trap/
Crappy and the fear of rejection
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.