How and Why to Measure Engineering Productivity
From DORA, SPACE, DevEx and QUANTS to the internal T-Meter
Slide contents
1. How and Why to Measure Engineering Productivity
From DORA, SPACE, DevEx and QUANTS to the internal T-Meter
2. Alexander Polomodov
Alexander Polomodov, Technical Director & Fellow, large fintech
Architecture and development processes
An engineering organisation of about 10,000
The internal T-Meter platform
3. Name the type of work first
Run — Stable operational work
Change — Product delivery and development
Disrupt — New products and models
4. Metrics moved beyond output
5. 01. DORA reads delivery
Delivery tempo and stability form one system
6. Speed cannot leave stability behind
7. The core model connects capabilities
Technical capabilities
Process capabilities
Culture and wellbeing
Delivery and operational performance
8. One metric is never enough
9. Friction appears in three places
10. Surveys and telemetry answer differently
Survey
Perception
Cognitive load
Satisfaction
Systems
Cycle time
Review wait
Context switching
11. First ask whether to measure
12. Platforms choose a measurement school
Surveys
DevEx 360
DX Core 4
Satisfaction and flow
Telemetry
Cortex scorecards
Code Climate
Pluralsight Flow
13. 02. T-Meter reads workflow
A templated Jira model becomes team and portfolio dashboards
14. Two depths reveal different problems
15. A KPI turns measure into target
Do not rank people
Do not copy thresholds across teams
Read trend and context
Adopt bottom-up
16. Productivity needs several lenses
Define the work type
Join tempo and stability
Add perception
Read flow at two levels
Never turn metrics into KPIs
Measurement should support improvement
17. Four frameworks, one context
Accelerate + DORA
SPACE framework
DevEx framework
Google QUANTS + GSM
18. Thank you!
tellmeabout.tech
Slides, notes and links are on the site
Alexander Polomodov, Technical Director & Fellow, large fintech
@book_cube