Measuring engineering performance is critical – but understanding the methodology behind your measurements is equally important. This guide explains what DX Core 4 metrics are, how they are calculated, and how to take advantage of the flexibility to measure them either with system or self-reported data.

The DX Core 4 tracks engineering productivity across four dimensions, each with a key metric:

The Developer Experience Index (DXI) is measured using self-reported data from surveys. However, diffs per engineer, change fail percentage, and time spent on new capabilities can be measured in two different ways:

This flexibility allows teams to start measuring immediately, even with imperfect system data. Establishing a baseline now is better than waiting for perfection.

What it is:

Diffs per engineer is the number of merged pull requests authored by developers.

How it’s measured:

This metric is calculated as a count of pull requests merged by developers, excluding those authored by bots or contributors who don’t regularly write code. When measured through self-report, developers provide the average number of pull requests they merge per week, based on their activity over the past 90 days.

Why it matters:

PRs per engineer provides an understanding of flow and friction through the system. This helps organizations focus on enabling faster lead times by lowering friction and red tape to deliver.

What it is:

DXI is a measure of key engineering performance drivers that are linked to financial impact. These drivers can be customized for each organization, but typically include things such as test coverage, change confidence, and more.

How it’s measured:

The DXI score is the mean average of all individual driver scores that are captured through self-reported questions in DX Snapshots.

Why it matters:

The DXI is a measure of how much friction there is in the development process. Organizations can improve this by tackling opportunities such as code quality and build tooling. Read more about the Developer Experience Index.

What it is:

The percentage of deployments that result in failure (e.g., incidents or rollbacks).

How it’s measured:

This metric is calculated as the number of incidents divided by the number of production deployments when measured through systems. When measured through self-report, it reflects the frequency of failures based on a standardized question adapted from DORA’s research assessment.

Why it matters:

Change fail percentage is a measure of how frequently there are failures when changes are released. This metric helps ensure that organizations are not focusing on speed at the expense of quality, and provides insight into how to provide better observability for making changes confidently.

What it is:

The percentage of time teams spend working on new features versus other types of work (e.g., maintenance, bugs).

How it’s measured:

This metric is determined by integrating with issue tracking tools (like Jira) to categorize work types based on your team’s definitions when measured through systems. When measured through self-report, developers provide a breakdown of how they’ve allocated their time over the past 90 days.

Why it matters:

A company can only remain competitive in the market by innovating and delivering new capabilities to its customers. As such, it’s important to track how much time is spent on new capabilities versus KTLO and maintenance, and to look for ways to enable engineers to spend more time on new capabilities.

The DX Core 4 provides the flexibility teams need to measure what matters—regardless of where they are on their journey. Start where you are, establish a baseline, and iterate over time. With DX Core 4, teams can confidently measure what matters, starting today—without needing perfect system instrumentation or data hygiene.