TempoUse frameworks as lenses, not scorecards
DORA, SPACE, and developer-experience frameworks answer different questions. DORA focuses on software delivery performance. SPACE protects against reducing productivity to activity. Developer-experience measures help explain the friction behind system outcomes.
A practical measurement system borrows the smallest useful set from each lens. The goal is not framework compliance; it is enough shared evidence to decide what to improve next.
| Lens | What it helps explain | Typical signals |
|---|---|---|
| Delivery performance | How quickly and reliably changes reach users | Deployment frequency, lead time, recovery, failures, deployment rework |
| Flow efficiency | Where work waits inside the development system | PR cycle time, pickup time, review time, WIP age |
| Developer experience | Why developers encounter friction or lose focus | Satisfaction, cognitive load, feedback, local pain points |
| Quality and sustainability | Whether speed creates downstream cost | Rework, incidents, no-review work, maintainability signals |
| Impact | Whether engineering effort advances company priorities | Outcome delivery, investment mix, initiative progress |
A practical starter set for software teams
Begin with six to eight signals that cover the delivery path and the constraints around it. Add a metric only when someone can name the decision it changes and the action available when it moves.
| Metric | What it reveals | Useful companion |
|---|---|---|
| PR cycle time p50 | Typical speed from open to completion | PR size and stage breakdown |
| PR cycle time p90 | The slow tail hidden by the median | Long-lived and blocked PRs |
| Pickup time | How long ready work waits for review | Review ownership and reviewer load |
| Deployment frequency | How often completed changes reach production | Lead time to production |
| Throughput | How much work completes in a period | WIP and scope movement |
| WIP age | How long active work remains unfinished | Stale issues and blockers |
| Developer sentiment | Friction system telemetry cannot explain | Qualitative comments and team context |
| AI adoption rate | Where assistants appear in shipped work | Cycle time, review load, quality constraints |
Operationalize metrics in four steps
Metrics create value only when they enter an improvement loop. Establish a baseline, agree on a question, inspect the work behind the trend, and run one bounded experiment. Keep the measurement window and segmentation stable while the experiment runs.
- Frame the decision: for example, whether review capacity is the main constraint.
- Select one outcome, one leading indicator, and one balancing signal.
- Inspect repository, work-type, and team context before acting.
- Record the intervention and review whether the whole signal set improved.
Avoid measurement patterns that destroy trust
Lines of code, commit counts, tickets closed, and isolated velocity numbers are easy to collect and easy to game. Used as individual targets, they reward visible activity while ignoring complexity, collaboration, quality, and outcomes.
Keep individual drill-downs for investigation and support. Make teams and systems the unit of improvement, explain how every metric will be used, and remove signals that have become performance theater.
- Do not turn one metric into a productivity score.
- Do not compare teams with different missions without context.
- Do not set targets on outcomes a team cannot directly control.
- Do not interpret a correlation as proof that a tool caused the change.
How Tempo approaches developer productivity
Tempo combines GitHub delivery metadata with Jira or Linear work histories and optional local AI attribution. It emphasizes flow, work health, and the connection between AI-assisted work and delivery outcomes.
The product keeps contributor detail available for diagnosis while presenting organization and repository trends as system signals. The aim is to help leaders ask a better question, then inspect the evidence behind it.
Frequently asked questions
What are the best developer productivity metrics?
The best set depends on the decision. A practical baseline combines PR cycle time, pickup time, deployment frequency, throughput, WIP age, a quality constraint, and qualitative developer feedback.
Can developer productivity be measured per individual?
Individual data can help investigate workload or support needs, but a single individual productivity score is misleading. Software delivery depends on team topology, systems, collaboration, work type, and outcomes that activity counts cannot capture.
Are DORA metrics developer productivity metrics?
DORA metrics describe software delivery performance. They are an important part of a productivity system, but they do not directly measure developer experience, collaboration, or business impact.
How many productivity metrics should a team track?
Start with six to eight signals tied to one or two decisions. Add more only when the existing set cannot explain a recurring question and someone owns the response.
Sources and further reading
- SPACE: A framework for developer productivityThe original research arguing for multidimensional productivity measurement.
- DORA software delivery performance guidanceDefinitions and interpretation of delivery performance metrics.