Ben Darfler, Director of Engineering, Honeycomb.io, and Jon Kern, the co-author of Agile Manifesto from the Adaptavist Group will be discussing Developer Experience [DevEx] drivers, metrics, and practices in this area, as my guests on the upcoming webinar.
Here’s the link to webinar recording, and below are key highlights from the webinar and some of the topics we planned to cover.
Here are the key takeaways from our conversation on Developer Experience during the webinar.
While developing software, you likely face growing complexity—both within your team and beyond. Internally, everything is interconnected. Externally, you must continuously adapt to meet ever-evolving and demanding user needs.
DevEx is about sensing and responding differently to complexity. It places developers and their experiences at the center, fostering curiosity and encouraging deliberate action. DevEx takes a holistic view of every aspect of the software development process. By providing data and response paths directly from and to teams, it creates space for innovative thinking and action.
The key question is always: How can we find ways to grow as a company, as a team, and as individuals to deliver value? The DevEx helps bring to light things you might want to consider being curious about. It’s about bringing more conversations, more curiosity, and the potential; we just have to make sure people don't get locked into one narrow focus. – Jon
Direction and delivery both have to evolve together. If your car is broken down and can't move, you're not going to get there. If you're driving in the wrong direction, you're still not going to get there. – Ben
At the core of DevEx is having conversations about what truly matters. It’s easy to ignore your guesses and intuitions when you’re unsure; it’s hard to know the unknown. While data helps, it doesn’t tell the whole story - it needs context, direction, and experience. Moving beyond metrics and fostering deliberate conversations is the real game here.
Passive data from the delivery process, such as DORA or FLOW metrics, has been around for a while. Developer Portals measure developer interactions with tools and resources. Developer Experience surveys add a new layer by asking developers about key blockers in their daily experiences, providing a holistic view that uncovers roadblocks, opportunities, and actions that passive data might miss.
For me, the key blocker to improvement is when teams do not take a step back and reflect. It’s important to make space and time and prioritize the conversations. There's always another fire to fight, always too much work to get done. It can be easy to just go heads down and focus on the next thing and the next. – Ben
The survey would get at something quick, things that you could focus on, and then we'd be able to layer on top of that, making sure the direction, value, and the other things are aligned. The survey might help spark the growth of a company and a team, enabling harder conversations because we all want to succeed, hopefully. We're all fighting for the best outcome for our users. – Jon
For DORA, or other passive data metrics, I'm just looking for trends and outliers on a monthly cadence. To get curious and start asking some questions. It's never the smoking gun. Oftentimes, teams are already feeling something, but it can be easy to ignore your hunches if you're not quite sure. But if you've got a hunch and some data, now you can have a conversation. – Ben
The true key is putting people first. It’s no longer just about automating & unifying key DevOps processes and tools at scale—that's already mastered by the best teams.
Now, it’s about unlocking human potential. Does the process bring signals directly from developers, revealing insights that automated proxies, tool usage stats, or data like DORA metrics might miss? Engineers, through DevEx surveys, often provide the most accurate insights on complex issues, uncovering what passive data might overlook.
Does distributing signals and response options directly to teams foster conversations and actions at every level? Are we creating an environment where observability, transparency, and actions happen seamlessly across the organization? That’s what DevEx is all about.
It's really up to the teams to feel the pain and be empowered to make the changes. They're going to know what's most impactful for them. If it's more of a systemic problem, they can bring that up to us leaders. But we're not going to understand the relative priorities as well as the people who are experiencing it day to day on the ground. – Ben
What I tend to see in a lot of conversations is people going really deep and narrow on some specific metric and trying to optimize that, and that really is not the right approach to move forward. – Ben
Time is our greatest constraint, and collaboration is our key strength. Together, they form the core of the DevEx formula. Are we making time for what truly matters? Are we collaborating deliberately?
Deep work, based on the Maker Time concept, means at least 2 hours of uninterrupted focus, enabling developers to enter a flow state. Time is also key for reflection, improvement, and holding onto uncomfortable, fuzzy, complex ideas for as long as needed—whether individually or as a team.
Unlocking more time for deep work improves both Developer Experience and the delivery process. Without time to fix issues, even those affecting their own work, improvements won’t happen—despite developers' love for refinement, as fixing things is what makes them happy.
Deep work and collaboration can be measured with both DevEx surveys and data from calendars, chats and emails.
If you're scattered with meetings throughout the day, and you've got 30-minute blocks of work here and there, you're really not going to find that satisfaction as a developer. You’re not going to be able to make the impact you're looking for, or the impact the company is expecting you to make. – Ben
Deep work helps us get to the essence of what we need to do and how we might do it. I would question the ability to be effective at being innovative and creative without it. But it doesn't work if you're constantly bombarded with crap, stupid meetings, and wasteful, non-value-added stuff. – Jon
DevEx is about sensing and responding differently in a complex environment. The focus is now on people—their experiences, conversations, insights and actions—prioritized over the automation of processes and tools already in place. It's an opportunity to create space in a complex system for innovative thinking and action, both small and big. There are many levels to master, but the key is to start.
When things are complex, just take a step, move in the first direction. If it was a bad way to go, you'll know. Good thing we only did it for a day. Then try another way and get feedback. It doesn’t have to be a big leap over a tall building. – Jon
Start small, make a move, start with something imperfect, improve from there, and then see where that goes. – Ben
Surveys are a nice start, but over time (especially nowadays), survey strain gets in the way. It is hard to beat the quality of insights gained from doing an interview or sitting together with teams for a while – Head of Engineering – Development Services at Ocado Technology
Yes, survey fatigue is real, I totally agree. But surveys are a great starting point and useful for gathering insights at scale from 10 to ... teams. When results, benchmarks, and developer comments are automatically shared with teams, it can spark curiosity and drive discussions around improvements, as Ben mentioned. I also agree that interviews are the best way to dive deeper, but it’s challenging to do them at scale. Surveys can help you target your interviews by highlighting which teams and topics to focus on.
What's your strategy for deciding when a DX-related signal is worth investigating? – Head of Engineering – Development Services at Ocado Technology
Our tools (DevEx surveys, and Work Smart AI) visualize signals through 4 perspectives: benchmarks, trends, signal scale, and a broader view that combines specific data with overall insights.
Both external and internal benchmarks are useful (the 75th percentiles for external, with a broader range for internal). We focus on trends, tracking major changes or long-term negative shifts. Scale matters—does the signal show up in just one team or across many? We also visualize multiple data points, such as DX signals (like test quality) alongside perceived productivity in surveys—when both are low, the signal may be more significant. Our tools are built to scale, helping many users quickly understand signals, spark curiosity, start discussions, and take action when needed. For analysts, perspectives are more sophisticated, and here’s a one example https://www.nicolasbrown.co.uk/work
Unclear priorities and some mid or long term vision are important for DevEx – Director of SW Engineering at Emplify
What is in your opinion the optimal ratio between roadmap (features to end-client) vs maintenance vs DevEx? – Director of SW Engineering at Emplify
Watch the webinar recording to get the answer!
During the webinar, we asked Heads of Engineering five quick questions about DevEx. We’ve noticed that this perspective is often missing in global discussions around DevEx. While reports from Github, Harness, Atlassian, LeadDev, and Stack Overflow provide valuable insights from developers and sometimes managers, they rarely include the views of Heads of Engineering.
We are still gathering responses, so if you’d like to participate, here’s the link to vote. We’ll publish the results soon!
Developers often face various types of friction throughout their workflow, especially when using multiple tools. Meetings, requests, and other disruptions force developers to piece together context from fragmented, outdated sources, hindering productivity and code quality.
So, what makes a good Developer Experience for GitHub for example?
At GitHub a good DevEx means developers have all the information they need and can easily switch between focused work and collaboration, completing tasks with minimal delays. Low friction is key.
It includes: Seamless collaboration | Speed | Short feedback loops | High degrees of automation and integration | Low levels of friction | Transparent, well-documented processes
The list of DevEx drivers we’ve created at Network Perspective is more specific and covers developer experience in the small steps of the process of delivery: when developers do their own work, and collaborate to specify, create, validate, and deploy the code. Here they are:
Direction | Specification | Task batching | Priorities | Timelines | Codebase | Documentation | Coding | Compliance | Tech debt | Test quality | Test efficiency | Code review | Build pipeline | Release ease | Incident handling | Live debugging | Monitoring | Telemetry | User feedback | On-call practice | Experimenting | Learning | Deep work | Meetings | Context switching | Intra-team collaboration | Cross-team collaboration | Empowerment
We will be talking about what among DevEx drivers already mentioned are the key enablers that allow developers to focus on what matters most: building great software?
Traditionally, software development teams have focused on measuring developers' productivity. DevOps Research and Assessment (DORA) team has identified key metrics that have become industry standards for assessing team performance:
Deployment Frequency | Lead Time for Changes | Change Failure Rate | Time to Restore Service.
Many engineering managers are excited about measuring Developer Experience (DevEx) through surveys. These surveys help identify daily challenges developers face in terms of flow state, cognitive load, and feedback loops. They ask developers to rate the level of their agreement with the questions like:
In this part we will be talking about: how proxies for delivery outputs are measured now? What is working, what’s not? What is simple to implement? Any new directions (after DORA) that emerge?
But we’ll also talk about measuring Developer Experience with surveys: what are the pros, what can be achieved this way, and what are the limitations.
DevEx survey questions also ask about deep work, and collaboration. Deep work comes from the Maker Time concept and means min. 2 hours without interruptions. Some statistics reveal that even 90% of developers spend less than 2 hours per day on pure coding.
How about collaboration? Developers in enterprise settings work with an average of 21 other engineers on projects—and want collaboration to be a top metric in performance reviews.
At GitHub they see collaboration as a key factor that boosts the entire DevEx. Their formula focuses on creating a collaborative environment where developers can be: productive (quickly make changes to the codebase), impactful (move from idea to production with ease), and satisfied (enjoy their environment, workflows, and tools).
Not enough time per coding is what I frequently hear from dev teams. Lack of time for deep, uninterrupted work and insufficient deliberate cross-team collaboration are major issues. These factors not only score low in DevEx surveys but also act as blockers for improvements in other areas of Developer Experience. Simply put, developers don't have the capacity to make further improvements, even in areas affecting their own experiences.
In this part, we will be talking about the role of deep work and collaboration in the Developer Experience, and measuring these aspects in ways other than surveys.
