The DX Core 4 Framework

The next iteration of developer metrics

In the mid-20th century, the world of manufacturing was undergoing a transformation that would ripple far beyond factory floors. Visionaries like W. Edwards Deming, an American statistician, introduced groundbreaking ideas in quality control and productivity. Deming’s influence helped Japan recover economically after World War II. Another key figure in the manufacturing quality and efficiency movement was Taiichi Ohno, often regarded as the father of the Toyota Production System (TPS). Ohno, a Japanese industrial engineer, was instrumental in developing what later became known as lean manufacturing, a methodology that revolutionized production processes worldwide. Factories hummed with assembly lines optimized for efficiency, driven by data and systems thinking. Every screw, every widget, every step in the process was measured, analyzed, and refined.

This obsession with productivity didn’t stay confined to manufacturing plants. As computers and software began to shape the post-industrial world, managers in this new frontier looked to manufacturing for guidance. Inspired by works like TPS and Peter Drucker’s The Practice of Management, they sought to apply those same principles to software engineering. Programmers became the new factory workers, and their output, lines of code, was treated like products rolling off an assembly line.

But the translation was far from perfect. Fred Brooks, in his classic 1975 work The Mythical Man-Month, highlighted how managing software wasn’t like managing manufacturing at all. "Adding manpower to a late software project makes it later," he famously warned, capturing the inherent non-linearity of software creation. Still, the allure of measurable productivity was strong. Managers clung to metrics like lines of code, borrowing from Deming’s legacy while misunderstanding the unique challenges of programming. Yet the story didn’t end there.

Last week’s newsletter finished up the five-part series focused on common business problems with the discussion about engineering efficiency vs engineering experience. In that article we discussed how the drive for efficiency often leads companies to focus on speed and productivity, neglecting the overall experience of their employees. This week we are discussing a new framework that just came out called DX Core 4, developed by Abi Noda (DX co-founder & CEO) and Laura Tacho (DX CTO), in collaboration with the authors of DORA, SPACE, and DevEx – Dr. Nicole Forsgren, Dr. Margaret-Anne Storey, and Dr. Thomas Zimmerman amongst others. A few weeks ago, I got to spend some time with Abi to ask questions about DX Core 4.

Now, before we dive into this new framework, I had thought that the use of Lines of Code as a metric for productivity had died out in the 1990’s when equally bad alternatives such as Allan Albrecht’s Function Point Analysis were introduced. However, to my surprise apparently financial services companies are still using Lines of Code (LOC) or something abhorrently close to it to “show that a few highly productive teams were responsible for a lot of its code.” This lingering reliance on outdated metrics like LOC underscores the challenge of defining and measuring productivity in meaningful ways. Modern frameworks such as DORA, SPACE, and DevEx aimed to address this gap but reveal the complexities of creating a holistic approach that satisfies both technical and organizational needs.

Frameworks such as DORA, SPACE, and DevEx each approach productivity measurement from a distinct angle but fall short of providing a comprehensive solution. DORA, for instance, offers well-defined metrics on system performance, but its narrow focus misses broader productivity elements, especially those tied to developer satisfaction and workflow efficiency. SPACE allows for more flexibility by emphasizing perceptual measures, yet it can be challenging to apply consistently, as it lacks prescriptive guidance. DevEx, meanwhile, focuses exclusively on self-reported developer experience, isolating it from broader productivity metrics that stakeholders in engineering and leadership alike need to see.

Recognizing these gaps, the DX Core 4 framework was developed to unify the strengths of these existing models, synthesizing them into a balanced and standardized approach. DX Core 4 aims to provide a framework that according to the creators offers:

“Meaningful and useful to stakeholders across the business (EMs, CTO, CEO, CFO).

Measurable in a consistent way across most companies, and can be benchmarked.

Balanced (i.e., a basket of self-reported and objective metrics across different dimensions).”

Its ultimate goal being to support, sustain, and enhance the developer experience while translating these insights into tangible business value.

The DX Core 4, as its name implies, framework operates on four core dimensions: Speed, Effectiveness, Quality, and Impact. Rather than zeroing in on a single metric, DX Core 4 aims to balance these factors to capture the holistic experience of engineering teams. As we’ve talked about before and know from eponymous laws such as Goodhart’s, metrics can quickly lose their importance when used to measure individuals or even a team's performance. We almost always need counterbalanced metrics. The four dimensions are:

• Speed: Speed is often the first measure that comes to mind in productivity discussions and attempts to measure how quickly teams deliver new features, fixes, and updates.

• Effectiveness: This dimension dives into the alignment between what we produce and the value it brings, examining elements like code sustainability and project prioritization.

• Quality: Quality measures touch on stability, robustness, and long-term maintainability, using metrics such as incident rates and issue reports.

• Impact: Impact focuses on the connection between engineering outputs and the business’s strategic goals. This includes how well the engineering work aligns with user satisfaction, revenue, or other organizational objectives.

Within these four dimensions under Effectiveness we have the Developer Experience Index (DXI), showing the inspiration drawn from DevEx, offering a quantifiable view into the developer experience and predicting productivity outcomes. Designed as a forward-looking indicator, DXI measures 14 aspects of developer experience on a 5-point Likert scale, providing a nuanced metric that supports broader strategic decisions.

DXI distills responses from a comprehensive set of questions covering workflow, collaboration, and resource accessibility into a single score. Much like indices in employee engagement, DXI is designed to be simple, actionable, and insightful. It offers engineering leaders an objective way to gauge and respond to developer satisfaction and workflow. DXI goes beyond a satisfaction metric as it purportedly provides a tool for guiding productivity improvements, making its ROI clear and compelling for finance teams. By catching inefficiencies and friction early, DXI enables teams to make proactive adjustments that prevent small issues from snowballing into productivity blockers.

Pros

What I like about the DX Core 4 framework is that it represents a fresh approach to developer productivity that attempts to balance methodology with relevance to business outcomes. By taking inspiration from previous models and prioritizing both productivity and developer experience, DX Core 4 offers companies a new tool to drive impactful change. Here are some of the specific aspects that I appreciated:

• Predictive Power: DX Core 4’s predictive capabilities stand out as a meaningful advancement in measuring developer productivity. Rather than just looking at metrics retroactively, DX Core 4 uses DXI to offer forward-looking insights, giving companies a chance to proactively address potential productivity issues. By identifying friction points within the development process early on, organizations can implement changes before they affect delivery timelines or developer satisfaction. This predictive aspect enhances the practical value of DX Core 4, allowing it to function as a true management tool rather than a passive measurement framework.

• Executive Value: DX Core 4’s alignment with executive needs is another point of distinction. The framework’s dimensions are areas that speak to both technical and non-technical stakeholders. For executives, DX Core 4 provides clarity by linking developer productivity with business objectives, translating engineering metrics into language that resonates at the executive level. This alignment helps facilitate better communication and decision-making around resourcing, budgeting, and strategic initiatives, as leaders can see how engineering productivity directly impacts the company’s overall performance.

• PRs per Engineer: The inclusion of PRs per engineer (pull requests per engineer) was a bold but somewhat risky move. There are definitely engineers and organizations that have had really bad experiences with this metric, so much so that they might not try this framework because of that. DX Core 4’s creators recognize that while PRs per engineer is an imperfect measure, but felt it was nonetheless a useful signal of workflow and output when interpreted carefully. A cautionary note accompanies this metric, emphasizing the need to use it in balance with other indicators, particularly the DXI, to avoid counterproductive incentives. It is also stressed that it should never be used as a standalone metric or tied to individual performance reviews. This balanced approach is essential for ensuring that PRs per engineer remains a helpful, rather than harmful, metric.

Note: Abi did share with me the concept that they are considering for “Weighted PRs” which would help add more nuance to this metric. I particularly appreciate the adaptability that this demonstrates. Knowing how so much evolves in our industry, taking a hardline stance is a quick path to irrelevance. Being flexible about the need to evolve as new ideas are formed and new information is discovered will help stay relevant for longer.

• Supporting Engineers: Finally, one of the most commendable aspects of DX Core 4 is its emphasis on supportive implementation. DX Core 4 is designed not as a tool for evaluating developers but as a resource to help them perform their best work. The framework includes communication guidelines that encourage companies to introduce it as an ally rather than a watchdog. By positioning DX Core 4 as a productivity enhancer rather than a performance evaluator, organizations can foster a more positive culture where developers feel supported rather than scrutinized. Companies like Plaid have successfully applied DX Core 4’s principles to balance flow metrics with developer experience, creating a more sustainable and fulfilling work environment for their engineering teams.

Overall, the DX Core 4 framework strikes an impressive balance, providing actionable insights that benefit both developers and executives. Its ability to translate developer experience into meaningful business metrics, combined with its balanced approach to productivity, sets it apart as a comprehensive solution to the challenge of measuring and improving developer productivity.

Cons

While DX Core 4 has many strengths, there are aspects of the framework that may raise questions or concerns for certain users, especially for those looking for more comprehensive measures or alignment with business frameworks.

• Impact Should Be Tied to Broader Outcomes: Although DX Core 4 includes "impact" as one of its four core dimensions, the framework’s approach to impact measurement could benefit from a stronger connection to broader business outcomes, particularly when aligned with frameworks like the Product Operating Model. While DX Core 4 effectively links productivity to engineering outcomes, it could go a step further by explicitly tying engineering metrics to strategic business objectives, such as customer engagement. This would offer an even clearer line of sight from developer activity to tangible outcomes, such as customer satisfaction or market expansion, enhancing its relevance for senior executives.

• Single-Item Scales in DXI: This DX Core 4’s Developer Experience Index (DXI) relies on single-item scales, meaning each question measures only one aspect of a dimension. This approach has both advantages and limitations. Single-item scales are efficient, reduce survey fatigue, and work well for unambiguous constructs, which is why DXI uses them to assess elements like speed or quality. However, single-item scales can be overly simplistic when measuring more complex, multifaceted constructs. I was trained by professors who really did not like them but most of us use NPS which is a single-item scale because it asks a single question - “How likely are you to recommend [Organization X] to a friend or colleague?"

The creators of DX Core 4 cite research supporting the use of single-item scales for constructs that are straightforward to measure, referencing the article Single Item Measures in Psychological Science. This research argues that single-item measures are appropriate in cases where the construct is unambiguous, although they have traditionally been criticized in academic and applied research settings for lacking depth. Despite the limitations of single-item scales, DX Core 4’s research rigor helps strengthen its validity. The detailed correlation analysis to examine both convergent and divergent validity was shared with me. This analysis shows strong relationships among related constructs, like collaboration and connectedness, and weaker relationships between unrelated constructs, which supports the DXI’s effectiveness in measuring distinct facets of developer experience. Additionally, reliability testing using Cronbach’s alpha yielded a high score (α = .87), indicating strong internal consistency among DXI items. While the single-item scales could be seen as a limitation, the high reliability and validity scores help alleviate some of my concerns about their effectiveness.

In summary, while DX Core 4’s design choices are pragmatic, especially for organizations looking for a quick, actionable overview of developer productivity, some elements could be enhanced to provide even greater depth and flexibility. Strengthening the link between impact and broader business outcomes, and offering an option for multi-item scales, could make the framework more adaptable to diverse organizational needs.

Conclusion

The DX Core 4 framework presents a meaningful advancement in how we measure, understand, and enhance developer productivity. By balancing dimensions of speed, effectiveness, quality, and impact, it provides organizations with a holistic view that aligns engineering performance with broader business objectives. Through its core component, the Developer Experience Index (DXI), DX Core 4 not only highlights productivity in real-time but also serves as a predictive tool, allowing companies to address potential productivity issues before they escalate. This balanced approach enables leaders to make informed decisions that benefit both developers and the organization at large, fostering an environment where productivity and satisfaction go hand in hand.

Ultimately, DX Core 4 invites us to rethink how we measure productivity in modern development environments. With its balance of technical metrics and human-centered insights, this framework provides a path for companies to support their engineering teams in a way that’s data-driven, actionable, and deeply aligned with organizational goals. As the industry continues to evolve, DX Core 4 stands as a valuable tool for building a supportive, high-performing engineering culture that’s ready to meet the demands of today and the challenges of tomorrow.