Should we focus on developer experience or developer productivity?

Featured image

When talking about developer experience, there are a couple of other names thrown into the conversation that all kind-of mean the same, but IMHO have a slightly different touch / focus and can be perceived quite differently.

Some may call it developer productivity or developer effectiveness. I, however, prefer the term developer experience. And here is why:

Naming matters

While all those terms may have the same intention and are also highly correlated, there can be small differences in the perception. From my perspective, developer experience is focussing more on the humans and that they have a good time and just a stellar experience at work, regarding all aspects of software development.

Developer productivity or effectiveness on the other side focus more on the outcome in terms of speed, quality or other KPIs.

While experience would probably be measured by asking and listening to developers, productivity or effectiveness tend to be measure by hard KPIs. This can quickly become toxic as the organisation might lose focus on the humans and gets too attached to optimising metrics.

Business wants developer effectiveness

From a business perspective, it is pretty clear, that we want developers to be effective. Basically, it is interesting how the ratio between value generated by the development team and the number of team members (or the sum of their salaries) is. This might be a KPI that could be measured. But should we?

The answer is “No!” — Assuming, that motivated employees will do the best work possible, this KPI completely takes the human out of the equation and hides the real problem. If developers are not effective, there is a good reason for that, which often lies in an inferior experience. An inferior experience can have many and multiple root causes that need to be addressed instead of putting pressure through KPIs. Having those KPIs as a goal quickly kills employee motivation and if their experience is a cause for frustration too, this situation will quickly get worse.

Therefore, if you believe that your people want to do excellent work, you should as well assume, that superior developer productivity directly follows from an excellent developer experience.

In fact, recent studies have shown, that happy employees are around 12% more productive1 and there is no reason to believe that this is any different for developers.2

Furthermore, if people enjoy their work and feel that they are effective and spend their time meaningful, they are much more likely to stay with the company longer. Consequently, they would attain more profound understanding of the product, the system, and the organisation.

But does it even matter in day-to-day work?

How does developer experience work differ from developer productivity work? — Interestingly, not really much.

Many tasks that a team would do to improve the experience would also be the tasks they would do to improve productivity and effectiveness. Examples are

  • reducing build times,
  • helping teams to shorten their feedback loops,
  • enabling teams to understand the behaviour of their systems in production, or
  • simplifying the local toolchain setup.

All those are examples for tasks such teams would focus on, no matter, how you call them. However, the difference lies more in how they seek feedback for their work and prioritise work. It is more about asking people and addressing their biggest pain points rather than optimising some KPI.

Summary

While terms like developer productivity, developer effectiveness and developer experience are about similar topics and long-term outcomes, I find developer experience to be the more human-centric term and therefore prefer it over the others.

What do you call it in your company? Why so? Share your thoughts in the comments or via LinkedIn or Twitter.


  1.  Does Employee Happiness have an Impact on Productivity?  ↩︎

  2. Of course, it is important to note, that many factors influence the experience of employees, outside the scope of a developer experience team. ↩︎


This blog post is based on my own opinion and experience. It is inspired by what worked for me and my team in our context. I recognize, that your context is different.
The “Just Sharing” Principle