Week of 2021-05-24
Watch for platforms to emerge
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.
🔗 https://glazkov.com/2021/05/28/watch-for-platforms-to-emerge/
Playing to change
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 less 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.
🔗 https://glazkov.com/2021/05/28/playing-to-change/
Weak opinions, strongly held
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.