After writing 35 days in a row one post per day about DX, I started to think what kind of skills/expertise is needed to build great Developer eXperience. Dissecting the thought resulted to pie chart below. Probably not even nearly final, but still it’s evident that DX is not just engineering. The gray dots/circles mark the themes touched so far in this article series. The dots are just “around” the areas not exact mapping of the post topics.

At this point I remembered the API as a Product thinking and the similarities are pretty obvious. If you want to know more about that, check out book by Amancio Bouza and Andrea Zulian “API Product Management”. Another resource is book I wrote with 3 other colleagues “API Economy 101”. If API as Product would be dissected similarly and the “maps” would be places on top of each other they would probably overlap like 75-85%.

I would love to find time to sit down with Amancio Bouza and do the mapping, then write the ideas down and let the world enjoy the fruits of our minds. I need to arrange that some day.

Over the years of developing APIs and toooling around it, it has become obvious to me that great sustainable DX is a lot more than engineering only. I already wrote about “Full stack DX” which was still technically oriented, but I wanted to have more holistic 360 view to Developer eXperience. Thus the post. This might also clarify a bit the topics to cover in rest of the posts.

About the slices and disciplines

Just a few quick thoughts on the items in “360 DX” piechart. Yeah, that 360 had to be injected there, it seems to be present in many concepts now. You havee to cover all angles of the subject…sarcasm

Politics This one is put under internal DX which was discussed in one post. The idea is that as DX lead you are balancing, negotiating and compromising between the external DX (consumers) and internal DX all the time. You probably can’t get all you want in the external DX without losing some agility or maintainability internally. Thus it’s politics. Traditionally politics is understood to be a set of activities associated with the governance of a country or an area. It involves making decisions that apply to members of a group. Just replace the “country or an area” with you product’s DX. DX development requires resources and your company probably has limited amount of that. You are negotiating with others about the usage of it. Again, that is politics.

Economics In here it should be obvious that your business plans and sales strategy affects developer experience. Freemium is expected for APIs and trial is dead. Also the role of API in product affects: is it add-on, sold as is, promoting other sales, is it public API, private or partner API? Also the general business drivers such as “time to market span” have crucial role in API product DX.

Marketing and communication There’s a reason why B2D aka Business to Developer marketing concept has born. There was and is need for it. Communicating with and marketing to developers is different compared to B2C. The roles in B2D are different. It’s totally a different ball game.

If B2C is ice hockey, then B2D is football. They share some elements, but have different rules.

Then there is the community aspect. Great APIs have enthusiastic community around it. They promote the product, build additional helping tools for developers, use it in value adding solutions and also bring in the money with paid plans.

Social sciences To get your message through and understand for example developer work flows and flow states, you need to have some understanding of psychology and social sciences. Developers hardly ever work in a barrel, they are part of teams and team dynamics is not explained with engineering.

Understanding the history of developer culture from early hackers gives you perspective and views to the values among the community. Getting familiar with past gives you insights of the future as well. Below image is from one open access article included in my PhD thesis.

Learn what hackers really are and you'll understand the developers a lot better.

Ethnography Of course you need to gather customer needs and feedback to constantly improve DX, but to go to the top class you need more. In the pie chart I used the broader aspect (Ethnography) instead of just customer needs or alike. To be able to really understand the needs of the developer you have to understand the developer community and that informatin is gathered and analyzed with ethnographic methods. Deeper and wider understanding offers better understanding of the customers. With analysis your get windows to the future. To get in the heads of developers, what kind of trends is in toooling and understand them requires more than just listing needs in bullet points. Most simple tool here is to read results of developer community related surveys (Hacker Rank, Stack Overflow reports etc).

Engineering Finally there’s the engineering as well. All the above give direction and foundations for engineering efforts. Technology is not the driver, but customers and their needs. In technology you need to follow trends as well to get a grip what is expected and in what kind of environments your products are used and injected to. For example devops, containers, and rise of javascript have affected the optimum DX of APIs and API driven products.


Some more to read from 100 Days DX