Calculate engineering productivity from throughput, cycle time and output metrics.
This DORA-inspired composite blends five signals often correlated with healthy, sustainable engineering velocity: PR throughput (25%), PR review turnaround time (20%), PR size (20%, rewarding small reviewable changes), deployment frequency (25%, mirroring DORA's own key metric), and on-call interrupt load (10%, penalizing teams whose planned work is constantly derailed). Each sub-score is normalized 0-100 against common industry reference points before weighting, and the total maps to Elite (85+), High (70+), Medium (50+) or Low (<50).
productivity_score = pr_throughput_score × 0.25 + review_time_score × 0.20 + pr_size_score × 0.20 + deploy_frequency_score × 0.25 + oncall_load_score × 0.10
Research on code review consistently shows smaller PRs get reviewed faster, more thoroughly, and ship with fewer defects than large PRs — this score treats ~200 lines or fewer as ideal and penalizes size growth beyond that as a proxy for reviewability, not raw output.
Not unconditionally — this model caps both scores at reference points (30 PRs/week, daily deploys) considered strong-but-sustainable benchmarks, rather than rewarding unbounded throughput that could reflect low-quality, rushed work rather than genuine productivity.
Frequent on-call interruptions fragment focus time and divert engineers from planned work, which is a real (if indirect) drag on delivery — including it nudges teams to treat operational load as a first-class productivity concern, not just a reliability one.
No — treat it as a complementary, easy-to-read team health signal. Formal DORA reporting (deployment frequency, lead time, change failure rate, MTTR) should still be tracked individually for deeper investigation.