Today the acedemic side of me took over. I think the reason is that I discovered our CTO (Mikolas Hämäläinen) to be reading a lot of scientific articles as well and I worked closely today with him. What I present here is work in progress and some initial playful thoughts on what I have now labelled as “Developer eXperience maturity model”. I might have touched the idea previously, but I felt like returning back to it today.
Side note: I’ve noticed a change in my thinking. When ever I see a business I start to analyze the most likely business model behind it - strengths and weaknesses.
The idea follows the familiar REST maturity model (Richardson Maturity Model) which describes steps to glory of REST. That is technological approach and I wanted to have more like business-ish / mindset approach. I can’t yet find the right words for this. Richardson Maturity Model contains 4 levels (0-3). My Developer eXperience maturity model is not nearly as sophisticated or refined as Richardson Maturity Model.
Developer eXperience maturity model
The idea for this model came to my mind around 2018 while I was writing the book API Economy 101, but it was not included in there as such as model. After that it has been cooking and boiling in my head. I’ve used the model in presentation material occasionally. I’ve noticed that it resonates with the audience pretty well. People seem to get it, it’s simple enough. The below illustration is taken a few steps forward compared to the one I’ve used previously. The model can be devided to two segments: introvert and extrovert.
In the introvert part focus is inside the company developing the API. Or then the focus is inside own team only. This segment contains two phases: techno-centric and product-centric.
Techno-centric can be defined as centring on the use of technology; emphasizing and promoting the importance or value of technology. In techno-centric stage API is just created. It might be simple API for one microservice component and used by 1-2 developers inside the company. It might be a little cumbersome to use and requires context knowledge. It might lack proper documentation. I would call this as the prototype of a API product. The focus is on getting the technology to work and provide some value for limited target group.
The API is often for internal use and might evolve to stage in which it begins to be treated as a product. Often this is internal API which becomes popular inside a bigger company and other teams + divisions start to use it. When you reach that point you are almost forced to think it as a product with proper documentation, enable easy onboarding (internally still).
The API might be available for public as well. A product-centric organization is one that is focused on the products it brings to market rather than the customers that buy those products. It looks to develop new products by leveraging technology or specialized skills that exist in the company.
The second segment is the extrovert in which focus is outside the company developing the API at hand. This segment contains again two phases: customer-centric and developer-centric.
In the customer-centric phase focus and eyes are on the customer. I find this simple comparison of product and customer-centric approaches rather useful. It’s not very academic, but I would assume facts based support for the model is easy to find.
The last step is to understand that developers are the primary customers as we defined in the API economy definition 2018 in API Economy 101 book. It’s fundamentally important to understand that dispite the primary focus on developer, the manager or other person near the developer making resource related decisions is also your target group. Yet most of your focus should be in the developer, thus developer experience.
You probably notice the chasm between introvert and extrovert. I’ve taken the concept from Moore’s chasm which is often connected to diffusion of innovations.
In Developer eXperience crossing the chasm requires a mindshift from introvert to extrovert. Your focus turns outwards facing instead of inside. This requires you to think about customer relations (customer-centric) and eventually developer relations (developer-centric)
That’s about it. I need to spend more time on this and fill in more details, but not now. It’s Friday and I want to enjoy some moments with wife.
Some more to read from 100 Days DX
- #85 - Great Developer eXperience requires fluent internal workflow
- #84 - Theory of Economics of Developer eXperience
- #83 - The Space of API Design Decisions is missing
- #82 - Purpose of API Evaluation Framework
- #81 - Should We Move to Stack Overflow?
- #80 - Four data driven ideas for improving API documentation
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!