Why Improve Developer Experience?

Pouring all your attention into the product alone never holds up over time. A sustainable business also takes care of the team that builds it.

It sounds obvious, yet many companies still ignore their development teams and let them burn out. We see it in organizations around us, and we do not want to stand by while people and the products they build suffer. That is why we created a new approach to help them.

The approach is built on improving Developer Experience. That is also why we started DX Heroes.

Developer Experience (DX) is like User Experience (UX), but seen from the other side of the product. The users here are developers. Their experience comes from good collaboration, the right tools, a pleasant environment, and a product they enjoy building.

Anyone who has spent time in IT, or built a product, knows that sooner or later they will run into a pile of issues to solve with their team.

The development process is not always set up well, and that puts the whole effort at risk. We often see demotivated team members, high turnover, more bugs, and delivery times that grow as the product moves into the later stages of its life.

We know it is hard to get everything right from day one. Often the starting conditions do not even allow for a healthy developer environment. Maybe the team worked under a tight budget or a strict deadline. That can be necessary at the start, but as the product grows, you cannot leave it that way. A common mistake is to keep overloading the team with unrealistic deadlines and high management expectations. The team can also underperform for the opposite reason: poor tooling, bad architectural decisions, missing DevOps, or no basic rules for how the team communicates.

This is a hard problem, and it deserves respect and humility. That is why we help development teams in several stages.

Before we can fix anything, we have to understand what we are dealing with. In this phase, our DX Gurus join the development team and help build the product alongside them. It is the best way to observe how the team really works.

The DX Gurus focus on the problems the team worries about, which usually fall into two groups.

The first group is the hard problems, often tied to badly chosen tools or missing procedures that drag down product quality. The team might have no Continuous Integration, no Pull Request process, or a misconfigured test environment that costs more than it saves.

The second group is the "soft" problems, which come from the simple fact that team members are people. They have feelings, emotions, and expectations. Ignore that side and you get demotivation, poor communication, or a missing sense of purpose.

Screening usually takes about three weeks to a month. We learned that you need to live through at least two sprints inside an agile team to spot the major issues.

Next, the DX Gurus write up everything they found. They suggest how to tackle each issue inside the team and how to introduce good DX practices.

When they design the solution, they work from the criteria the team's management set before screening began. The criteria might be cutting the product's error rate or speeding up delivery. They depend on the product and on what the team needs. They have to be realistic, or the change will not stick.

Here the DX Gurus check every proposed solution with team management, and where it helps, with the team itself. Validation keeps an eye on the agreed criteria, but the real goal is a team that works well and feels good about it.

Explaining the proposed solutions deserves extra care. These are often changes that nobody greets with applause, so each one needs a clear justification grounded in the team's actual work and needs.

We always tailor the solution to the specific product team and the organization around it. Adopting general principles without adjusting them first rarely pays off.

Here is an example we see go wrong often: dropping agile development onto an existing team without respecting their needs. The idea that agile rituals and instruments, run like a checklist, will magically start working is simply wrong. Usually it just annoys the team and gives them almost nothing in return.

In the fourth stage, the DX Gurus start introducing the practices in the team. The key point is that they do it while working with the team on the real product. That way they can explain each rule on the spot and show its correct use and meaning, which builds consensus around the change. This leads not just to implementation, but to real adoption.

An important rule for how DX Heroes works: once the mission is done, the team should no longer need us.

When the DX Gurus leave, the team knows all the new and improved practices and can keep going on its own.

We want to give everyone a place to share their experience and the issues they face inside teams. That is why we are starting a community of people who want to improve Developer Experience in their organizations.

The first thing we are launching is the DX Knowledge Base, a place focused on the practices that help teams work better and improve their Developer Experience.

Every Knowledge Base article is published as open source and free to use, so anyone who wants to contribute or refine a new aspect of DX is welcome to join here.

We are only getting started. If you want more information or want to stay in touch, take a look at our site:

And what can you expect from us next? We know how much the right tools improve life for developers and the whole team. That is why we started building a tool called DX Scanner. It lets you "measure" Developer Experience straight from your source code and recommends practices to adopt so you can improve how you build your product.