Developer Experience and Productivity Metrics

In this illustrative situation, a platform team is asked to show that the platform is working. Someone builds a dashboard: commits per developer per week, pull requests merged, story points completed. It is precise, it updates nightly, and within a month two teams have split their commits to look busier while a third stops volunteering for code reviews because reviews are not on the chart. Nobody lied and nobody is better off.

The SPACE paper explains why activity counts alone cannot distinguish useful work from effort spent overcoming poor systems or planning. Reviews, mentoring, and coordination may improve other people’s work without raising the contributor’s count. An activity dashboard needs that context before it can support a decision.

DORA, SPACE, and DevEx offer complementary perspectives on delivery, productivity, and lived experience. Use them to investigate work and outcomes rather than reducing people to a score. This article concentrates on platform improvement; it distinguishes organization-level reporting from voluntary personal analysis and explains how to combine operational evidence with user perceptions.

What activity counts leave out

SPACE identifies recurring misconceptions about productivity. Their consequences explain why a broader set of evidence is needed.

• Activity does not establish value. A high count may reflect effective work or extra effort caused by poor tools and planning. Missing events and inconsistent definitions can also distort the count.
• Individual output does not capture team contribution. Reviews, on-call work, and shared engineering improvements can help a team while taking time away from one person’s implementation tasks.
• One metric cannot represent productivity. Different measures reveal different aspects of work, and each depends on its context.
• Measurement can help developers themselves. SPACE allows voluntary personal analysis to understand work patterns and manage energy. That use differs from management ranking people by activity.
• Tools are only part of the environment. Goals, culture, mentoring, and knowledge sharing affect what people can accomplish. Some of that work is difficult to count automatically.

A platform team therefore needs evidence about the work its users can complete, the effort involved, and the outcomes of that work. Reducing avoidable friction is one improvement objective, not a complete definition of productivity or customer value.

Three frameworks, three questions

Framework	The question it answers	What it will not do
DORA (five delivery metrics)	How well does our delivery system move changes to production, and how stable are they?	Tell you why, or how the work feels
SPACE (five dimensions)	Which aspects of productivity should our measures cover?	Supply one fixed metric set that fits every situation
DevEx (three dimensions)	What friction are developers actually experiencing?	Summarize into a score you can compare across companies

Use delivery results to locate changes in the service, SPACE to check the breadth of the evidence, and DevEx to examine users’ experience. The frameworks overlap, but none makes the other measures or investigation unnecessary.

DORA’s current delivery metrics

DORA’s January 2026 guide uses five metrics grouped into throughput and instability. Failed deployment recovery time has a narrower event population than all-cause recovery time. Preserve the published definitions while documenting how events are identified in your service.

• Change lead time — elapsed time from committing a change to version control through its deployment in production.
• Deployment frequency — deployments per defined period, or the interval between successive deployments.
• Failed deployment recovery time — recovery duration following a failed deployment that needs immediate intervention.
• Change fail rate — the share of deployments followed by immediate intervention, commonly a rollback or hotfix.
• Deployment rework rate — the share of deployments that are unplanned responses to production incidents.

DORA reports that high-performing teams tend to combine delivery speed and stability. This supports improving both over time; it does not prove that every local control has no delay cost or that faster delivery causes greater stability. The measures are outcomes of delivery practices and signals associated with organizational performance. DORA metrics explains their event boundaries and interpretation.

DORA recommends measuring one application or service at a time. A fleet average can move because the service mix changed even when no service improved. Assign ownership for interpreting the aggregate and retain the service-level evidence.

That is an argument about how to aggregate, not a prohibition on aggregating. If you do report a fleet number, report what it is made of: which services are in the population, whether each counts once or is weighted by deployments, and the distribution rather than only the mean — a median that improves while the slowest quartile gets worse is a finding, and an average hides it. And check the composition before attributing a change to your work, because onboarding twenty fast-moving services improves the average without improving anything.

DORA’s guidance also identifies ways that measurement can undermine improvement.

• Broad quotas. Requiring every application to deploy several times a day can reward moving a count rather than delivering useful changes.
• A single favored metric. A balanced set should expose important costs or outcomes that the favored metric misses.
• Disparate comparisons. Different release constraints and workloads can make a mobile application and a mainframe service unsuitable for a shared ranking.
• Siloed ownership. Assigning speed to one group and stability to another can encourage each to transfer costs to the other.
• Competition instead of learning. Compare a service’s results over time and investigate context before making cross-team claims.
• Measurement that delays action. A conversation or initial assessment may be enough to choose a useful experiment before building precise integrations.

DORA recommends establishing a baseline with the cross-functional team, discussing a significant constraint, making a change, and checking the result. Small batches are one candidate for improving feedback and recovery. Choose an intervention from the observed constraint rather than assuming batch size is always the problem.

SPACE: covering different aspects of work

SPACE organizes productivity into dimensions. Its recommendations help teams choose measures that answer different questions instead of collecting several versions of the same activity count.

Dimension	What it covers	A caution from the paper
Satisfaction and well-being	How people experience their work, tools, team, and health	Satisfaction is associated with productivity; it is not proof of a particular intervention’s effect
Performance	Outcomes of a system or process	Code volume, quality, and customer value are different things
Activity	Actions or outputs produced during work	Coverage is incomplete and context is necessary
Communication and collaboration	How people work together	Much useful coordination is difficult to observe automatically
Efficiency and flow	Progress through work with fewer unnecessary delays and interruptions	Protecting one person’s focus can delay someone else’s work

The authors recommend a small set spanning at least three SPACE dimensions and including perceptual evidence, such as survey responses. Choose the measures for the decisions they will inform. Adding pull-request counts to commit counts broadens activity coverage but does not necessarily add another dimension.

Measures can expose competing outcomes without moving in opposite directions. Faster delivery and fewer failures may improve together. The purpose of a balanced set is to notice when an intervention helps one outcome and harms another. Several measures can still be distorted together, so inspect their definitions, underlying events, and relationship to the intended result.

What leaders measure communicates what they value. SPACE illustrates how rewarding story points alone can discourage collaboration and other less visible work. Include evidence about the outcomes and relationships that matter rather than making the easiest count the incentive.

More measures also create interpretation and collection work. A proxy has limits: retention can reflect compensation, promotion, family circumstances, or restrictions on transfers, as well as satisfaction. Survey responses can have different cultural or linguistic baselines. Record these limitations before comparing results, and avoid raw-score rankings across incomparable populations.

DevEx: waiting, mental load, and being interrupted

The DevEx framework examines how developers experience their work through feedback loops, cognitive load, and flow state. These are perspectives on experience, not three defects to eliminate. Developer experience includes both tools and the social conditions in which work happens.

Feedback loops concern the speed and usefulness of responses from tools and people. A fast test result with an unintelligible error can still block work. Build, test, and environment delays may interrupt progress, while review or approval queues can do the same through human handoffs. Investigate both the response and the waiting that preceded it. Backlog coupling describes the scheduling dependency when one team’s progress requires work in another team’s queue.

Cognitive load is the mental processing required for a task, including understanding the problem, learning, and navigating tools. Reduce unnecessary complexity and overload while preserving the knowledge users need to make decisions and operate their part. Clear code, documentation, and supported platform paths can help; fewer concepts alone does not establish that a task is safer or easier.

Flow state is a psychological state of absorbed focus, involvement, and enjoyment. Uninterrupted time can support it but does not establish that it occurred. Delays, unclear goals, limited autonomy, and the fit between a task and a person’s skills can affect the experience. Shorter waits may reduce disruptive context switching; measure that effect rather than adding an assumed productivity multiplier to every minute saved.

DevEx concerns social conditions as well as tools. Its authors distinguish broadly shared problems from concerns specific to a team or role. Scope helps identify who should coordinate an investigation, but it does not establish the cause or repair owner. A common build delay can arise from application test design; a problem reported by one team can come from a shared platform defect.

So read the spread as a routing signal: how widely something is felt tells you what level should coordinate the response, and the investigation tells you what to change and who can change it. The useful pair of questions is where the cause lives and who holds the authority to alter it, which are frequently different people. And separate not leading from not helping — a platform team that cannot fix a single team’s local problem can often tell them what the data shows, hand over a diagnostic, or remove the constraint that makes their fix expensive.

Break down results where the task, role, or experience differs. A company average can be useful for a defined question, but it can conceal a small group facing a serious problem. Retain enough context to interpret the distribution while protecting respondents’ identities.

Perception is data, not decoration

The DevEx paper uses contrasting examples to show why perceptions and workflow observations belong together.

A short review turnaround can coexist with disruptive interruptions, while satisfaction with a build process can coexist with avoidable waiting. Neither finding establishes its cause. Ask about the experience, inspect the workflow, and test the suspected explanation.

A perceptual measure captures reported attitudes or experience. It contributes evidence that task timestamps cannot fully supply. System observations add different evidence about duration, failures, and behavior. The two should inform each other rather than form a fixed hierarchy.

The authors also note concern about misuse of metrics. Explain how responses will be used and connect the analysis to users’ work. Asking questions alone does not protect trust if the results are later repurposed for ranking.

Start with evidence you can obtain responsibly. A short, tested survey may establish an initial view while integrations are built; existing telemetry may answer another question sooner. Question design, recruitment, classification, data validation, and analysis all take work. The CNCF white paper recommends gathering useful feedback with a suitably small initial effort.

Keep broader outcomes in view while improving individual factors. The DevEx paper recommends overall indicators such as perceived ease of delivery, satisfaction, or engagement alongside specific workflow measures. Where the question concerns customer value or business performance, include evidence for that outcome rather than treating reduced friction as its substitute.

Running a survey people answer twice

The DevEx authors offer survey recommendations based on their work with organizations. Adapt them to the population, question, and decisions you can act on.

• Test the questions. Define the construct, wording, response scale, and recall period, then check interpretation with intended respondents. Keep core trend items stable where useful. If a question is misleading or the subject changes, version the revision and validate continuity or establish a new baseline; a new question can still provide valuable cross-sectional evidence.
• Analyze relevant groups safely. Roles and tasks may have different experiences. Before collection, explain the purpose, access permissions, and reporting level. Combine or suppress groups small enough to identify people, and inspect cross-tabulations and free text for disclosure risks. Set a reporting policy appropriate to the population; removing names alone does not make a small group anonymous.
• Use comparable benchmarks. Check constructs, wording, scales, recall periods, roles, work, and response composition before comparing. Cultural or language differences can make raw scores unsuitable for ranking. A benchmark adds context; a failed task or a credible complaint does not need an external comparator to merit investigation.
• Sample relevant touchpoints. Transactional surveys can examine an installation error, a completed setup, a support interaction, or another defined event. State who was eligible and sampled. A survey triggered only by failures describes that experience, not all users’ experience.
• Budget for participation and follow-up. Frequency, length, timing, relevance, and visible decisions all affect response. The authors suggest quarterly or semiannual surveys for many organizations, with more frequent collection useful in some settings. Choose cadence from change rate, respondent burden, and the capacity to interpret and act on results.

Close the feedback loop through review, a decision and its reasons, and follow-up on the outcome. An accepted change may lead to design work and release; a justified deferral, rejection, or explanation of an existing capability can also be useful. State when the decision will be reconsidered. The CNCF maturity model describes disengagement when users cannot see how feedback was considered.

A falling response rate is a question to investigate, not proof that follow-up failed. Record invitations, timing, survey length, relevant work conditions, and response composition. Seek voluntary views about participation through a separate route without linking anonymous answers to identifiable people. Even stable response rates can conceal nonresponse bias.

Coverage needs checking in telemetry too. The maturity model gives an example in which automated collection covered only Java applications. Missing groups limit representativeness, while dropped events, sampling, inconsistent clocks, and collection errors can limit completeness and accuracy even within an instrumented group.

What these numbers are not for

Specify the purpose and audience before collecting data. Organization-level improvement, personal reflection, and performance assessment are different uses with different evidence requirements.

SPACE warns against using activity alone to judge individual or team productivity. Reviews, mentoring, architectural guidance, and incident work contribute in ways a count can miss. Evaluate relevant outcomes in context rather than treating output volume as their equivalent.

DORA directs attention to improving a service over time. Shared delivery measures help development and operations investigate the same system; team rankings without comparable context encourage competition over the numbers.

For organizational reporting, SPACE recommends anonymized group results. It also allows developers to opt into analysis of their own work patterns. A private personal chart used to manage focus is different from a management league table. Keep participation and access explicit, and do not present an activity dashboard as a complete individual performance assessment.

A starter set for a platform team

Choose a small set for the current improvement question. The examples below can cover satisfaction, performance, and efficiency in SPACE when defined as shown. DevEx’s three dimensions are a separate framework; asking one question per DevEx dimension does not automatically cover three SPACE dimensions.

Candidate	Definition and scope	Question and SPACE dimension
Change lead time	Commit-to-production time for one service, with consistent events and population	Where does delivery take time? Efficiency and flow
Change fail rate	Share of deployments requiring immediate intervention under a stated rule	Did delivery reliability change? Performance; interpret alongside lead time without assuming either prevents manipulation of the other
A targeted experience question	For example, perceived disruption from review waits over a stated period	How does the workflow affect progress? Efficiency and flow; questions about satisfaction may instead address satisfaction and well-being
Overall developer satisfaction	A tested question for a defined user group and period	How do users evaluate their work experience? Satisfaction and well-being; broader than one platform capability

Platform-specific candidates include request-to-fulfillment time, time to a usable new service, and time to a new user’s first relevant change. The CNCF white paper lists such organizational-efficiency signals. Choose the supported task and role, start and completion events, permission prerequisites, and observation period. Submission, merge, and production deployment are different boundaries. Separate approvals from execution and include unfinished or failed attempts where relevant. A golden path tutorial’s step count is a clue shaped by writing granularity; compare effort, waiting, success, and rework as well. Support volume needs task and cohort context, a suitable denominator, and effort per request. Recurring questions can reveal toil or legitimate learning and judgment needs. These are optional candidates, not an instruction to append every metric to the starter set. For each chosen measure, name a collection owner, cadence, cost, and decision it informs.

Distinguish delivery of the internal developer platform itself from delivery by its consumers. DORA’s platform guidance calls for both views and notes that favorable experience can coexist with weaker delivery outcomes. A change that improves satisfaction while increasing lead time requires interpretation, not an automatic declaration of success or failure.

Choose the intended outcome first, then evidence that can indicate progress and important side effects. A usage measure describes adoption under its stated population and choices; a time-saved estimate needs a credible comparison. The maturity model encourages moving from feature measurements toward explicitly chosen outcomes.

Turning evidence into an improvement

Begin with a feasible instrument, then investigate a candidate problem. Prioritize using impact, frequency, exposed population, risk, change authority, and improvement cost; the largest reported inconvenience need not be the most valuable intervention. Concentrate new instrumentation on the hypothesis while retaining relevant reliability, support, collaboration, and outcome checks. Make a change, observe it, and explain the result or decision to users.

Stable wording helps comparison but does not control the respondent mix. Consider an illustrative five-point question: one group averages 2 and another 4, with neither changing. An 80:20 response mix yields 2.4; a later 20:80 mix yields 3.6. The apparent gain of 1.2 points comes entirely from composition. This arithmetic is an example, not a reported study.

Record the eligible and invited populations, response counts, period, and relevant work context. Examine safe group summaries and changes within groups, including roles, tenure, and who did not respond. Repeated cross-sectional surveys need not involve the same individuals, but comparable wording and broad group labels alone do not remove selection bias. If an item changes, validate its connection to the earlier measure or report a new baseline. A before-and-after observation shows a change after an intervention; without stronger design it does not establish that the intervention caused it.

Avoid a single composite score presented as a complete account of productivity. Preserve the distinctions needed to interpret each measure, and make the consequences of comparisons and targets explicit.

• Comparison. Use comparable history or appropriately matched benchmarks to learn. Investigate differences in work, definitions, and populations before drawing conclusions. Ranking unlike teams or withholding attention from a problem because peers report it too defeats that purpose.
• Targets. A service can set an improvement goal while watching relevant consequences. Lead time and failure rate are useful together, but neither guarantees detection of gaming. Inspect definitions, event samples, and user outcomes when numbers improve without a corresponding change in the work.

Agree these uses and boundaries before launching the dashboard. Changing incentives after people have organized their work around a score is harder than designing the interpretation with them at the start.

A platform team should be able to explain what changed in users’ work, which evidence supports that conclusion, and what remains uncertain. Feedback loops, cognitive load, and flow state help locate experience problems; toil can affect all three through recurring effort, waiting, and interruption. Combine perceptions with observations and the outcomes the service exists to support. Treating the platform as a product provides the continuing responsibility to investigate, decide, and learn from those results.

References

• Forsgren et al. — The SPACE of Developer Productivity, Communications of the ACM 64(6), 2021, pp. 46–53
• Noda, Storey, Forsgren, and Greiler — DevEx: What Actually Drives Productivity, ACM Queue 21(2), 2023
• DORA — Software delivery performance metrics (January 5, 2026)
• DORA — Platform engineering
• CNCF TAG App Delivery — Platforms White Paper
• CNCF — Platform Engineering Maturity Model