Developer Productivity Vocabulary: DORA, SPACE, and DevEx in English

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

1. “The inner loop on this project is painfully slow — local test runs take 12 minutes, which completely breaks flow state.”
2. “Our SPACE survey revealed that communication and collaboration scores dropped significantly after the team moved to fully remote working.”
3. “Reducing toil is a core objective for the platform team this half — our target is to automate all routine environment provisioning tasks.”
4. “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.”
5. “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.”

In Practice: Navigating Nuance – Common Phrases & Their Subtle Meanings

For non-native speakers, understanding the precise way these terms are used in a professional setting can be incredibly challenging. It’s not just about knowing the definitions of “DORA” or “SPACE”; it’s about grasping the subtle nuances and expectations around communication. Let’s look at some common phrases you might encounter and how they differ slightly depending on context.

One frequent issue is the use of “technical debt.” While seemingly straightforward, it’s often layered with unspoken implications. Saying “We need to reduce technical debt” can sound accusatory if not carefully framed. A better approach would be: “Let’s prioritize refactoring this module to improve maintainability and reduce potential future risks – addressing some areas where our current implementation isn’t as flexible as it could be.” Similarly, “moving the needle” doesn’t simply mean achieving a small improvement; it implies a significant impact on a key metric. A developer might say, “This change has moved the needle on deployment frequency,” indicating a noticeable and positive shift in their workflow. Another phrase to watch out for is “blue sky thinking.” While brainstorming new ideas can be valuable, consistently suggesting radical, unfeasible solutions without grounding them in reality can quickly become frustrating for your team. Instead of proposing a completely new database technology, you could say, “Let’s explore how we might optimize our existing PostgreSQL setup – perhaps by reviewing indexing strategies or query performance.”

Furthermore, the language used during code reviews is particularly important. Receiving feedback like “This needs to be more readable” isn’t necessarily criticism of your coding style; it’s a request for clarification and potentially a suggestion that you could improve the structure or add comments to enhance understanding for others (and yourself in the future!). Phrases like “it’s not immediately obvious” are often used to politely highlight areas needing further explanation.

Finally, be mindful of your tone when discussing metrics. Saying “We’re failing on our DORA metrics” can feel demoralizing. A more constructive approach would be: “Let’s analyze these metrics together to identify the root causes and develop strategies for improvement – perhaps focusing on reducing cycle time or increasing deployment frequency.”

Here’s an example of how you might use git to demonstrate a change that’s moving the needle in terms of code review turnaround time, specifically using the git diff command:

git diff --stat HEAD^..HEAD

This command shows the changes made between the previous commit (HEAD^) and the current commit (HEAD). The --stat option provides a summary of these changes (lines added, lines deleted) which can be helpful in quickly communicating the scope of the work to a reviewer. It’s a simple tool, but demonstrating an understanding of how to use it – and explain why you used it - showcases your professionalism.