Companies might fall into the trap to believe that developer experience is a nice-to-have luxury rather than a necessity. However, this is not the case. As I argued in my last article, high developer productivity results from a great developer experience and thus, the companies’ success ultimately relies on this.
In this article, I will further elaborate what all this “developer experience” talk is about and why it matters for your business for various reasons.
What developer experience is about
Thinking about developer experience is as simple or as complicated as thinking about the question of how to make the normal day of a developer better. This opens up a broad field of potential topics that fall into the developer experience realm.
Developers would probably enjoy their work, if they knew what to work on, why their goals matter and how they can achieve them. Furthermore, it would be beneficial if they had not to fight with tools or processes to get their job done. Especially, more experienced teams know (or think they know) the appropriate approach for a problem. Thus, it is important, that the team can pursue it, get feedback on it and then can iterate and incrementally improve the solution, as the team learns.
Less experienced teams, on the other hand, might benefit from more guidance and consistency and from not needing to reinvent the wheel. Good developer experience needs to cater for both teams, and therefore balance team autonomy with consistency.
Naturally, experience varies between teams, between topics and also within teams. The fact that one team has profound knowledge in frontend testing does not imply, that this team also feels safe to decide about deployment approaches.
To sum it up, a team aiming to improve developer experience should provide solutions (i.e. tools, services or documentation) to reduce cognitive load of the teams without interfering with their need for autonomy.
Bad Developer Experience
Bad developer experience can come from many things, including:
- Forcing developers to use certain technologies, follow certain processes or care about certain aspects of software development, that they do not find important.
- Using old or dissatisfying technologies or outdated/slow hard- or software.
- Lack of autonomy, but also
- Lack of guidance and consistency, and
- Not having psychological safety.
Autonomy vs. Consistency
In larger companies, there are many teams and even more people. Many of those have different opinions about almost every topic. Which framework to use for frontend testing, how and if to write documentation, how and when to deploy, coding styles or so called best practices.
The list of topics one could argue about is endless, and finding a consistent approach across all teams becomes harder as companies, and therefore the number of stakeholders, grow. Furthermore, changing the strategy often also becomes more difficult as the codebase grows.
Companies therefore need to decide where to place themselves on the spectrum from total autonomy to total consistency. The first extrem enables teams to quickly evolve the artefacts they own and try out new things without aligning with everybody in the company. The latter extreme, on the other hand, makes it easier for others to switch teams and to contribute to areas owned by others. However, it also involves more alignment and rigid structures that make it impossible for teams to do what is right in their context with high autonomy.
Finding the correct balance is certainly not an easy task. The best attempt, I have seen so far, is to:
- empower teams to make decisions,
- make teams capable to make decisions,
- enable teams to work largely independent of other teams,
but also to:
- provide guidance so that teams do not have to make all decisions, and
- to make it easy to default to a good (enough) approach.
In short: Allow teams to reinvent the wheel, but do not require them to do so!
A developer experience team can provide the needed guidance and recommend approaches that allow other teams to rely on these solutions. This helps with consistency across teams, as long as teams do not have a good reason to derivate from the recommended approach.
However, it is crucial, that developer experience teams do not enforce certain approaches as force will ultimately lead to frustration, resistance and bad developer experience for some, if not most developers.
Psychological safety
Psychological safety is crucial for people to show their full self without fear. This allows people to ask questions, that might feel stupid to them, to try out new things (and learn) and to raise concerns that nobody else does.
Being allowed to make mistakes, but at the same time being guarded against making dangerous mistakes, is important for people to feel safe to experiment and tryout new things.
While this is of course a cultural topic and not only essential for developers, it also largely affects developer experience. Developer experience can be improved by providing mechanisms to avoid bad mistakes. Tools like automated deployment pipelines, automated testing and release toggles can help to avoid or mitigate severe incidents. Moreover, the practice of blameless postmortems can make people feel safe.
Psychological safety combined with the freedom to take decisions and make mistakes will have a highly positive impact on developer experience and employee satisfaction overall.
Why it matters
The positive effects of a great developer experience are manifold.
Foremost, it will increase the satisfaction of developers. Developers will enjoy their job more and have more fun at work. This has at least three other positive effects:
- Happy employees are usually more productive. 1
- Happy employees tend to stay longer with the company, which again has a positive impact on the productivity.
- Great and motivated people will attract more great people. Hiring will become easier for you, too.
If happy employees were not enough reason to care about good developer experience, they come hand in hand with higher productivity, too. Furthermore, as stated in my last article, good developer experience and high developer productivity go hand in hand, as many efforts that improve the experience of developers also have a massive impact on their productivity.
For example is it not only more fun to work in an environment with fast build pipelines, but it also enables faster deliveries.
Summary
There are many great reasons to care about the experience of your developers (and employees in general). As if happiness of your employees would not be reason enough to care about this topic, productivity is directly linked to it.
Thus, an investment in developer experience is an investment in the future profitability of your business, too.
What is your company doing to ensure a great developer experience? Share your thoughts here in the comments or via LinkedIn or Twitter.
