--- title: "How should DX be used for performance assessment?" canonical_url: "https://docs.getdx.com/knowledgebase/using-dx-for-performance-assessment/" md_url: "https://docs.getdx.com/knowledgebase/using-dx-for-performance-assessment.md" last_updated: "2026-05-08" --- # How should DX be used for performance assessment? Whether it's performance review season or you're evaluating personnel more broadly, there are times when having concrete performance metrics for individual developers may seem necessary. However, it's crucial to proceed with care. Using development metrics for individual performance evaluation is a sensitive and often problematic practice that can lead to unintended consequences if not handled with extreme caution. Leading researchers consistently caution against relying on metrics to assess individual performance: - _"Pounds of coal shoveled per hour will tell you which shovelers are the best shovelers; lines of code per minute will not tell you which software developers are the best software developers."_ –Collin Green & Ciera Jaspan, Google - _"Tracking individual performance can create a morale issue, which perversely could bring down overall productivity. Research has shown that developers do not like having metrics focused on identifying the productivity of individual engineers; this has also been our experience at Google."_ –Ciera Jaspan, Google - _"It is commonly agreed on that the nature of knowledge work fundamentally differs from manual work and, hence, factors besides the simple output/input ratio need to be taken into account."_ –Stefan Wagner and Florian Deissenboeck, Defining Productivity in Software Engineering - _"Rewarding developers for lines of code or higher output volumes leads to bloated software that incurs higher maintenance costs and higher cost of change."_ –Dr. Nicole Forsgren, Lead author of Accelerate and SPACE Still, there are moments when business needs make it necessary to use data for performance assessment. At DX, we believe this can be appropriate—_if approached with great care_. This article outlines our recommended practices for doing so responsibly. We strongly advocate for using a broad set of metrics that reflect the many dimensions of developer work. Performance data should go beyond task completion to include contributions like code reviews, incident response, technical interviews, and peer feedback. Ultimately, no set of metrics can capture the full picture. Personnel decisions should always involve thoughtful judgment and human discretion. ## Recommended guidelines We recommend combining multiple metrics into a single composite score—referred to as a _Performance Index_—to represent overall performance, as illustrated in the example [Performance report](https://docs.google.com/spreadsheets/d/19YH5uhFkNDsW3NxFkfuVq2HZ0YBXfMxffev4MPVY1nM/edit). DX advises creating these reports in a spreadsheet rather than within the DX platform, for several important reasons: 1. **Discretion and control:** Individual performance reporting should be handled in a secure, tightly controlled environment. Unlike DX, spreadsheets are less likely to be openly accessible or discoverable within the organization. 2. **Sensitive data integration:** Performance evaluations often require inputs beyond engineering metrics—such as peer feedback, compensation data, or promotion history. These data points are highly sensitive and should not be uploaded to DX. 3. **Flexibility:** Spreadsheets offer maximum flexibility for calculating and adjusting weighted composite scores, as outlined later in this article. The composite score—or _Performance Index_—can be used by leadership to assess and compare individual performance. When doing so, the following principles are essential: - **Metrics never tell the full story.** Some roles, especially senior engineers, contribute in ways that aren't easily measurable (e.g., mentoring, architecture, cross-team leadership). Use metrics as a signal, not a conclusion. - **Compare like-for-like.** Performance should be evaluated within peer groups—such as by role or job level—not across the entire engineering organization. - **Keep it confidential.** These reports should be limited to upper management. If developers become aware of metric-based evaluations, it can lead to metric gaming and reduce the reliability of these signals in the future. ## Creating a report ### Step 1- Export metrics from DX 1. Browse to the [Breakdowns report](https://app.getdx.com/report/breakdowns) in DX and view it **By contributor**. 2. Select the relevant date period. 3. Click the download icon to export a CSV. ### Step 2- Export additional data from DX In addition to the metrics from the Breakdowns report, you may want to load in additional metrics or user attributes such as job level, role, or location. 1. Browse to [Data Studio](https://app.getdx.com/datacloud/studio) in DX 2. Create a query that generates metrics and/or attributes by user 3. Download the CSV ### Step 3- Compile your report 1. Import your CSVs into a spreadsheet in Microsoft Excel or Google Sheet. 2. Add additional data such as salary and peer performance ratings. ### Step 4- Build your composite score 1. Standardize each metric on a 0–100 scale using percentiles, min-max normalization, or binary thresholds. 2. Calculate a weighted average of the standardized 0–100 scores to generate an overall "Performance index" score. 3. See the section below for suggested metrics to include in your report. ## Suggested metrics | Metric | Reasoning | Data source | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | TrueThroughput® | TrueThroughput® calculates weighted PR throughput, providing the most accurate measure of development output. | DX | | PR reviews | Code reviews are like assists in basketball—they are as important as writing code. | DX | | PR review comments | Review comments provide a signal into review effort and quality, which is important to capture in addition to the number of reviews. | DX | | PR review turnaround | Review turnaround time captures an individual's responsiveness for code reviews, providing a lens into their overall performance and impact. | DX | | Issues completed | Issues data is important to include because it can capture work that does not show up in PRs. | DX | | Peer rating | This is critical to include in order to capture the impact of individuals beyond what shows up in metrics.

\*Weighting of at least 25% recommended | HR platform | | Support tickets resolved | Support tickets take away from regular coding activities, and is important to capture. | DX or support platform

\*Use DX to aggregate issues or PRs that are classified as support. | | Docs created | Docs creation in tools like Confluence are an important dimension to capture, when applicable. | DX | | Incidents handled | Incident handling takes away from regular coding activities, and is important to capture. | DX

\*See IncidentIO follow-ups | | Interviews | Interviewing hiring candidates takes away from regular coding activities, and is important to capture. | DX or ATS Platform

\*Use DX calendar integration. | | AI usage (optional) | Organizations with official AI mandates should consider including this. | DX | | Slack messages (optional) | Organizations that use Slack can include message counts to capture glue work that doesn't show up in other metrics. | Slack export | --- ## Sitemap [Overview of all docs pages](/llms.txt)