DevEx talk: measure & adapt in software development

I had an absolute blast hosting a talk on Developer Experience [DevEx] with the brilliant minds: Ben Darfler , Director of Engineering at honeycomb.io , and Jon Kern , Co-author of the Agile Manifesto from Adaptavist . Here are my thoughts from the webinar.

Want to catch the essence of the discussion?

Watch the 2.5-minute recap video!

Insights from the DevEx Talk

Here are the key takeaways from our conversation during the webinar. I hope you enjoy them!

DevEx: measure and adapt differently while developing software

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

Data sparks conversations that wouldn’t happen otherwise

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

Those on the ground experience and grasp pains & priorities best

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

Deep work and collaboration are superpowers

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?

When things are complex and unknowable, just take a step

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

Insights from Heads of Engineering

Head of Engineering - Development Services at Ocado Technology:

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.

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?

Our tools 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

Director of SW Engineering at Emplify:

What is in your opinion the optimal ratio between roadmap (features to end-client) vs maintenance vs DevEx?

Watch the webinar recording to get the answer!

Questions and perspectives on DevEx?

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.

Here are the responses and what we've learned: Beyond the Code: How Senior Tech Pros View Developer Experience and Delivery Challenges.

For more DevEx tips, check out these talks:

Beyond DevEx Metrics: How to Define and Achieve High-Impact Goals? with Chas Mastin, Sr. Engineering Manager at Google - save your spot!

How to Turn Developer Experience [DevEx] Insights into Actions?, featuring Benjamin Kitt, Sr. Engineering Manager at Lob