Productivity Engineering Glossary
Clear definitions for the terms we use across Spotlight on Productivity Engineering. Start with the foundation: What Is Productivity Engineering?
Jump to: Core concepts · Metrics & frameworks · Delivery flow · Technical debt · People & team health · AI & productivity
Core concepts
Productivity engineering
Productivity engineering is the discipline of systematically improving how an engineering organization delivers software, by measuring and removing friction in tooling, processes, and team health rather than pressuring individuals to work harder. It treats productivity as a property of the system, not of people. Full explanation: What Is Productivity Engineering?
Developer productivity engineering (DPE)
Developer productivity engineering is the practice of improving developer effectiveness by optimizing the tools and feedback loops developers touch every day - builds, tests, local environments, and CI. DPE is the tooling-centric subset of productivity engineering; the broader discipline also covers process, measurement strategy, and team health.
Developer experience (DevEx)
Developer experience is the sum of friction a developer encounters getting work done: build speed, review latency, documentation quality, tool reliability, and cognitive load. Poor DevEx rarely appears in delivery dashboards directly - it shows up later as attrition and slow onboarding.
Platform engineering
Platform engineering is the practice of building internal platforms, shared infrastructure, golden paths, and self-service tooling, that let product teams ship without reinventing deployment, observability, or security. It is one of the highest-leverage tools of productivity engineering.
Internal developer platform (IDP)
An internal developer platform is the concrete product of platform engineering: a curated layer of self-service capabilities (environments, pipelines, scaffolding, service catalogs) that standardizes how software gets built and shipped inside an organization.
Goodhart's Law
Goodhart's Law states that when a measure becomes a target, it ceases to be a good measure. It is the central failure mode of productivity measurement: any single metric used to judge people will be gamed. The defense is balanced metric sets used to improve systems, not to rank individuals - see Beyond Lines of Code.
Metrics & frameworks
DORA metrics
DORA metrics are four measures of software delivery performance from the DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. Together they balance speed against stability, which is why they resist gaming better than any single metric.
SPACE framework
The SPACE framework measures developer productivity across five dimensions, Satisfaction, Performance, Activity, Communication, and Efficiency, on the principle that no single metric can capture productivity. Its key contribution is legitimizing human measures (satisfaction, wellbeing) alongside system measures.
DevSat (developer satisfaction score)
DevSat is a structured survey score measuring how satisfied engineers are with their tools, processes, and working conditions. It captures what dashboards can't: two teams can post identical delivery numbers while one thrives and one burns out. How to build one: Psychological Productivity Engineering.
Engineering allocation
Engineering allocation is the breakdown of where engineering capacity actually goes - new features, maintenance, tech debt, incidents, support. It answers the business question behind all productivity work: "what are we getting for our engineering spend?" See Productivity KPIs in SDLC.
Vanity metrics
Vanity metrics are measures that look like productivity but don't correlate with delivered value - lines of code, commit counts, story points closed. They are cheap to collect and dangerous to reward; AI code generation has made them actively misleading.
Delivery flow
Cycle time
Cycle time is the elapsed time from when work starts on a change until it reaches production. It is the single most diagnostic flow metric because it can be decomposed, coding time, review wait, review duration, deploy wait, and each segment points at a specific bottleneck.
Lead time for changes
Lead time for changes is the time from code committed to code running in production, one of the four DORA metrics. Long lead times usually indicate friction in review, testing, or release processes rather than in coding itself.
Deployment frequency
Deployment frequency is how often an organization ships to production. Higher frequency means smaller batches, which means lower risk per release and faster feedback - it's a proxy for the health of the whole delivery system.
Change failure rate
Change failure rate is the percentage of production deployments that cause a failure requiring remediation (hotfix, rollback, patch). It's the stability counterweight to speed metrics: optimizing deployment frequency while ignoring change failure rate just ships bugs faster.
Flow efficiency
Flow efficiency is the ratio of active work time to total elapsed time for a piece of work. Typical values are far lower than teams expect - work spends most of its life waiting (for review, for QA, for deploy windows), which is why fixing queues usually beats making people code faster.
Technical debt
Technical debt
Technical debt is the accumulated cost of past shortcuts and outdated decisions in a codebase - a hidden tax that quietly consumes 25–40% of engineering capacity through slower changes, more defects, and longer onboarding. What it really costs and how to manage it: Tech Debt Explained.
Tech debt ratio
Tech debt ratio is the estimated cost of fixing a codebase's known issues divided by the cost of building it. It turns "our code is bad" into a number that can be tracked over time and traded off against features on the roadmap - see AI-driven technical debt management.
People & team health
Psychological productivity engineering
Psychological productivity engineering is the practice of measuring and improving the human substrate beneath delivery metrics, motivation, safety, sustainable pace, with the same rigor applied to pipelines and tooling. The framework, including a structured survey and DevSat score: Psychological Productivity Engineering: Building a Framework.
Cognitive load
Cognitive load is the total mental effort a developer needs to hold to do their work - codebase complexity, tool sprawl, process overhead, interruptions. High cognitive load is invisible in delivery dashboards but is a leading cause of slow onboarding, defects, and burnout.
AI & productivity
AI impact measurement
AI impact measurement is the practice of assessing what AI coding assistants actually change in engineering output, beyond inflated commit and line counts. Honest measurement tracks downstream effects: review load, rework rate, defect escape, and time-to-value. Why the easy metrics break: How AI Disrupts Productivity Measurements.
AI-assisted development
AI-assisted development is a workflow in which engineers use AI tools to generate, review, and refactor code, shifting the human role toward specification, verification, and orchestration. Enterprise realities and pitfalls: AI Coding Assistants in the Enterprise; where the role is heading: The Future of Software Engineers in the AI Era.
Something missing? Subscribe - the glossary grows with the blog.