Developer Productivity Vocabulary: DORA, SPACE, and DevEx in English
Learn the English vocabulary for discussing developer productivity — DORA metrics, the SPACE framework, DevEx concepts like cognitive load and flow state.
Developer productivity is one of the most discussed topics in modern engineering organisations. Three frameworks dominate the conversation: DORA (delivery performance), SPACE (a multidimensional model of productivity), and DevEx (developer experience). This guide gives you the vocabulary to participate in these conversations fluently in English.
The SPACE Framework
SPACE stands for Satisfaction, Performance, Activity, Communication/Collaboration, and Efficiency. It was developed by researchers at GitHub, Microsoft, and academia to provide a richer picture of developer productivity than metrics alone.
| Dimension | What it measures | Example metric |
|---|---|---|
| Satisfaction | How developers feel about their work and tools | Survey: “I have the tools I need to do my job well.” |
| Performance | Quality and outcomes of work | Code review turnaround time, defect escape rate |
| Activity | Volume of actions taken | Pull requests merged, deployments, incidents responded to |
| Communication/Collaboration | How well developers share knowledge and work together | PR review participation, documentation contributions |
| Efficiency | Ability to complete work with minimal friction | Build time, pipeline wait time, environment setup time |
SPACE Vocabulary in Sentences
- “Our SPACE survey results show high satisfaction scores but low efficiency ratings — engineers feel effective but report that the build pipeline is a significant source of friction.”
- “We’re tracking PR review turnaround time as our performance indicator for Q2.”
Developer Experience (DevEx) Vocabulary
DevEx refers to the experience developers have when working with systems, tools, and processes. A good developer experience reduces friction and supports productivity.
| Term | Definition |
|---|---|
| Cognitive load | The mental effort required to understand and work with a system or codebase |
| Flow state | A state of deep focus and productivity where a developer is working without interruption |
| Friction | Any obstacle or unnecessary effort in a developer’s workflow |
| Toil | Repetitive, manual, automatable work that doesn’t add long-term value |
| Inner loop | The fast feedback cycle of writing code, running tests, and iterating locally |
| Outer loop | The slower cycle of committing, CI/CD, and deploying |
| Developer portal | A centralised platform for accessing tools, documentation, and internal services |
Cognitive Load in Practice
Cognitive load is a concept borrowed from psychology. In software engineering, high cognitive load means developers need to hold too many things in mind at once — understanding the code, the system architecture, the deployment process, and the business rules simultaneously.
Phrases:
- “The service has high cognitive load — the configuration is spread across six different files with no central documentation.”
- “One of our goals this half is to reduce cognitive load for new starters by improving the onboarding documentation.”
Discussing Developer Productivity in Surveys and Reports
When writing surveys or reports about developer productivity, use precise, neutral language. Avoid framing that implies productivity is solely the developer’s responsibility.
Survey question examples:
- “How satisfied are you with the speed of our CI/CD pipeline? (1 = Very slow, 5 = Very fast)”
- “How often does context switching prevent you from reaching a flow state during your working day?”
- “Do you feel you have sufficient time to address technical debt in your team’s codebase?”
Report language:
- “45% of respondents cited slow build times as the primary source of friction in their daily workflow.”
- “Engineers in the platform team reported higher cognitive load than those in product teams, likely due to the breadth of systems they are responsible for.”
- “Flow state interruptions were cited most frequently in teams that share on-call responsibilities with product engineers.”
Toil Vocabulary
“Toil” is a term popularised by Google’s SRE (Site Reliability Engineering) practice. It describes work that is:
- Manual — requires human intervention
- Repetitive — performed frequently in the same way
- Automatable — could, in principle, be done by a machine
- Tactical — solves an immediate problem without long-term benefit
“We spend roughly four hours per week on toil related to manual environment provisioning — automating this is on the Q3 roadmap.”
Example Sentences
- “The inner loop on this project is painfully slow — local test runs take 12 minutes, which completely breaks flow state.”
- “Our SPACE survey revealed that communication and collaboration scores dropped significantly after the team moved to fully remote working.”
- “Reducing toil is a core objective for the platform team this half — our target is to automate all routine environment provisioning tasks.”
- “High cognitive load in the monolith is making it difficult to onboard new engineers — we’re investing in better architecture documentation as a first step.”
- “The developer portal centralises access to all internal tools and runbooks, which we expect will reduce friction and improve efficiency scores in the next SPACE survey.”