Your CFO wants a number that proves the engineering team is productive, but your engineers want to know that number won’t be used to rank them on a leaderboard or justify cutting headcount. Both concerns are valid, and most measurement approaches fail because they serve one side while alienating the other.
This guide gives you a practical framework for measuring real delivery output using DORA and SPACE, explains how AI-assisted coding has changed what “normal” throughput looks like, and shows you how to do it without turning measurement into surveillance. You will also learn to spot when your developer productivity metrics are actually signaling a hiring problem, not a process problem.
In this guide:
- Why Output Metrics Fail in Real Engineering Work
- Use DORA to Track Delivery Speed and Reliability
- Add SPACE So You Do Not Miss Burnout, Friction, and Hidden Work
- Add DX Core 4 When You Need One Framework That Talks to Finance
- How AI Developer Productivity Tools Are Resetting the Baseline
- Common Measurement Mistakes That Break Trust With Engineering Teams
- Build a Team-Level Measurement System People Will Trust
- A Practical Decision Matrix for Staffing, Process, and Platform Changes
- When the Numbers Point to a Hiring Problem Instead of a Process Problem
- Frequently Asked Questions
- How Arc Helps Close the Gap
Why Output Metrics Fail in Real Engineering Work
The most common developer productivity metrics still in use reward the wrong behavior, collapse under AI-assisted workflows, and make cross-team comparisons meaningless. Lines of code, commit counts, pull request volume, and story points each carry a specific failure mode that engineering leaders need to understand before building any measurement system.
Lines of Code Reward the Wrong Behavior
A developer who refactors a 400-line authentication module down to 120 lines of cleaner, more maintainable code just made your system better. By a lines-of-code metric, that developer had negative productivity for the day.
Lines of code incentivizes sprawl, not quality. It punishes the exact work you want senior engineers doing: simplifying architecture, reducing technical debt, and writing code future teammates can actually read. No serious engineering organization treats lines of code as a primary metric in 2026, yet it still shows up in executive dashboards because it feels concrete.
Commit Count and Pull Request Volume Breakdown in the AI Era
AI coding assistants like GitHub Copilot, Cursor, and Claude Code have made this problem acute. A developer using an AI assistant can generate 15 small PRs in a day for boilerplate, test stubs, and scaffolding code. A developer doing the same work manually might produce three.
By PR count, the first developer looks five times more productive. The actual shipped value might be identical, or the AI-generated code might carry quality issues that create rework next sprint.
That risk isn’t hypothetical: DORA’s 2025 State of AI-assisted Software Development report (the first edition where DORA shifted its entire research focus to AI) found that the time developers save generating code is frequently reallocated to auditing and verification rather than eliminated, and that higher AI adoption is associated with an increase in both delivery throughput and delivery instability.
Measuring commits without measuring what those commits do, and how much review load they create downstream, is noise, not signal.
Story Points and Hours Logged Distort Cross-Team Comparisons
Story points were designed as a team-internal planning tool, not a cross-team productivity benchmark. A team carrying heavy technical debt on a legacy payments service will burn 8 points on work that a team building on a modern stack finishes in 2 points, so comparing their velocity is meaningless.
Hours logged is even worse. It measures presence, not output. A developer spending six hours fighting a flaky CI pipeline and two hours coding looks less “productive” by hours-on-code than someone who happened to have a clean build environment that week. The metric captures none of the systemic friction that actually determines throughput.
What Good Measurement Should Capture Instead
Effective developer productivity metrics measure three things:
- Delivery speed and reliability (how fast and safely code reaches production)
- Developer experience (whether the environment supports or blocks good work)
- Business impact (whether shipped work moves customer or revenue outcomes)
No single metric covers all three. Combining these three dimensions is how you actually improve developer productivity measurement without turning your dashboard into a scoreboard used against people, which is exactly why the DORA and SPACE frameworks exist together, not as substitutes for each other.
Use DORA to Track Delivery Speed and Reliability
DORA metrics, developed by the DevOps Research and Assessment team (now part of Google), are the industry standard for measuring software delivery performance. The four core metrics describe how fast and reliably your team ships code to production. They work because they measure system-level outcomes, not individual activity, telling you whether your deployment pipeline, review process, and incident response are healthy.
One caveat worth flagging up front: DORA’s 2025 report (the first edition to shift its entire research focus to AI) also moved away from a strict “Elite/High/Medium/Low” tier system toward percentile-based bands. The figures below reflect the commonly cited “top-performer” range across recent reports; treat them as directional targets, not a certification test.
| Metric | What It Measures | Top-Performer Range | Common Misread |
| Deployment Frequency | How often code reaches production | On-demand (multiple times/day) | Equating frequency with quality |
| Lead Time for Changes | Time from commit to production | Under one day | Ignoring queue time in code review |
| Change Failure Rate | % of deployments causing incidents | Roughly 5% or lower (some reports put the top band as wide as 0–15%) | Punishing teams for deploying more |
| Time to Restore Service | Time to recover from a failed deploy | Under one hour | Confusing fast recovery with fewer incidents |
Tools That Automate DORA and SPACE Data Collection
The “how to pull the data” instructions throughout this section describe what’s possible manually. In practice, most teams beyond a certain size use a purpose-built tool to collect and surface these metrics automatically. The four most commonly used in 2026:
- LinearB: Integrates with GitHub, GitLab, and Jira to surface DORA metrics, cycle time, and review turnaround automatically. Strong on engineering manager dashboards and team-level benchmarking.
- Jellyfish: Focuses on connecting engineering metrics to business outcomes and R&D investment reporting. Particularly useful for the CFO conversation DX Core 4 is also designed for.
- Swarmia: Developer-first approach; surfaces flow metrics and engineering health with emphasis on team-level visibility rather than individual ranking. Popular with teams that prioritize developer trust in their measurement system.
- DX: Built by the researchers behind DX Core 4; combines automated system metrics with developer surveys to produce the DXI composite score. The only tool natively implementing the full DX Core 4 framework.
None of these replace the judgment calls this article describes; they just automate the data collection so your engineering leaders spend their time interpreting signals rather than querying CI/CD logs. Evaluate each against what your team will actually trust and use, not just what it can technically measure.
Deployment Frequency
Deployment frequency tracks how often your team ships code to production. Top-performing teams deploy on demand, often multiple times per day. Teams deploying weekly or less often usually have manual release processes, large batch sizes, or insufficient test coverage blocking confidence in smaller releases.
How to pull the data: Query your CI/CD platform (GitHub Actions, GitLab CI, Jenkins) for successful production deployments per week. Filter out staging or dev deployments.
A common misread is treating high deployment frequency as inherently good. A team deploying broken code ten times a day has high frequency and terrible delivery performance. Always read deployment frequency alongside change failure rate.
Lead Time for Changes
Lead time for changes measures the time between a developer’s first commit and that code running in production. It captures everything: coding time, code review wait time, CI pipeline duration, and deployment queue.
Teams with lead times under one day can iterate quickly on customer feedback. Teams with lead times measured in weeks usually have bottlenecks in code-review turnaround times, manual QA gates, or slow deployment pipelines.
How to pull the data: Track the timestamp of the first commit on a branch through to the production deployment timestamp in your CI/CD tooling. Tools like Jira linked to GitHub can automate this.
Change Failure Rate
Change failure rate is the percentage of deployments that cause a production incident, rollback, or hotfix. A rising change failure rate often signals insufficient test coverage, rushed reviews, or AI-generated code that passed review without adequate scrutiny.
This metric is most directly affected by AI-assisted coding right now. DORA’s 2025 findings are consistent on this point: teams that adopted AI coding tools saw individual effectiveness and code quality improve, but delivery instability (measured through change failure rate) rose in parallel. The takeaway isn’t “AI makes code worse.” It’s that shipping more code, faster, without scaling review capacity to match, is exactly what produces more failed deployments.
How to pull the data: Divide the number of failed deployments (requiring rollback, hotfix, or incident response) by total deployments in the same period. Pull incident data from your on-call tooling (PagerDuty, Opsgenie) and correlate with deploy timestamps.
Time to Restore Service
Time to restore service (sometimes called MTTR, mean time to recovery) measures how quickly your team recovers from a failed deployment or production incident. Top-performing teams restore service in under one hour.
This metric reflects your incident response maturity, runbook quality, and system observability. A team with a high change failure rate but fast restoration time is handling risk well. A team with a low failure rate but eight-hour recovery times has a fragile incident response process that will eventually cost them.
How to pull the data: Measure the duration between incident creation and resolution in your incident management platform.
Add SPACE So You Do Not Miss Burnout, Friction, and Hidden Work
DORA tells you how your delivery system performs, but it doesn’t tell you whether your team is burning out to achieve those numbers. The SPACE framework, developed by researchers including Nicole Forsgren, captures the human and collaborative dimensions that throughput metrics hide.
Consider this scenario: a team posts strong DORA numbers for two consecutive quarters. Deployment frequency is high, lead time is under a day, and change failure rate stays low. By every delivery metric, they look exceptional.
Behind those numbers, three senior engineers carry 80% of the on-call load, review turnaround stress is causing two team members to interview elsewhere, and the team has stopped mentoring or sharing knowledge because they are too stretched. That team is six months from a retention crisis that will crater their DORA numbers. SPACE catches this before it happens.
Satisfaction and Well-Being
Measure this through quarterly developer surveys. Ask about on-call burden, satisfaction with tooling, and whether engineers feel they can do their best work. Track retention rates as a lagging indicator.
A drop in satisfaction scores with stable DORA metrics is a leading indicator of attrition. Take it seriously. Teams with high satisfaction ship more sustainably over time.
Performance and Outcomes
Performance in the SPACE framework means business outcomes, not lines of code. Track feature adoption rates, customer satisfaction tied to shipped features, defect rates in production, and uptime.
This dimension connects engineering work to what the business actually cares about. A team that ships fast but delivers features no customer uses has a performance problem that DORA alone cannot see.
Activity Without Over-Indexing on Busyness
Activity metrics (commits, PRs, code reviews completed) have a role, but only as context alongside other dimensions. Use them to spot absence of activity (a team that stopped shipping entirely) rather than to rank output.
Review turnaround time is one of the most useful activity signals. If PR review time is climbing, it usually means the team is overloaded, missing a senior reviewer, or drowning in AI-generated PRs that need careful scrutiny.
Communication and Collaboration
Track how well knowledge moves across the team. Metrics here include code review participation breadth (is one person reviewing everything?), mentoring hours, and documentation contributions.
Teams where knowledge lives in one or two people are fragile. If those individuals leave or burn out, cycle time and quality collapse. Measure collaboration to spot single points of failure before they break.
Efficiency and Flow
Focus time (uninterrupted blocks of two or more hours) and context-switching frequency are the core signals here. Developers in a flow state produce higher-quality work. Developers switching between four Slack threads, two meetings, and a code review every 30 minutes produce friction.
Track the ratio of meeting hours to focus hours per developer per week. If your engineers have fewer than four hours of uninterrupted focus time per day, your processes are eating your productivity before any code gets written.
Read more: Does Remote Work Increase Productivity? What the Evidence Says and What Actually Drives Output.
Add DX Core 4 When You Need One Framework That Talks to Finance
DORA and SPACE are complementary but distinct. Engineering leaders sometimes need a single, unified language that works for a CFO conversation as well as an engineering retrospective. That’s the problem DX Core 4, published in December 2024 by Abi Noda and Laura Tacho at DX in collaboration with the researchers behind DORA, SPACE, and DevEx, was designed to solve.
DX Core 4 organizes developer productivity into four dimensions (Speed, Effectiveness, Quality, and Impact), each with a primary metric and supporting signals:
| Dimension | Primary Metric | Why It Was Chosen |
| Speed | Diffs per engineer per week | More legible to non-technical stakeholders than lead time; measures actual throughput, not just pipeline speed |
| Effectiveness | Developer Experience Index (DXI) | Composite score from developer surveys capturing friction, flow, and satisfaction in one number |
| Quality | Change failure rate | Directly from DORA; catches the instability that speed metrics miss |
| Impact | Feature adoption or business KPIs | Connects engineering output to what the business actually cares about |
The framework explicitly incorporates DORA (lead time and deployment frequency appear as supporting metrics under Speed; change failure rate is the Quality primary), SPACE (DXI draws on satisfaction, efficiency, and collaboration signals), and DevEx (feedback loops, cognitive load, and flow state feed into DXI calculation). It’s a unification, not a replacement.
When to use DX Core 4 versus DORA + SPACE separately:
DX Core 4 is the right choice when you need a single dashboard that works across organizational levels, from a team retro to a board update. Its primary metrics are designed to be legible without engineering context: “each engineer ships 4.3 changes per week” lands differently in a leadership meeting than “our lead time is 1.2 days.”
DORA + SPACE separately gives you more granularity within each dimension. If your problem is specifically about delivery pipeline health, DORA alone is more precise. If your problem is specifically about developer experience or burnout, SPACE is more targeted.
DXI as the composite metric your CFO actually asked for:
The opening of this article frames the core tension: your CFO wants a number, and your engineers worry that number will be weaponized. DXI is the closest thing to an honest answer to that tension: a composite score derived from developer surveys covering friction, flow state, and satisfaction, benchmarked against other organizations so it isn’t just an internal number disconnected from external context.
It doesn’t replace the nuance of DORA or SPACE, but it gives engineering leaders something to bring to a board meeting without resorting to lines of code or story points.
The framework has been tested with over 300 organizations, with reported outcomes including 3–12% increases in engineering efficiency and 14% increases in R&D time spent on feature development.
How AI Developer Productivity Tools Are Resetting the Baseline
AI coding assistants are now the most consequential category of developer productivity tools most engineering orgs have adopted in the past two years. By late 2025, Google’s DORA research found that roughly 90% of software teams used AI tools at work daily. The real question is not whether your team uses them, but whether your measurement system accounts for how they change the shape of engineering work.
Where AI Speeds Up the Workflow Today
AI tools deliver measurable speed gains in specific, well-defined parts of the workflow:
- Boilerplate and scaffolding code: Setting up API routes, data models, and repetitive CRUD operations
- Test generation: First-draft unit and integration tests from existing code
- Code review summarization: Summarizing large PRs to help reviewers focus on critical sections
- First-draft PRs: Generating initial implementations that developers then refine
Sonar’s 2026 State of Code Developer Survey, which surveyed 1,149 developers globally, found that developers report an average 35% boost in personal productivity from AI tools, with 82% saying AI helps them code faster.
Those gains are real, but they’re concentrated in specific task types: writing documentation (74% effective), generating tests (59% effective), and assisting new code development. The same survey found AI less effective for refactoring and optimizing existing code (43% effective), which is exactly the kind of complex, context-dependent work senior engineers spend most of their time on.
The improvement is real for this category of work; it just isn’t a number you can extrapolate across everything an engineer does.
Where AI Still Does Not Replace Engineering Judgment
AI tools do not meaningfully help with:
- Architecture decisions that require understanding system constraints and business context
- Debugging novel production incidents where the root cause spans multiple services
- Cross-team coordination on shared interfaces and migration planning
- Security review of authentication flows, access control logic, and data handling
- Technical debt prioritization that requires codebase history and business impact judgment
If your team spends most of its time on these activities, AI adoption will show minimal impact on throughput metrics. Measuring “AI productivity gains” without distinguishing task type produces misleading results.
How AI Changes Review Load, Quality Risk, and Metric Interpretation
Here’s the operational effect engineering leaders are seeing in 2026. DORA’s 2025 research framed AI’s role precisely: AI is an amplifier, not a fix. Teams with strong foundational practices (clean deployment pipelines, mature code review, well-maintained test coverage) see AI accelerate delivery without a proportional increase in instability.
Teams without those foundations see AI accelerate delivery and instability at the same time, because AI makes it faster to ship code into a system that was already fragile. The rest of this section describes that distinction in operational terms.
PR volume is up, and review load is up faster
AI-generated code still requires human review. Sonar’s 2026 survey found that 95% of developers spend at least some effort reviewing, testing, and correcting AI output, with a majority rating that effort as moderate or substantial.
More pointedly, 38% of developers say reviewing AI-generated code requires more effort than reviewing code written by human colleagues, while only 27% say it requires less. And critically, only 48% of developers always check their AI-assisted code before committing, meaning a meaningful share of AI-generated code enters review without any pre-screen by the developer who wrote it.
Teams without enough senior reviewers face a review bottleneck that slows lead time for changes, even as code is written faster.
Code quality variance increases
AI-generated code can introduce subtle bugs, inconsistent patterns, or security issues that pass casual review. Teams with strong code review discipline catch these; teams without it see rising change failure rates within months of heavy AI adoption- the exact pattern DORA’s 2025 research documented at the industry level.
DORA benchmarks need recalibration
A team deploying three times per day pre-AI might now deploy eight times per day. That does not mean their delivery capability tripled. Engineering leaders are adjusting baseline expectations to separate genuine throughput improvement from AI-inflated volume.
Some organizations now track “human-initiated vs. AI-assisted” deployments separately, and weight change failure rate more heavily than deployment frequency when judging AI-era performance.
That’s the real question behind how to improve developer productivity measurement in 2026: which combination of signals your team will actually trust enough to act on.
Read more: How Hiring Remote Developers Builds Strong and Diverse Teams
Common Measurement Mistakes That Break Trust With Engineering Teams
Goodhart’s Law states that when a measure becomes a target, it stops being a good measure. Every mistake in this section is Goodhart’s Law in action: the moment engineers know they’re measured on commit count, they optimize for commit count, not for shipping value.
Using individual DORA metrics for performance reviews
DORA was built to measure system and team health, not to rank people. The moment an individual’s deploy count or lead time shows up in a performance conversation, engineers start optimizing for the number instead of the outcome, and the metric stops meaning anything.
Comparing velocity across teams with different tech debt loads
A team maintaining a decade-old billing system will always look “slower” on raw throughput than a team shipping greenfield features on a modern stack, no matter how skilled either team is. Compare a team’s trend against its own baseline, not against a team facing a different technical reality.
Measuring a quarter that included a major migration or incident response
If a team spent six weeks migrating off a deprecated database or handling a security incident, that quarter’s DORA and SPACE numbers will look worse by design. Flag those quarters and exclude them from trend comparisons, or you’ll draw the wrong conclusion about the team’s normal performance.
Ignoring how on-call burden is distributed
A team can hit every DORA target while two engineers absorb 80% of the pages. The dashboard will look healthy right up until those two people burn out or leave, at which point every metric collapses at once.
Build a Team-Level Measurement System People Will Trust
The fastest way to destroy trust with an engineering team is to use delivery metrics to rank individual performance. The fastest way to build trust is to let teams own their metrics and use them to improve their own workflows.
You don’t need to add more dashboards to improve productivity. Use the ones you already have, just don’t turn them into a surveillance tool.
What to Measure Weekly Versus Quarterly
Weekly (team-level dashboard):
- Deployment frequency
- Lead time for changes
- PR review turnaround time
- Change failure rate
- Active incidents and time to restore
Quarterly (retro and planning inputs):
- Developer satisfaction survey results
- Retention and attrition data
- Feature adoption rates and customer satisfaction
- Flow time and context-switching trends
- Code review participation distribution
- Onboarding time for new team members
Weekly metrics inform tactical decisions (“our review turnaround spiked, let’s investigate”). Quarterly metrics inform strategic decisions (“satisfaction is declining despite good throughput, something systemic is off”).
What Belongs at the Team Level and What Should Never Rank Individuals
- Team-level metrics (safe and useful): deployment frequency, cycle time, change failure rate, MTTR, review turnaround time, flow distribution, throughput trends.
- Never use for individual ranking: commit count, lines of code, number of PRs, story points completed, hours logged. Using these to compare individuals creates gaming behavior, damages psychological safety, and undermines the culture that sustains high performance.
How to Combine Quantitative Signals With Qualitative Feedback
Neither data nor conversation alone gives you the full picture. Use both:
| Approach | Strengths | Weaknesses |
| Metrics-first culture | Objective, consistent, easy to trend over time | Misses context, morale, and hidden work |
| Qualitative-first culture | Captures nuance, builds trust, surfaces root causes | Hard to scale, subject to recency bias |
| Combined (recommended) | Full picture of delivery and experience | Requires discipline to maintain both inputs |
Run monthly team retrospectives where you review dashboard metrics and have an open discussion about what felt hard, what slowed people down, and what would make next month better.
A Practical Decision Matrix for Staffing, Process, and Platform Changes
When metrics show a problem, use this framework to decide what kind of fix it needs:
| Signal | Likely Root Cause | Action |
| Rising lead time + stable team size | Process friction (review bottleneck, slow CI) | Fix the pipeline or review process |
| Rising lead time + recent attrition | Understaffing or lost expertise | Evaluate hiring needs |
| High change failure rate + new AI adoption | Insufficient review discipline for AI code | Strengthen review standards and QA |
| Low satisfaction + strong DORA numbers | Unsustainable pace, on-call overload | Redistribute load, adjust expectations |
| Slow onboarding + poor documentation | Platform and knowledge-sharing gap | Invest in docs and onboarding tooling |
| Rising cycle time + single reviewer bottleneck | Missing senior capacity | Hire or redistribute review authority |
When the Numbers Point to a Hiring Problem Instead of a Process Problem
Not every productivity metric problem has a process solution. Some patterns only resolve when you add the right people to the team. The challenge is telling the difference, because hiring when you actually have a workflow problem wastes money, and optimizing processes when you are genuinely understaffed burns out the people you already have.
Signals of Understaffing, Missing Seniority, and Review Bottlenecks
Look for these specific patterns in your metrics:
- PR review turnaround time is climbing, and one or two people review 70%+ of all PRs. This is not a process problem. You do not have enough qualified reviewers.
- Cycle time is rising, but individual coding time is stable. Work sits in queue, not in progress. The team produces code at the same rate but cannot move it through review and deployment fast enough.
- On-call load concentrates on 2–3 engineers because no one else has the system knowledge to handle incidents. You are missing depth, not process.
- Onboarding time for new hires exceeds 60 days, and documentation quality is low. The team is too stretched to invest in the knowledge infrastructure that would help new people ramp up.
- Technical debt keeps growing despite being prioritized in planning. The team acknowledges the debt but never has capacity to address it because feature work consumes all available bandwidth.
How to Separate Skill Gaps From Workflow Gaps
A workflow gap means the team has the right skills but the wrong process. Signs include inconsistent CI pipelines across services, unclear code ownership, or manual deployment steps that could be automated. Tooling and process changes fix these.
A skill gap means the team literally lacks the expertise to do certain work well. Signs include architecture decisions that repeatedly create scaling problems, security reviews that miss critical vulnerabilities, or infrastructure work that gets deprioritized because no one on the team has SRE depth. No amount of process improvement fills a skill gap.
Ask this question: If you gave this team an extra 2 hours per day of uninterrupted time, would the problem be resolved? If yes, it’s a workflow issue. If the answer is “they still wouldn’t know how to design that system correctly,” you have a hiring problem.
What Engineering Leaders Should Fix Before They Hire
Before opening a req, confirm you’ve addressed:
- CI/CD pipeline speed: If builds take 30+ minutes, fix that first. Slow pipelines waste every engineer’s time.
- Code review process clarity: Define who reviews what, set SLAs for review turnaround, and distribute the review load.
- On-call rotation fairness: Spread the burden. If two people carry the team’s on-call, that’s a management decision to fix, not a headcount problem.
- Documentation and onboarding: If your last three hires took months to become productive, investing in docs and onboarding tooling may yield more than adding a fourth hire into the same broken ramp.
If you’ve fixed these and your metrics still show rising lead times, bottlenecked reviews, and missing expertise, the data is clear: you need to hire.
Frequently Asked Questions
What is developer productivity?
Developer productivity is how effectively an engineering team turns effort into reliable, valuable software, not how much code one person writes. The most useful measures combine delivery speed (DORA), developer experience (SPACE), and business impact rather than relying on a single output number like commits or lines of code.
How do you measure developer productivity?
Combine DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service) with SPACE dimensions (satisfaction, performance, activity, communication, efficiency). Track DORA weekly at the team level and SPACE quarterly through surveys and retros, and never use either to rank individuals.
What are the DORA metrics?
DORA metrics are delivery performance indicators developed by Google’s DevOps Research and Assessment team: deployment frequency, lead time for changes, change failure rate, and time to restore service. They measure how fast and safely a team ships code to production, not individual output.
What is the SPACE framework?
SPACE stands for Satisfaction, Performance, Activity, Communication, and Efficiency. It complements DORA by capturing burnout risk, collaboration health, and flow state, the human factors that pure delivery metrics can miss entirely.
Are lines of code a good developer productivity metric?
No. Lines of code rewards verbosity and penalizes the work senior engineers should be doing, like simplifying architecture and reducing technical debt. Most engineering organizations dropped it years ago in favor of DORA and SPACE.
How has AI changed developer productivity metrics?
AI coding assistants have inflated commit counts and PR volume without a proportional increase in shipped value. DORA’s 2025 research found that AI adoption raises both throughput and delivery instability, meaning change failure rate and review turnaround now matter more than raw deployment speed.
Should developer productivity metrics be used to rank individual developers?
No. Metrics like commit count, PR volume, and story points encourage gaming and erode trust when tied to individual performance reviews. Use DORA and SPACE at the team level, and reserve individual conversations for qualitative feedback.
How do I know if low productivity is a hiring problem, not a process problem?
If review turnaround keeps climbing, on-call load concentrates on two or three engineers, or onboarding regularly takes more than 60 days, you likely have a capacity or skill gap that no amount of process tooling will fix.
How Arc Helps Close the Gap
When your developer productivity metrics point to a genuine capacity or skill gap rather than a fixable process issue, the priority shifts to finding the right person quickly.
Arc is a vetted marketplace for remote developers and other technical roles, screened for both domain expertise and English communication skills. The HireAI tool instantly matches your team with pre-vetted candidates, skipping the manual resume screening that engineering leaders rarely have bandwidth for while also managing a velocity problem.
Teams using Arc can fill roles in as little as 14 days, drawing from a global pool of over 450,000 vetted professionals across 190 countries.
If your metrics indicate a capacity gap, explore Arc’s vetted developer talent pool today.
