July 08, 2024
For the last few years, everyone has been talking about capital D, capital E: “Developer Experience.”
While there has been a lot of discussion about developer experience as a concept and as a product — most often in the form of qualitative experience surveys — it’s not exactly a new idea.
Engineering leaders always ask engineers in one-on-one meetings what could be better about their work environment and what is blocking them from doing better work. They work to identify issues that lead to bottlenecks or lost productivity, and strive to address those challenges. Over time, larger companies took a step forward by using surveys to collect and aggregate that data, and they labeled it as the “Developer Experience”.
What has been missing to this point, however, is the step connecting that experience to business objectives — data that contextualizes it for business leaders to understand how engineer experience leads to delivering on the things they care about, better. Due to this, developer experience has historically been neglected by business leaders, because they don’t fully understand the way the work is completed and they lack context on how improving developer experience drives business value.
Now, there is an opportunity rising as C-suite executives come to grips with the rising costs of acquiring employees and talent shortfalls in critical areas — retaining engineers is more important than ever, and developer experience is vital for employee retention. Engineering leaders are in a great position to make the case for prioritizing developer experience by using data that’s easy to understand to business partners — drawing clear lines between experience, productivity, and business value. The result should propel developer experience to become the business priority it deserves to be.
What actually is developer experience?
When we talk about developer experience, we’re not just talking about asking engineers “what’s on your mind?”
We’re also talking about a multitude of factors that can impact how successfully an engineer can hands-on-keyboard code, test and deliver that code — both safely and quickly. Their success is contingent not just on those tools that help them do that, but also their access to sufficient support, ability to effectively collaborate, and clarity on the objectives they’re building towards. Poor communication, incomplete toolsets, and a lack of clear direction from leadership can all prevent an engineer from doing their best work, and when kept unchecked, can leave them frustrated or ready to leave.
Let’s break it down into some broad themes:
- Processes and Culture: The processes and cultural norms in an engineering organization can greatly impact an individual contributor’s (IC’s) experience. Lack of proper documentation and rigid or bottlenecked processes can frustrate and slow down engineers. Take code review processes, for example, where even the fastest coders are slowed down by inefficient reviews. When voices aren’t heard, decisions take too long, or collaboration is lacking, the overall experience suffers.
- Tools and Environment: This encompasses the hands-on aspects that affect daily coding. Is the environment slow or unreliable? Does it take multiple VPNs, a jump across a rainbow, and crossing fingers to get code running? Perhaps the testing infrastructure is flaky, causing engineers to chase testing ghosts all day. Or maybe technical debt is so overwhelming that it hinders the ability to write quality code. These factors can severely impact productivity and satisfaction.
- Support and Direction: This aspect is more squishy and covers whether engineers have clear direction and adequate support from their leads, teams, or managers. Do they have the resources and encouragement needed to grow their careers and build themselves up? Are there proper incentives to maintain a happy, productive, and successful team? These factors are crucial for fostering satisfaction and well-being that keep engineers motivated and doing their best work.
When dissecting these concepts, it’s easy to reach the conclusion that high-performing teams require a genuine investment in their processes, tools, and support systems to be able to excel. Without that investment, you might end up with teams struggling to execute, lack of clear direction on what to build or prioritize, and a codebase bowl of spaghetti with nightmarishly long PRs.
How do you prioritize developer experience?
So you might be saying to yourself, “OK, duh, obviously we should be doing that.” Then why is it so hard to prioritize these improvements when they’re so critical to engineering’s success?
The answer is likely that it has historically been hard to determine which investments will actually move the needle and provide value, what’s just good old-fashioned dogmatism, and what’s merely a “nice-to-have” shiny addition. Then when you have an idea, how do you stack that up against other priorities that the company needs, and convincingly articulate to business partners that it’s worth pausing an important project to instead spend a week upgrading this linter so it gets engineers to stop arguing and go faster?
Qual Needs Quant and Quant Needs Qual
The good news is there are solutions to overcome these challenges. Running developer surveys to gain qualitative direction and combining them with quantitative data can help you prioritize and articulate its business value.
Just asking for qualitative feedback alone isn’t enough — you need to translate feelings into something more tangible. Similarly, quantitative data needs context to give it life. By combining these, you can get a consistent pulse on engineers’ feelings and tie those insights into a compelling story. This can elevate the priority for executive buy-in to rebalance resources and priorities. So, what do I mean by this exactly?
For example, let’s say you run a qualitative developer experience survey and find many engineers are upset about their testing tools. That’s a start, but it’s not enough. Feedback is great to directionally tell you where the problems are, but isn’t sufficient on its own to say where an investment could have a significant impact, confirm if the investment was effective or help craft a compelling enough narrative to make it a priority.
The next step has to be to look at related quantitative metrics. You might find that defect rates are acceptable, but the frequency of deployments could be higher. So now you know that improving these tests may not solve an issue with quality, but it could potentially boost both the perception and the actual speed of development.
Investing a week or two in refining the testing infrastructure, with an anticipated increase in development speed, is a move you can justify. More importantly, you can track and demonstrate the outcome, presenting it as, “We now deliver 15% faster due to these improvements.” This approach is far more effective than merely stating, “We think we deliver faster,” or worse, realizing that the investment didn’t actually speed things up, even though it might have made the team feel slightly better.
This approach tells a clear story and builds trust, especially with non-technical partners. Of course, testing is a simple example, but you can also imagine those extremely esoteric cases where the lines are harder to draw — quantitative data will simply make a stronger case for improvements to be prioritized.
Improving developer experience isn’t just about gathering survey feedback — it’s about really digging into the issues that matter, figuring out solutions, and pushing for the necessary shifts in budget and resources. It’s essential to pair the directional feedback from those surveys with hard data on SDLC bottlenecks, resource allocations, and delivery metrics. This combination arms you with a full toolkit to not just identify problems but to effectively tackle them and drive real change.
Continuously drawing that line between developer experience and business value
I’m a believer that the key to truly creating a good developer experience is by getting it prioritized, and you do that by continuously tying it to business value. Business leaders will invest in what they understand; showing the impact of developer experience on hiring, retention, and productivity will open the eyes of any executive to the value of a healthy engineering team.
With engineering being one of the largest cost centers in every tech company, business executives should have a vested interest in making that cost center as efficient as possible. And as engineering increases its influence on business strategy — 90% of respondents to Jellyfish’s 2024 State of Engineering Management Report said their engineering team helps inform business strategy — you can quickly imagine a world where developer experience is a standard business OKR, and executives understand the importance it has to their business.
New standards are developing in the world of engineering efficiency, and developer experience is a part of that. Developer experience is evolving from just asking your engineers to a more comprehensive and routine health check on your organization. Today, investing in automated, data-driven solutions and integrating both qualitative and quantitative measurements is becoming essential for businesses. The speed and effectiveness of an engineering organization can dramatically influence a company’s success; it’s too critical to leave to chance or guesswork.
