What This Template Is For
Developer experience (DevEx) is to platform and internal tools teams what user experience is to product teams. It measures how easy, fast, and satisfying it is for engineers to do their daily work. Poor DevEx shows up as slow CI pipelines, confusing documentation, flaky test environments, and tools that require tribal knowledge to operate.
Most organizations measure engineering output (velocity, throughput) but not the friction engineers encounter producing that output. This is like measuring a car's speed without checking if the road is full of potholes. The SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency) provides a structured way to measure DevEx across multiple dimensions.
This template gives you a structured approach to measuring developer experience using surveys, metrics, and friction logs. For tracking the delivery metrics that result from good DevEx, see the delivery metrics template. If you are building internal tools or platforms, the technical PM handbook covers the product management approach to infrastructure work. The DORA metrics glossary entry explains the standard engineering performance benchmarks.
When to Use This Template
- Quarterly DevEx surveys. Run the survey instrument every quarter to track trends in developer satisfaction and identify emerging friction points.
- Platform team planning. Use the friction log and metrics dashboard to prioritize platform team investments for the next quarter.
- Post-migration assessments. After a major infrastructure change (new CI system, monorepo migration, cloud migration), measure the impact on developer workflows.
- Engineering org health checks. Use DevEx data alongside DORA metrics to get a complete picture of engineering effectiveness.
- New tool evaluation. Before and after adopting a new internal tool, measure whether it actually improved the workflows it targeted.
- Onboarding optimization. Track how long it takes new engineers to ship their first PR and where they get stuck.
How to Use This Template
Step 1: Define Your DevEx Dimensions
Start with the SPACE framework dimensions in the template. For each dimension, select 2-3 metrics that are measurable in your organization. Not every metric will be relevant. A 10-person startup measures DevEx differently than a 500-engineer platform.
Step 2: Deploy the Survey Instrument
Send the developer survey to all engineers. Keep it short (5-7 minutes max). Run it quarterly. The survey captures subjective experience that metrics alone miss.
Step 3: Collect System Metrics
Pull objective metrics from your CI/CD system, version control, and deployment tools. These complement the survey by providing concrete data points.
Step 4: Run Friction Logs
Ask 3-5 engineers to record a friction log for one full day. A friction log captures every moment of confusion, waiting, or unnecessary effort. This is the richest qualitative data source for DevEx.
Step 5: Synthesize and Prioritize
Combine survey results, metrics, and friction logs into a DevEx scorecard. Identify the top 3 friction points and create action items for the platform team.
The Template
SPACE Framework Metrics Dashboard
| Dimension | Metric | Current Value | Target | Trend | Data Source |
|---|---|---|---|---|---|
| Satisfaction | Developer satisfaction score (1-10) | Quarterly survey | |||
| Satisfaction | Would recommend our dev environment (NPS) | Quarterly survey | |||
| Performance | P50 CI pipeline duration (minutes) | CI system | |||
| Performance | Deployment success rate (%) | CD system | |||
| Activity | PRs merged per engineer per week | VCS | |||
| Activity | Mean time from PR open to merge (hours) | VCS | |||
| Communication | Code review turnaround time (hours) | VCS | |||
| Communication | % of PRs with review within 4 hours | VCS | |||
| Efficiency | Time to first commit (new engineer, days) | Onboarding tracker | |||
| Efficiency | % of time on toil vs. feature work | Survey / time tracking |
Developer Survey Instrument
Rate each statement from 1 (Strongly Disagree) to 5 (Strongly Agree).
| # | Statement | Score (1-5) |
|---|---|---|
| 1 | I can set up a local development environment in under 30 minutes | |
| 2 | Our CI pipeline gives me fast, reliable feedback on my changes | |
| 3 | I can find the documentation I need without asking someone | |
| 4 | Our testing infrastructure is reliable (tests fail for real reasons, not flakiness) | |
| 5 | I can deploy my changes to production confidently | |
| 6 | Code review turnaround does not block my progress | |
| 7 | Our internal tools are intuitive and well-maintained | |
| 8 | I spend most of my time on meaningful engineering work, not toil | |
| 9 | I can debug production issues without needing tribal knowledge | |
| 10 | I would recommend our engineering environment to a friend |
Open-ended questions:
- What is the single biggest source of friction in your daily workflow?
- What tool or process change would save you the most time each week?
- What was the last thing that made you think "this should not be this hard"?
Friction Log Template
| Time | Activity | Friction Point | Severity (Low/Med/High) | Category | Time Lost (min) |
|---|---|---|---|---|---|
| Tooling / Docs / Process / Infrastructure / Testing |
Instructions for friction log participants:
- Record entries in real-time throughout your workday, not from memory at the end.
- Include the specific context: what you were trying to do, what went wrong, and how you worked around it.
- Estimate time lost including context-switching cost.
- Note whether this is a recurring friction point or a one-time issue.
DevEx Scorecard Summary
| Category | Score (1-10) | Key Issue | Action Item | Owner | Due Date |
|---|---|---|---|---|---|
| Local Development | |||||
| CI/CD Pipeline | |||||
| Testing | |||||
| Documentation | |||||
| Code Review | |||||
| Deployment | |||||
| Observability | |||||
| Onboarding |
Onboarding DevEx Tracker
| Milestone | Target (days) | Actual (days) | Blocker (if any) |
|---|---|---|---|
| Laptop configured with dev tools | 0.5 | ||
| Repository cloned and building locally | 1 | ||
| First PR opened | 3 | ||
| First PR merged to main | 5 | ||
| First production deploy | 10 | ||
| Solo feature shipped (no pairing) | 30 |
Filled Example: Acme Platform Team Q1 Review
SPACE Framework Metrics Dashboard
| Dimension | Metric | Current Value | Target | Trend | Data Source |
|---|---|---|---|---|---|
| Satisfaction | Developer satisfaction score | 6.2 / 10 | 7.5 | Down from 6.8 last quarter | Q1 survey (n=84) |
| Satisfaction | Dev environment NPS | +12 | +30 | Flat | Q1 survey |
| Performance | P50 CI pipeline duration | 18 min | 10 min | Up from 14 min (worse) | GitHub Actions |
| Performance | Deployment success rate | 94% | 99% | Down from 96% | ArgoCD |
| Activity | PRs merged per engineer per week | 4.2 | 5.0 | Stable | GitHub |
| Activity | Mean time PR open to merge | 11.4 hours | 6 hours | Up from 9.2 hours (worse) | GitHub |
| Communication | Code review turnaround | 5.8 hours | 3 hours | Stable | GitHub |
| Communication | % PRs reviewed within 4 hours | 42% | 70% | Down from 48% | GitHub |
| Efficiency | Time to first commit (new eng) | 3.2 days | 1 day | Improved from 4.1 days | Onboarding tracker |
| Efficiency | % time on toil | 31% | 15% | Up from 26% (worse) | Q1 survey |
Top 3 Friction Points from Friction Logs
- CI flakiness (High severity). 4 of 5 friction log participants reported at least one CI failure caused by flaky tests rather than real code issues. Average 22 minutes lost per occurrence. Engineers re-run pipelines 2-3 times per day.
- Documentation gaps for shared libraries (Medium severity). Engineers spend 15-30 minutes searching for usage examples of internal SDK methods. Most resort to reading source code or asking in Slack. The internal docs site has not been updated since the v2 migration.
- Local environment drift (Medium severity). Docker Compose setup breaks every 2-3 weeks due to dependency updates. Engineers lose 30-60 minutes debugging environment issues that are unrelated to their feature work.
DevEx Scorecard Summary
| Category | Score | Key Issue | Action Item | Owner | Due Date |
|---|---|---|---|---|---|
| Local Development | 5 | Docker Compose drift | Implement dev container with pinned versions | Platform | Q2 Sprint 2 |
| CI/CD Pipeline | 4 | Flaky tests, slow builds | Quarantine flaky tests, add build caching | Platform | Q2 Sprint 1 |
| Testing | 5 | Flaky integration tests | Migrate to contract tests for service boundaries | Platform | Q2 Sprint 3 |
| Documentation | 4 | Outdated SDK docs | Establish docs-as-code in SDK repos | Platform + Leads | Q2 Sprint 2 |
| Code Review | 6 | Slow turnaround | Implement review rotation and SLA dashboard | Eng Managers | Q2 Sprint 1 |
| Deployment | 7 | Occasional rollback failures | Add automated rollback validation | Platform | Q2 Sprint 4 |
| Observability | 7 | Dashboard sprawl | Consolidate to standard service dashboard template | Platform | Q2 Sprint 3 |
| Onboarding | 6 | Slow local setup | Dev container + automated setup script | Platform | Q2 Sprint 2 |
Key Takeaways
- Measure DevEx across multiple dimensions (satisfaction, performance, activity, communication, efficiency) using the SPACE framework. No single metric captures the full picture.
- Combine surveys (subjective experience), system metrics (objective data), and friction logs (qualitative detail) for a complete assessment.
- Run friction logs with real engineers for real workdays. They surface problems that surveys and metrics miss entirely.
- Track trends over time, not just snapshots. A CI pipeline going from 10 to 18 minutes over two quarters is a signal even if 18 minutes seems acceptable in isolation.
- Prioritize friction points by frequency multiplied by severity. A medium-severity issue that hits every engineer daily matters more than a high-severity issue that affects one team monthly.
- Connect DevEx improvements to business outcomes. Faster CI means faster iteration. Better docs mean faster onboarding. Frame platform work in terms leadership cares about. The technical PM handbook covers how to build the business case for infrastructure investment.