Knowing what SPACE stands for is a starting point. Knowing how to apply it inside a real engineering organization is where most VPs of Engineering hit friction. This is the operational side: what each dimension looks like in practice, what to measure, and which patterns should prompt a decision.
If you want the full breakdown of the five dimensions and the research behind them, start with Waydev’s guide to the SPACE framework and its metrics. What follows goes further into how you apply those dimensions as a team scales, and how to interpret what you find.
The challenge for an executive overseeing multiple teams is not learning the acronym. It is deciding which signals to act on, recognizing when a data point reflects a structural problem rather than a temporary spike, and avoiding a message to your teams about what you value that you never intended to send. Waydev brings the DORA metrics together with activity and collaboration data, giving VPs of Engineering and CTOs dashboards that surface those signals without manual input from engineers or managers.
SPACE was published in ACM Queue in 2021 by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler. Its central claim is that productivity cannot be reduced to a single dimension or metric.1
The paper is specific about what to do instead. Capture metrics across at least three of the five dimensions, and make sure at least one of them is a perceptual measure such as survey data. Adding pull requests and coding time to a dashboard that already tracks commits does not count, because all three are activity metrics.1
Before the detail, the whole framework in one view: what each dimension answers, and where the answer comes from.
| Dimension | The question it answers | Where you read it | |
|---|---|---|---|
| S | Satisfaction and well-being | Can this team keep working this way | Surveys, retention timing, review and toil distribution |
| P | Performance | Did the work move the product forward | Throughput, DORA metrics, reliability, user feedback |
| A | Activity | Where is the work actually happening | PR and commit reports, activity heatmap, deployment frequency |
| C | Communication and collaboration | Do contributions compound or collide | Review collaboration, integration time, onboarding time |
| E | Efficiency and flow | How smoothly does work move between stages | Lead time, time to restore, interruption patterns |
Scroll the table sideways to see every column.
An early warning system, not a soft metric you check once a year.
Motivation shapes output in ways sprint velocity will never capture. An engineer frustrated by unclear requirements or inadequate tooling still closes tickets. What erodes is the quality of that work and their willingness to stay on the team.
This is also the dimension the original paper insists you cannot skip, since it is where the perceptual measure usually comes from.1 Start with one question: would team members recommend this workplace to peers in their network. Then watch the indirect signals. Engineers consistently working outside normal hours can look highly productive, but the pattern usually means the work does not fit inside a reasonable day, whether because of process friction, tooling gaps, or unclear priorities.
There is no numeric threshold that tells you satisfaction is healthy. The value sits in the trend, and in what your managers hear when they actually ask.
Whether the team’s collective output moved the product forward.
Performance in a software team is almost never about one engineer’s output. A developer writing large volumes of code tells you nothing about whether the sprint delivered user value. Correlating individual commits with a shipped product’s success is rarely possible and rarely useful. What does scale is assessing the team against outcome-level indicators.
The most visible dimension, and the most easily misread.
High commit volume does not make a high performing team. A team deep in design and architecture may show two quiet weeks while doing the work that determines the quality of the next six months. Track activity in a way that accounts for the full scope of daily work, including research, review cycles and meetings, not only the artifacts that happen to be countable.
| Signal | The lazy reading | What it usually means |
|---|---|---|
| Low commit volume | The team is slow | Design, architecture or investigation work that produces few artifacts |
| High commit volume | The team is productive | Small tasks, or one change split across many commits by habit |
| PR open for days | Nobody is working | Reviewer bandwidth, or unclear ownership of the review |
| Low deployment frequency | Slow engineering | Release process overhead sitting between done and shipped |
| Rising after-hours activity | A committed team | Work that no longer fits inside the working day |
Whether individual contributions compound into something coherent.
Two engineers working in parallel on adjacent features without coordinating will create integration debt that takes longer to unwind than the original work took to produce. So what does good collaboration look like in the data?
The structural lever here is creating the conditions for collaboration rather than mandating it. Visibility into each engineer’s current workload and blockers removes most of the coordination overhead that siloed work creates.
How smoothly work moves through your delivery process.
Flow is the state where an engineer is fully focused and making fast progress. It is also fragile. One meeting placed in the middle of a morning turns a three-hour focus window into two unusable blocks.
One caveat. Minimizing interruptions at the individual level can quietly reduce collaboration if you take it too far. An engineer who never attends a design review is highly focused and completely detached from the team’s decisions. The goal is protected focus time inside a structure that keeps people aligned.
SPACE was written before coding assistants were standard equipment, and the shift has made the framework more useful rather than less. The 2025 DORA report, based on responses from nearly 5,000 technology professionals, found that AI functions as an amplifier: strong teams get faster, and teams with weak processes ship weak work faster.2 Ninety percent of respondents now use AI in their daily work, and higher adoption is associated with an increase in both delivery throughput and delivery instability.3
For anyone reading a dashboard, that combination is the whole problem. Activity metrics move up first and most visibly, while the cost lands downstream in review queues, rework and failed changes. A team can look more productive on every countable signal in the same quarter that its quality position gets worse.
Activity is the fastest dimension to improve and the least trustworthy on its own. That was true in 2021 and AI has widened the gap.
DORA also found that AI had no measurable effect on burnout or friction, because both are properties of the system people work inside rather than of the tools on their desk.3 Which is another way of saying that the satisfaction dimension does not get easier to skip just because output went up.
Connect your Git provider and Waydev builds throughput, review collaboration, heatmap and DORA views from your full commit and PR history, alongside AI adoption and impact. No manual logging from engineers.
Request a Free TrialThree dimensions is the floor the research recommends, and one of them has to be perceptual.1 This is a defensible starting set for a first quarter. Add the other two once the first three are being read consistently.
| Dimension | One metric to start | Cadence |
|---|---|---|
| Satisfaction and well-being | A short recurring survey, including whether engineers would recommend the team | Quarterly |
| Efficiency and flow | Lead time for changes, split by stage | Weekly trend, reviewed monthly |
| Communication and collaboration | Share of reviews handled by the top two reviewers | Monthly |
| Add next: Performance | Change failure rate | Monthly |
| Add next: Activity | Time from PR open to first review | Weekly trend |
The question executives face is not which metric to track. It is which combination is telling you something you need to act on right now. These pairings come up most often, and each has a sensible first move.
| Pattern in the data | What it usually means | First move |
|---|---|---|
| Strong activity, low satisfaction | Retention risk. The output is real and someone is absorbing its cost personally | Look at review and toil distribution before you look at capacity |
| High satisfaction, low throughput | A process problem or unclear scope rather than a motivation problem | Map where work waits between stages |
| High throughput, poor user satisfaction | The team is shipping the wrong things, or shipping at a quality level users notice | Review prioritization and change failure rate together |
| Throughput up, change failure rate up | The classic AI-era pattern. Speed arrived before the controls did | Invest in test coverage and review capacity, not more generation |
| Review load on two or three people | Bus factor risk and a morale problem forming at once | Rotate reviewers and set a participation target per team |
| Long lead time, normal commit activity | The bottleneck sits between stages, not inside the coding stage | Time each handoff from ready for review to deployed |
| Rising after-hours activity | The work no longer fits in the day | Check interruption sources and meeting load before adding headcount |
A single week of data rarely tells you anything definitive. A trend across six weeks almost always does.
Scaling an engineering organization is not simply adding headcount. It means preserving the quality of work and the clarity of communication as the number of teams, projects and dependencies grows. SPACE gives you a structure for monitoring that process across dimensions a single velocity chart would miss entirely.
What you choose to measure tells your teams what you value, whether or not you intend it to.
If the only dashboards you review in leadership meetings show commit counts and deployment frequency, engineers will optimize for those signals. If satisfaction data and review collaboration appear in the same reviews, that communicates a different set of expectations about how work should get done.
Teams that adopt SPACE tend to build more durable operating habits than teams measuring throughput alone. The reason is structural. When you track five dimensions, problems invisible to a single-metric view become detectable early.
No, and using it that way breaks it. The dimensions describe a system. Applied to a person, activity metrics reward volume and satisfaction data stops being honest the moment engineers know it feeds a performance review.
At least three dimensions, with at least one perceptual measure, which is the recommendation in the original paper.1 One metric per dimension is enough for a first quarter.
Six weeks of trend is a reasonable floor. A single sprint contains too much noise from holidays, incidents and release timing to support a structural decision.
They answer different questions and work well together. DORA measures delivery outcomes. SPACE adds the context that explains those outcomes, including satisfaction, collaboration and flow. Nicole Forsgren co-authored both.
It holds up better than single-metric approaches, because AI moves activity metrics first and quality metrics later. Reading several dimensions together is what catches the gap.
Knowing which signals matter is half the problem. The other half is surfacing them without asking engineers to log their own work. Waydev pulls activity, throughput, PR collaboration and DORA metrics into one view, so you can review the health of several teams in a single session instead of assembling data from five tools.
The activity heatmap, work log and review collaboration reports map directly onto the SPACE dimensions. You can see where work is flowing, where reviews are bottlenecked, and where teams are carrying uneven loads, without asking anyone to fill out a status update.
Pull metrics from several dimensions when you build your next team health review. A single-dimension view gives you an answer that looks complete and leaves out the context that explains it.
Request a Free TrialConnects to your Git provider and reads your existing history, so the first session shows real numbers.
Ready to unlock your SDLC productivity?
