Three ways DevEx initiatives fail before they even get started
There are three consistent mistakes that undermine DevEx efforts, regardless of company size or technical stack.
This post was originally published on my Linkedin.
Organizations increasingly focus on developer productivity as a key competitive advantage, yet many engineering leaders are floundering in pools of data, unsure of what to actually do with it. I’ve worked with hundreds of teams and thousands of engineering leaders, and here are three consistent mistakes I’ve seen that undermine DevEx efforts, regardless of company size or technical stack.
The “unobtrusive measurement” trap
The most damaging mistake is attempting to measure productivity “unobtrusively” without developer involvement. Leaders often pursue this approach with good intentions, believing they’re reducing disruption or avoiding potential resistance.
This approach inevitably backfires. Developers quickly discover they’re being measured without consultation, which erodes trust—a foundation that takes significant time to rebuild. More fundamentally, there’s no scenario where productivity metrics improve without developer participation. Whether through adopting platform engineering tools or driving team-level improvements, developers must be active participants in the process.
Remember: developers should be consulted about productivity, not informed about it. Involving them from the beginning creates investment in the outcome and dramatically increases the likelihood of success. No one wants to feel monitored without context or consent.
Metrics without product thinking
The second critical failure is not treating metrics as a product that serves specific users with specific needs. Organizations frequently implement metrics without conducting user research to understand how engineering managers, executives, or individual contributors will actually use them.
This leads to metrics that don’t solve real problems or address actual pain points. Without thoughtful implementation, many teams look at these dashboards once and never return. For metrics to drive change, they must be designed with clear use cases in mind: Who will use this information? What decisions will they make with it? How frequently will they need updates?
The “build it and they will come” fallacy
Perhaps the most pervasive mistake is expecting that simply making metrics available will naturally lead to improvement. I call this the “spray and pray” approach – point the firehose of metrics at your teams and hope that good intentions and intrinsic motivation will take care of the rest.
Continuous improvement, data literacy, and productivity optimization are skills that require organization-wide support and incentives. Without structured reinforcement, delivery pressure will always trump improvement efforts. Leaders must create systems that reward continuous enhancement alongside feature delivery.
Without deliberate attention to these factors, productivity initiatives become dashboard exercises rather than transformation catalysts. Engineering teams need clear guidance on interpreting metrics, authority to make improvements, and recognition when those improvements manifest.
By avoiding these three pitfalls—involving developers from the start, designing metrics with user needs in mind, and creating systems that reward continuous improvement—organizations can build devex initiatives that deliver lasting value rather than temporary enthusiasm followed by abandoned dashboards.