How to reach Developer Experience supreme level — Part one

Hi all, glad to be here again! I have seen many companies recently evolve their products through good DX, and I have to confess, it’s amazing! Recently, I spoke with some of my colleagues about their experiences designing products that provide good solutions for both business and technical personas. I gained interesting insight. During those conversations, I noticed that people professed difficulty measuring how great their DX is — that’s why I wrote the Developer Experience Metrics. But beyond measuring DX, people were struggling to identify the maturity levels of these professionals at their jobs. So I decided to write this article and explain my Developer Experience Maturity thesis.

To begin, why is it important to map DX maturity levels?

Understanding a Developer’s Journey

In my experience, many players tried to provide great DX with high-level actions, forgetting about the details throughout the process. For example, some API Management tool creators tried to enable great DX by giving their users a full distribution experience within their developer portals, but they forgot to really seek understanding of the beginning of the journey, the development portion… They didn’t map the entire journey, and instead, they focused on just one frame.

Don’t get me wrong, I know some products focus on a small piece of the user’s tasks for good reason, but when you work with developers you should worry about the entire experience, even when your product’s purpose is to resolve a small piece of it. Because when we talk about designing products for developers, it’s almost a rule: they will use your product with another tool. So, when I set out to identify a general developer journey I plotted the following sequence:

The idea of this article isn’t to describe the development process, but it’s important to provide a short explanation to get us on the same footing:

• Solution Design: In this step, the developer receives the business requirements from the business personas (Product Manager, Product Owner, etc.), and with them, he designs the solution architecture. He can do it with a BPMN diagram, a mindmap, and any other tool that he feels comfortable using during this process.
• Development: The build phase, where the team will develop the proposed solution. Here they can use agile methodologies like Scrum, Kanban, eXtreme Programming, etc.
• Tests: You build it, you run it! This is Google’s mindset for their engineering teams, and I deeply believe in it and apply this to my own teams’ evolution. Basically, every developer should test their release, and not only unit tests but testing the entire client’s (end-user) experience to validate if the release will break another part of the product.
• Release: Let your customer feel your work, the release should be exciting for developers and customers! Here I prefer to use a cascaded release schedule; first, a smaller group of users, just because I want to understand how they will absorb the new experience, and after this validation process, I release to the larger user base.
• Monitoring: You build it, you run it, again! Doesn’t matter if you work with product development or professional services, you should always have a plan to monitor your releases. In every project that I worked on, I recommended my team develop custom dashboards to monitor usage. Usually, we use Metabase as our BI tool. Why Metabase? Because it’s an open-source tool, and we love open-source. ❤
• Client’s insights: A well-done monitoring process gives you insights about which clients you should speak to for future information, and don’t think this is only a UX Designer or Product Manager’s responsibility! Great developers like to speak with their users because this helps them evolve the product even more.

DX Maturity Levels

Now we can and speak about Developers Experience Maturity, and relate it to the general developer’s journey. To measure this I developed a framework with five levels:

Suffering Because of Bad DX

Every developer tool/service company will pass through this phase, even if DX is never important to them. This is because bad DX doesn’t impact only the user’s happiness; it will impact their sales, marketing, employee branding, etc. So these companies will be affected by their bad DX but very few of them will realize the problem’s origin.

Understanding DX

The small group of companies that realize the origin of their problems was DX will start to understand this subject by stumbling upon it. The product manager responsible for the product or feature will be the first warrior in this war. He will google the term, search for cases, references, etc. In my experience, I noticed this process takes at least two months. If you are at this level, I deeply recommend that you read What is DX.

Applying DX For Your Product

After understanding “what is DX” you will start to apply the concepts for your product. First, you’ll probably start to track your developers’ journeys; you’ll map it out, identify their needs, identify their desires, and see how your product will make their life greater.

In moments like these things get even more interesting. You start to realize that modifying your product isn’t enough to provide great DX. So you start to analyze your company, how your marketing team speaks about your product, how your sales team sells your product, how your customer success team helps your clients utilize your product.

Since this is not a matter of developing features, you will start to see that even the words you use in your product communication will be important for good developer experience. I recommend using the User Journey Framework to map your developer’s journey. You can find an example here.

This phase is really exciting, and you will need to be an excellent communicator to engage your internal stakeholders to modify your company because you will probably make changes to your organization structure — areas will be redesigned, people will be hired, a developer community will be created.

Evangelizing DX

Back in the days, I was responsible for creating our internal developer community, I realized that just having a great product for our customers and modifying our company internally was not sufficient to master DX for our products. So I started to look externally, to consider how our company and our team could help more developers, and I created the Kapi Community.

After this, I designed a career development plan for my team that helps them evolve and generate great content for the world development community. Currently, our content is primarily in Portuguese; we realized that Brazilian Developers require quality communities dedicated to career growth and accessible development content in their primary language.

We also strive to find great partners in our mission. Here in Brazil, we have Rocketseat, a company designed by developers for developers, as well as NewSchool, a company that helps children in need better prepare themselves for the world in front of them, a future in STEM. These two companies are some of our developers’ community partners.

And to finish, I wrote this article explaining DX because I saw that many people don’t understand a simple fundamental truth: that developers deserve as great an experience as normal users, and these same people don’t understand how their product could be greater, their companies bigger, all through the simple act of making more developer-friendly tools.

The highest level of developer experience is when you start to be an active part of this battle: generating content, gathering insight, creating communities, basically being part of the process of evangelizing DX all over the world. We already have a job title for it — Developer Relations. This is one of the jobs to watch for the future; every company that respects DX will soon have this person on their team.

I’m really glad to have written this article, and even more, to say to you that this will be a starting point for a series explaining how to reach the highest level of developer experience. The series will explore each of the maturity levels, providing examples, cases, and my track record over the years working to build developer tools. I hope that you enjoyed this content, and if you want to chat about this, please, send me an email.

Bye, and see you soon!