1-800 Contacts is built on the core belief of being better — a belief that can be observed not just in their business model but in how every part of the organization operates, including engineering. So it’s no surprise that back in 2018, when the four DORA metrics were presented in the book Accelerate as a path to become higher performing, 1-800 Contacts was quick to adopt the new measurement model.
Josh Moore, Director of Engineering, explained that the DORA metrics helped their organization recognize which capabilities they needed to build to improve their ability to deliver. However, once those capabilities were built, engineering could no longer use the DORA metrics as the only tool to understand where to focus to continue improving. Moore further described why they needed more than just the DORA metrics: “As much as we didn’t want to compare teams, it happened anyway. But you can’t use these numbers to compare teams to each other when they’re working with different processes or on completely different systems.” They needed additional tools to continue to drive developer experience metrics.
1-800 Contacts looked to supplement the DORA metrics with feedback from developers in 1:1s and surveys about what was holding them back. However, 1:1s provided sporadic information about issues, and it wasn’t clear how widespread issues were. They also weren’t confident they were getting the full story from surveys because of the questions being asked and level of engagement they were seeing.
Today, 1-800 Contacts uses DX to surface the underlying causes of trends they see and get a clear picture of the highest priority areas to invest in. DX provides them with the ability to understand how widespread problems are as well as how painful tools and processes are. It also allows them to provide data back to the teams, so teams can take action on areas of friction that are either unique to their group or are otherwise important for their group to focus on.
It’s intuitive for developers to understand the impact that tools, processes, and team dynamics have on productivity, but it’s not always intuitive for non-technical stakeholders to make this same connection. Because DX measures an organization’s full developer experience and provides both qualitative (“how difficult is this?”) and quantitative (“how long does this take?”) data, engineering can now show the impact different areas of friction have, and in turn make more informed decisions about what needs to be prioritized.
An example of this is technical debt. “Technical debt” is a term that is talked about in many companies, and at 1-800 Contacts it was no different. After rolling out DX, the organization was able to see the real impact of technical debt: they could see how many teams were being delayed by technical debt, as well as how painful technical debt was across the organization. Moore added, “Now that product managers and directors have visibility into these areas, they’ve started asking questions like, ‘what are we doing about this?’ and ‘how can we help respond to that?’ That visibility we absolutely did not have before.”
Moore emphasized how DX has provided a channel for developers to voice the pain points they’re experiencing in a way that non-technical stakeholders understand. He said, “One of the most powerful things about DX is that it puts data behind areas of the developer experience that engineers or managers might know hurt our ability to ship, but that directors, PMs, or executives aren’t fully aware of. And it’s not just maintenance or bugs, but we can show ‘here’s the tooling, here’s the experience that we’re having that is preventing us from delivering in that higher vein.’”
DX provides results back to teams transparently, allowing everyone to immediately see what areas are causing the most frustration or delays, as well as how each area of their developer experience compares to industry benchmarks. That information has fueled conversations within retrospectives at 1-800 Contacts that lead to action. “We’ve seen significant gains from teams being able to see how they’re improving and that there are opportunities to take on problems they thought were untouchable in the past, like technical debt, CI/CD, and our codebase experience,” Moore adds. “We also have teams that come together regularly to share what they’re doing to solve different problems, and how those efforts are working.”