Week of 2021-10-11
Veering toward first-order effects
Have you ever driven a car that pulls to one side? It’s often subtle, but after a while, the counter-steering effort becomes impossible to ignore. This metaphor comes to my mind whenever I encounter a common developer experience pattern: the veering toward first-order effects.
To set the context a bit more, let’s arrange the effects of producing developer surfaces in two orders. The first-order effects relate to producing the developer surface. When we ship an API, we want it to be adopted, to be used broadly. Thus, when we measure first-order effects of our efforts, we look at the API adoption rate, developer satisfaction, etc.
The second-order effects relate to developers producing user experiences using our developer surface. At the end of the day, an organization that invests into shipping APIs does so -- intentionally or not -- to influence the overall state of user experience in some way. When we measure second-order effects, our metrics will likely track changes in the user experience. Does using our APIs result in products that are more secure, performant, accessible, etc. for the user?
Based on what I’ve seen working with developer experience teams throughout my career, there’s a pronounced pull toward first-order effects. They are easier to measure, have a shorter feedback loop, and are more familiar to folks accustomed to shipping consumer products. Even if a team sets out to influence the state of user experience at the beginning of their journey, the appeal of relative immediacy of first-order effects is so strong that the original intention often gets left behind.
A common symptom of forgetting to counter-steer toward second-order effects is the loss of strategic flexibility within a larger organization. When the first-order effects become the means onto themselves, they tend to get entrenched in a local maxima of developer expectations, stuck in an optimizing loop. An organization that contains teams stuck in that particular way feels like it is unable to do anything about it: everyone is seemingly doing “the right thing,” and prioritization exercises quickly devolve into peanut buttering. When something like this is happening, it’s a good hint that the concept of second-order effects got rolled into a dusty corner of the team’s shared mental models space, or ejected altogether.
To counter-steer, organizations must exert conscious effort to keep second-order effects in the shared mental model space. Whether it’s constantly pointing at them during the all-hands, setting up the metrics structure to reflect user experience shifts, or even just reminding about the unyielding force that -- like that darned car -- never quits pulling, it's an investment that's well-worth the price.
🔗 https://glazkov.com/2021/10/11/veering-toward-first-order-effects/
Cutting or highlighting?
Talking with one of my wise colleagues, we arrived at this neat framing around making decisions. “Decision” is a weird word. My friend Neel tells me that its Latin root is literally “to cut away,” and that recognition that a decision is always about narrowing the list of available options can be both liberating and anxiety-inducing. The interesting bit is that sometimes, decisions aren’t meant to cut away.
As it often happens in larger organizations, we tend to live in the swirl of the short-term and long-term objectives. And it is definitely a swirl: the art of leadership is picking out the right mix. Blend in too much short-term, and we’ll find the team stuck in the corner of a local maxima, overconstrained by its previous choices. Blend in too much long-term, and the team fails to make progress that’s necessary to keep that motor running.
To adjust the mix, leaders decide. A common mechanism here is prioritization: picking a shorter list of things that the team needs to focus on. One approach to prioritization is to apply the cutting mindset, as in cutting the list in half: keep what’s above the line and discard the rest. For example, let’s suppose I want to build an app that is available on both Android and iOS phones, but I want to prioritize iOS users. Applying this cutting mindset, I just forget about Android for a while, break out my XCode and start typing some Swift. Only after the iOS version is shipping do I start looking at the rest of the list. Given how many unexpected turns a typical software project takes, will I ever get to do that? Maybe. Will this approach result in a painful migration or two -- or worse yet, the “release polka” where my app always looks out-of-date on one platform compared to the other? Probably.
The cutting mindset is straightforward and clarifying. Yet, in situations where the rest of the list is still a thing we want to do later, it often leads to inferior choices. In these situations, we need something different. Instead of cutting the list, we want to highlight the items on which we want to focus -- while still keeping the rest of the list in mind. With this highlighting mindset, the choices we make take on a different spin. Instead of asking “what’s the next step to deliver <prioritized item>?” we ask “how can we take a step toward delivering <prioritized item> that also takes us closer to completing the whole list?” The thing is, the items on our lists are rarely orthogonal and live in clean separate boxes. More often than not, considering them as a whole reveals opportunities for advancing toward completion of multiple items simultaneously. In my app example, while still focused on the iOS release first, I might consider picking a UI framework that also runs on Android, or at least build my middleware in a way that is portable.
When making prioritization decisions, it’s worth being explicit about the mindset with which you’re approaching, discussing with the team the reason you chose one over the other. Otherwise, despite your desire to highlight, an eager PM might swiftly cut your long-term objectives out of the mix. Or conversely, the team will continue to swirl aimlessly in the ideals you have already forgotten about, from back when you thought you cut them away.
🔗 https://glazkov.com/2021/10/08/cutting-or-highlighting/
The story of belonging
Next in my adventure across the coherence narrative realm is the story of belonging. It sort of maps into one of the fundamental needs from the Four Needs Framework, but plays a subtly different role here.
The story of belonging is also something that is easy to spot as a felt experience. Someone wise suggested that humans are wired for connection, and the web of these connections is what creates the gravitational pull in the story of belonging. There’s something about being together with others, being part of the group, next to those who consider you kin, being loved, included, and understood.
When I try to examine stories of belonging, I notice something interesting. They usually contain the words “we,” “community,” “together,” “teamwork,” “alignment,” “unity,” and so on, but structurally, it’s almost always not a standalone story. Instead, the story of belonging acts as a powerful catalyst, laced into the story of a threat or the story of an opportunity. Just milling around together is one thing, but something magical happens when the “we are” is combined with “under attack” or “the future”: the capacity for coherence shoots up like a rocket. No matter what kind of compounding loop we might face, it seems that doing it as a tightly knit group feels natural and right to us humans.
To add to the weirdness, the loss of belonging is a common story of a threat -- and finding it a common story of an opportunity. In our interconnected world, this kind of ouroboros is in itself an abundant source of compounding loops. It’s one reason why teams tend to form boundaries and organizations grow silos. It is also the undercurrent behind the craving to gain more likes or followers and many similar societal dynamics.
Considering the story of belonging as means to improve organizational coherence, a couple of thoughts come to mind. First, the stories of belonging are quite inert by themselves. The need to combine with compounding-loop stories to get traction. Second, we live and tell multiple stories of belonging simultaneously. Navigating all these stories is tricky, and growing new stories of belonging (“we are a team!”) is a careful, finicky process that often bumps against all the participants’ stories, taking patience and time to develop. Maybe this is why we use the word “culture” to describe a mature organization’s story of belonging?