DORA and SPACE are the two frameworks worth knowing for engineering productivity. DORA measures delivery system performance through four metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. SPACE measures developer productivity multi-dimensionally — satisfaction, performance, activity, communication and efficiency — and argues no single metric can capture it.
Both were designed for teams and systems, not for ranking individuals. That distinction is the whole point, and it's the one most often lost when these get adopted.
DORA: the four delivery metrics
Emerging from the DevOps Research and Assessment program and popularised by Accelerate, DORA identifies four measures that correlate with high-performing delivery organisations:
| Metric | What it measures | What it exposes |
|---|---|---|
| Deployment frequency | How often you ship to production | Batch size, release friction |
| Lead time for changes | Commit → running in production | Pipeline and review bottlenecks |
| Change failure rate | % of deploys causing incidents | Testing and review quality |
| Time to restore service | Incident → recovery | Observability, rollback ability |
The elegance is the pairing: the first two measure speed, the last two measure stability. Optimising one pair alone is easy and useless — you can ship constantly by skipping tests, or achieve near-zero failures by shipping quarterly. Progress means moving both together.
Where DORA breaks down: it's blind to everything upstream of the commit. A team with excellent DORA numbers can still be miserable, drowning in meetings, working weekends, or building the wrong thing entirely. It also fits poorly outside continuously-deployed services — embedded, data, and ML teams often need adapted definitions.
SPACE: five dimensions
SPACE (Forsgren, Storey et al.) responds directly to the "one metric" problem. Its five dimensions:
- S — Satisfaction and well-being. How fulfilled and healthy developers are. A leading indicator: satisfaction usually drops before delivery does.
- P — Performance. Outcomes of the work — reliability, quality, impact — not output volume.
- A — Activity. Counts of actions: commits, PRs, deploys. Useful context, dangerous alone.
- C — Communication and collaboration. How work and knowledge flow, including review latency and discoverability.
- E — Efficiency and flow. Ability to work with minimal interruption and handoffs.
The framework's central instruction: pick metrics from at least three dimensions, and never rely on activity alone. Combining an outcome measure, an experience measure and a flow measure makes gaming much harder, because improving the composite requires actually improving the work.
Combining them in practice
A workable starter set for most teams:
- All four DORA metrics — delivery system health, from your CI/CD and incident tooling.
- A satisfaction signal — a short recurring pulse survey. Three honest questions beat a twenty-question annual survey.
- A flow signal — focus time and meeting load, which is where activity analytics contributes something surveys and pipelines can't.
That combination covers outcome (DORA), experience (satisfaction) and conditions (flow) — SPACE's three-dimension rule, without a measurement bureaucracy.
Where activity data helps — and where it doesn't
Activity data earns its place on the E dimension. Pipeline metrics can't see that your platform team lost 40% of its focus time to an interrupt rota, or that meeting load doubled after a reorg. Those are the conditions that produce DORA numbers, and they're invisible in DORA itself.
What activity data must not do is become a proxy for performance. Hours active, keystrokes and commit counts are the classic mistake — see focus time vs active hours and how to track employee productivity for the fuller method.
Rolling this out without losing the room
Engineers are, correctly, the most sceptical audience for productivity measurement — they've usually seen it done badly.
- Say what decision it informs. "Deciding whether to hire or fix our meeting load" is legitimate; "visibility" is not.
- Rule out individual scoring in writing, and mean it.
- Give engineers the data first. Teams that see their own numbers before management does tend to fix problems unprompted.
- Review as a team. Metrics in a retro produce action; metrics in a 1:1 produce defensiveness.
Where ProdView fits
ProdView contributes the flow and conditions layer: focus time, meeting load, capacity distribution and after-hours creep, from activity and app metadata — never screen content, never keystrokes, screenshots off by default, and engineers seeing the same dashboard managers do. One Rust agent runs natively on Linux alongside Windows and macOS, which matters for engineering fleets. SOC 2 Type II, $4.99/user/month, free for 3 seats.
When not to pick us: you want DORA metrics themselves — those come from your CI/CD and incident tooling, and a dedicated engineering-intelligence platform is the right home for them. We're complementary, not a replacement.
Try before you commit
Baseline focus time and meeting load for four weeks alongside your existing DORA numbers, then see which explains more of your delivery variance. Three seats are free — or model the payback with the ROI calculator.