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?