8 ways to retain top developer talent

Human-centric work is a growing movement that focuses on the needs of people, reaping business rewards in the process. As recent Gartner research shows, human-centric work practices leads to better employee performance, with workers 3.8 times more likely to be considered high performing in these environments. 

As some of your most valuable employees, software developers should be considered specifically in how to best apply these insights. In the software world, “developer experience” is a key aspect to work satisfaction — one that is not well understood by non-developers.

By bringing together the insights of human-centric work and developer experience, IT leaders can create a work culture that builds and retains top performing developers. Here are seven ways to cultivate a developer-centric environment that will pay dividends.

1. Understand what developer experience is

The leader who understands what developer experience is and gets why it’s important to coders is ahead of the game.

At the most basic level, developer experience (DX) is about how it feels to use a tool or system when building software. It stretches from the very specific, like the difference in how languages handle functional programming, to the general, like the difference in how it “feels” to use different cloud platforms. DX doesn’t stop there, encompassing the culture and attitude of what it means to live the developer lifestyle. In this most broad sense, DX is a major feature of how developers, especially experienced ones, feel when working in an organization.

At the heart of the human-centric philosophy is the idea of autonomous accountability, which means giving people goals and holding them accountable for performance while giving them as much control over how they accomplish things as possible. The idea is that people know what is working and what isn’t, and they are best able to course correct in fast, iterable fashion. And it very much aligns with a valued developer experience.

2. Understand why DX matters

Developers have a self-referential relationship with developer experience: They often build the tools they use, appreciating the way things work and the creative engineering that goes into building the things they use. 

Artistry and appreciation drive the software community forward. Ever since the early days of shared mainframes developers have joined together to create and collaborate on projects that stimulate their minds. The interest and uptake of developers in tech projects has become a key element in determining what projects are funded and find their way into common usage. DX is what distinguishes these projects among developers, and it acts as a kind of indicator of evolutionary suitability.

Dan Moore, head of developer relations at FusionAuth, draws a useful distinction about DX, saying, “Developer experience can be split into internal and external developer experience. The former is about enabling internal teams to build in a more coherent, secure, faster way by providing building blocks and guardrails along with self-service tooling. The latter is for increasing sales and building a sticky platform for developers outside your organization.”

To ensure those results, IT leaders must continuously ask what it is like to be a developer at their organization and find ways to make that experience better.

3. From DevOps to ‘DevEx’ — and back again

The expansion of DevOps has empowered developers to be involved in the full product lifecycle and influence that lifecycle in a holistic fashion. If you haven’t already embraced DevOps, that is a good first move in the direction of developer-centric practices. 

DX takes DevOps to the next level. As Guillermo Rauch, CEO and founder of Vercel told me, “Organizations will move from DevOps to dev experience. Great developer experience leads to better developer productivity and improved developer velocity, directly improving your bottom line. Every organization should be thinking, ‘How do I empower my developers to spend more time on the application and product layer while spending minimal time on the backend and infrastructure layer?’”

Looked at this way, focusing on DX is a way to better enable developers to control how they work: Instead of figuring out what DevOps processes are best and then imposing them on teams, empower the team to devise processes and technology that best suits them. After all, empowered teams involved in processes firsthand can better design and build tools for their tasks in response to changing conditions. 

Put another way, good DevOps is a natural outcome of good DX, and vice versa.

4. Have someone own DX

Including developers and IT staff in discussions around what tools to use — and giving them purchasing influence — provides an invaluable feedback loop about what is and isn’t working. It also ensures developers feel they are being heard, making them more likely to be invested in the project. 

The key to nurturing benevolent cycles between the business and tech staff is finding and empowering the force magnifiers in the organization, those individuals who can help speak for the developer experience and provide a bridge to the business side. A great way to help here is to explicitly put someone, or several someones, in charge of DX. This might be part of someone’s responsibility or the sole focus of a group, depending on the scope of your organization.

Establishing an explicit focus on managing the health of DX and providing a way for those involved with DX to interface with the business will greatly contribute to the overall success of your DX efforts.

5. Don’t push developers to fail their second audience

Developers create software for two audiences: users and developers — that is, those developers who will work on the product. For users, product excellence is critical. But for developers, excellence inside the product is extremely important as well, and that has big implications for the business using the software. In this sense, DX is an indication of code quality, which says everything about the viability of software.

Here, the importance to the business is two-fold. First, systems with good DX are easier to maintain and extend, with software quality a key differentiator between code that can grow and evolve and code that is doomed to degrade and decay. Second, when DX is high, developers — especially senior ones — are more likely to be satisfied with working on the project. Because of this, the importance of code quality shows why project velocity is not a metric to be seen in isolation as it often is. 

As the human experience of working on projects, DX is the most indicative characteristic of a project’s health. How it feels to work in the internals of a project is affected by everything from tooling to meeting tempo, and whether that feels pleasant or unpleasant says everything about how well things are going, how they will proceed, and whether people will want to continue working on it.

6. Provide opportunities to learn, teach, share

Learning, teaching, and sharing are major incentives for developers. And the more accomplished, passionate, and caring the developer, the more they typically matter. The ability to craft DX and help others see its value is essential. By inculcating a culture where everyone is participating in a larger journey that includes sharing, everyone finds a deeper well of inspiration.

Incorporating contribution to open-source projects is a great way to accomplish this.  Many software-oriented businesses include an open-source component for good reason.  It allows developers to express their creations, pulls in contributions from the wider world, and draws friendly attention to what’s being done in the organization.

Every developer’s experience is lifted up when their work feels a part of something greater.

7. Mitigate DX-killing red tape

The business longs for metrics and insights into what’s happening in the dark interior of software creation. But too much intrusion into developer workflow is a real DX killer. Instead, minimize unnecessary meetings and reporting, and keep an eye on what works most efficiently. Even just the sense that leadership is incorporating this factor into their strategizing will help.

The best software developers thrive in an environment where they can focus on what they do best — building software — and spend most of their time on activities that feel valuable.  They have honed and invested in what they are good at, and they want to spend as much time as possible on those tasks.

Reducing friction between teams and areas of ownership is also important. IT leaders are in the position to help break down silos of ownership and exclusivity. 

8. Automate (and de-stress) delivery

Recent research shows that 7 in 10 developers quit projects because of stress over delivery.  A million and one things go into the detailed activity of building software and when it is all bundled up into a single discrete thing that is to be delivered without problems, it’s very stressful. There is a sense of never really doing enough, despite your best efforts. 

The best way to address that is to build reliable automated systems. Continuous integration and delivery, automated testing and the like are becoming standard, must-have parts of dev processes these days, but they are only part of the story. A culture of support is just as necessary. How developers feel treated in their times of difficulty and uncertainty has a huge impact on DX. If successful organizations maintain a two-way street between business and IT, DX is the condition of the road.