Week of 2021-10-25
Stages of customer-centric maturity
While riffing on customer-centric mindsets and the veering toward first-order effects pattern, my colleagues and I came up with this idea of stages of customer-centric maturity. These stages are modeled after the personal development stages, like the ones in adult development theory. The basic premise is that teams typically progress through these stages as they become more experienced in the trade of developer experience, with each new stage building on the insights of the previous one: the include and transcend type of thing, rather than a wholesale replacement of fundamental premises.
At the zeroth stage of customer-centric maturity, we have the teams who come together to build cool developer tools and other kinds of products. The thought about developers is limited to “if I like it, then others will like it, too” and perhaps some vague notions of “shifting the developer paradigm.” There’s a sense of a rather imperial perspective, with nearly zero investment into understanding customers. These teams tend to build amazing things that nobody needs, though occasionally, they strike gold, perpetuating the “if you build it, they will come” myth.
After accumulating enough scars looking for problems that fit their predetermined solutions, teams tend to graduate to the first stage of customer-centric maturity. The pendulum swings all the way in the other direction. “Make developers happy” is the mantra. Intense focus on developers as customers is at the center of prioritization/investment decisions (aka first-order effects). If the team at this stage is building a UI toolkit, most of the attention will be devoted to ergonomics, faster build cycles, or seamless refactoring. Talking about users who might or might not benefit from developers relying on this UI toolkit is usually met with “well, that’s important, but isn’t it up to developers to do the right thing?” As a result, teams at this stage tend to struggle squeezing diminishing returns out of “faster horses”, unable to break out of the local maxima of developer wishes.
Somewhere around here, the awareness of connection between the first-order effects and the second-order effects may develop, potentially leading the team to the second stage of customer-centric maturity. Teams realize that having satisfied developers isn’t the end goal. Rather, it is the means to improve satisfaction of users: customers who will enjoy (or suffer from) the products made by developers -- the second-order effects. Thanks to the constant pull toward the first-order effects (as outlined in the DX pattern), the arrival to this stage may be elusive. However, if the team perseveres, it is rewarded with a much broader perspective that transforms local maximas from inescapable cages to minor bumps along the way.
One of my colleagues had a wise observation that within a large organization that ships developer-facing products, teams might be scattered across the whole spectrum of stages. In such a situation, teams will likely do a lot of talking past each other. For example, if a team operating at the second stage decides that the developer satisfaction metric can dip to accommodate a shift toward better user outcomes, they might encounter strong resistance from the team that’s still at the first stage. To them, such a move will bring back the pain of the scars they earned at the zeroth stage. Perhaps this simple framework could help them understand where their disconnect is coming from?
🔗 https://glazkov.com/2021/10/28/stages-of-customer-centric-maturity/
Framing and solving diverge-converge exercises
There’s this fairly common technique: the diverge-converge exercise. I first heard about it when learning about design thinking, and now recognize it in other places. The gist of it is fairly simple: break down your thinking process into two distinct phases. In the first phase, encourage divergence of ideas to broaden the space of possibilities. In the second phase, study this space to converge on one artifact that best satisfies the intended objective of the exercise.
When working on a decision-making framework, I realized that there are two distinct kinds of this diverge-converge exercise, each with a different goal. I am going to call them “framing” and “solving”. As I implied before, the first one roughly maps into the Complex Cynefin space, and the second one into the Complicated.
The solving diverge-converge exercise is the one that I see described most commonly. Invest a bit of time in the “diverge” phase to generate a rich pool of possible alternatives, then compare them to pick the one that works best in the “converge” phase. A typical engineering doc that’s an outcome of the solving diverge-converge exercise has several alternatives listed with pros and cons, and a discussion followed by a decision to pick one of these alternatives. This kind of diverge-converge exercise is very much about finding the best fit, and it benefits from having a strong fitness function that guides the process of making the pick.
The framing diverge-converge exercise might seem similar, but has an entirely different mindset. Here, the “diverge” phase is meant to collect perspectives that all describe something that’s difficult to see from just one side. When framing, the “converge” phase is no longer about picking the best fit. Instead, it’s the process to see the larger picture, incorporating all perspectives, studying the differences and similarities between them to synthesize a larger perspective. A typical artifact here is a problem statement doc, describing multiple perspectives of the stakeholders and outlining how they relate to -- and interact with -- each other, along with the outline of the synthesized larger perspective. In the framing diverge-converge exercise, the choices aren’t narrowed down. Instead, they are used to improve the understanding of the space.
When trying to compare the two kinds, the blind men and the elephant parable comes to mind. When applying the solving diverge-converge exercise, the big question will be whether it’s a fan, a snake, a tree, or a wall: we have to pick one. When applying the framing diverge-converge exercise, we might actually see the elephant.
🔗 https://glazkov.com/2021/10/24/framing-and-solving-diverge-converge-exercises/
The story of agency
Another kind of story that I’ve encountered in my exploration of coherence narratives is the story of agency. Again, it’s loosely borrowed from the Four Needs Framework and plays a catalytic role similar to that of the story of belonging.
The story of agency is all about going it alone. It’s about striking on our own, finding our own path, independence, and self-sufficiency. It can also be about perseverance, toughing it out, defending, and standing tall. The story of agency is deeply woven into American culture, celebrated on July 4, in remembering the Alamo, and oh so many movies with a lone heroic protagonist.
Just like the other catalyst story, the story of agency leans on the structure of another story. Combined with the story of an opportunity, it celebrates uniqueness and breaking with convention as the precious ingredient. Mixed into the story of a threat, it uses the same qualities to draw the bright line between life and death.
Looking at various organizations, I am picking out two distinct patterns. First, the story of agency often plays a role in diminishing coherence. It is the story of break-ups, of abandoning the common goal, of “this is not working out.” Behind every tense conversation, irreconcilable disagreements, and teams deciding not to collaborate lurk stories of agency.
Second, the stories of agency and belonging tend to blend into this curious nested-doll relationship that increases coherence. The story of agency provides the lens to evaluate the external environment, while the story of belonging sets the tone for internal: “we come together to be unique and different from others.” This is also a very common strategy in marketing. Apple’s “Think Different” poster immediately pops to mind when looking for an example of such a nested doll. I buy your product to stand out, while at the same time becoming part of a group.
Through this symbiotic relationship of two stories, organizations and any groups of individuals create boundaries. The story of belonging is what defines the in-group, and the story of agency -- the out-group. The story of a threat, catalyzed by the in-group’s story of belonging, is often based on the story of agency: the threat from whom? -- the out-group, of course.
For example, a team’s narrative might be about building something truly revolutionary (story of agency + story of opportunity) while persevering in a rapidly shifting, or even hostile conditions (story of a threat + story of belonging). If such a narrative is particularly resonant and crisp, it tends to live for a very long time, sustaining coherence of a group and becoming this group’s identity.