The SPACE Framework dimensions of developer productivity

How do you measure developer productivity? Well, you can get them to print out all their code and show it to you:

But that’s tough on the environment. You could choose commits, or LoCs, or velocity, or PR merges. But all these are missing something. For one, they all measure activity, and while you want activity, what you really want is directed activity—your team working well together towards a common goal. How do you measure that?

This brings us to the SPACE of developer productivity. The SPACE framework, devised by teams at Microsoft and the University of Victoria, lays out a more complete structure for knowing your development team and how they are working, from the management through to the individual contractors you are working with.

Here we’re going to step through this developer productivity framework, explaining each of the five components and how you can measure them with an emphasis on managing a freelance or contract developer’s performance, so you know how well they’re working with your team.

S.P.A.C.E.

The SPACE framework lays out five components to developer productivity:

1. Satisfaction and well-being

There are two parts to this:

1. Satisfaction is how much the developer enjoys their work, and
2. Well-being is how happy they are.

These might seem odd ones to start with when measuring developer productivity, but the happiness of a developer is critical for their success. A study from Google showed that “job enthusiasm, peer support for new ideas, and receiving useful feedback about job performance” were all predictors of productivity.

In terms of satisfaction, a developer that isn’t fulfilled will quickly become either bored or frustrated. Boredom if the work is too easy for them; frustration if the work is too challenging. Either way, disengagement follows which leads to a decline in productivity. 

Frustration, in particular, is a serious warning sign as it can also have severe consequences for the well-being of the developer. If they are overworked or stressed out from their tasks, this can lead to burnout, after which productivity will plummet.

The good news is that this means you can use signs of dissatisfaction as leading indicators of productivity problems. These are obviously qualitative measures, so the best way to understand satisfaction and well-being is to survey your contract developers on a regular basis. The potential to feel ‘apart’ from the rest of the team and disengaged can be higher with this type of developer, so having some way to check in is important. You might ask them:

• On a scale of 1-10, how satisfied are you with your work?
• On a scale of 1-10, how likely are you to recommend [company] to another developer?
• On a scale of 1-10, how likely are you to work with [company] again?

Each of these will give you an insight into how they are feeling with the possibility of heading off any satisfaction problems early.

2. Performance

The SPACE framework productivity performance component is how the developer contributes to the outcome of the process. The problem with measuring this is that the outcome of the process is, by its nature, the outcome of the team. 

Understanding a single individual’s contribution to this is difficult. This is why Torc is developing applications to measure the performance impact of productive developers.    

There are two parts to analyzing this part of the SPACE framework. Firstly, it’s important to understand what a positive outcome is. From a developer perspective, building a new feature might be a ‘positive outcome,’ but if it doesn’t add to customer satisfaction or retention or revenue, it’s not a positive business outcome. So the onus is on you to make sure goals are clearly defined for everyone on the team.

Secondly, you have to define smaller contributions that add to these positive outcomes. For developers, these might be simple metrics, such as:

• Reliability of code and ability to pass tests consistently.
• Quality of code and the absence of bugs.
• Longevity of code and the ability to write resilient code.
• Ability to pass or perform code reviews quickly and to a high level.

But they could also include more business-centered metrics such as customer satisfaction, retention, cost reduction or revenue.

3. Activity

Activity is the measurement that is ‘easiest’ to understand for developers and engineering managers. Easiest is in quotation marks there because of two subtle issues with measuring developer activity.

1. You can’t measure all activity, and
2. What gets measured gets managed.

These combined can lead to problems for understanding developer productivity. It’s easier to measure commits or lines of code than it is to measure how much time a developer spends helping team members. This means commits or LoCs are more likely to be measured, managed, and used to define productivity.

But it’s also easier to game these, and they are in no way good measurements of the activity of a contract developer, on their own. Instead you want to think about how these activities work alongside the other components of this framework (such as collaboration or performance) and other specific activities such as:

• PRs
• Code reviews
• CI/CD throughput
• Documentation and design volume
• Issue resolution
• On-calls

And these need to be adjusted for contract developers. For instance, it might be company policy not to have contractors work on customer-facing activity. If this is a big part of your productivity and performance measurements, these workers are going to be penalized. Thus, either design your activity measurement around the makeup of your team, or weight these activities less for your contract developers.

4. Communication and collaboration

In the Google study cited above, two of the three factors affecting productivity most were down to collaborating with the team: peer support and receiving useful feedback. Software development is a team game, so communicating well and collaborating to develop the best product for customers is the ultimate outcome.

The best teams embrace an environment where collaboration is foremost. This can be difficult, as collaboration and communication can sometimes be at odds with the last part of the SPACE framework, flow. Meetings and documentation writing feels to a lot of developers like busy work, taking them away from coding. But the reality is that any software developed by more than a single person is the product of collaboration, so these things are a necessity.

They also lessen an individual's work if done right. Good documentation can negate the need for code rewrites; good meetings can negate the need for constant check-ins. Both help reduce load on a developer and avoid burnout.

A good understanding of how well your team works together with contract workers will be a measurement of how quickly they can be onboarded, how quickly they can get up to speed using your documentation, and what they think of code reviews. This all calls back to the S in SPACE–good communication with a freelance developer will be seen in how satisfied they are with their work and how happy they are to work with your team.

5. Efficiency and flow

If you asked any developer what they want from a software organization, it would be the ability to work efficiently, to be able to get in the flow. Heads down, focused work. If managers see productivity through the lens of activity, developers see it through the lens of flow.

Measuring this can be as easy as measuring free time within a calendar. But you also have to factor in all the hidden work that might impact a developer’s efficiency:

• Are they being pinged for code reviews constantly?
• Are they pinged on Slack every hour to answer questions?
• Are there ad-hoc meetings in the middle of the day?

Issues like these interrupt work, interrupt flow, and ultimately delay work and impact productivity. For contract developers, these can impact them significantly as they might have specific time bounds on their contract or specific milestones in their contract. The more interruptions they have, the more difficult it’ll be for them to hit their milestones, the more stressed they’ll get, and we’re right back to the S in SPACE again.

Torc is developing applications that will help organizations identify developers who are out of the desired flow and recommend efficiencies for that individual developer and greater team to bring them back into flow.

A SPACE Odyssey

Here’s a matrix from the Microsoft/Victoria paper to help you understand some of the metrics you can use throughout your software team with the SPACE framework:

‍

The SPACE framework helps you understand how your team is working together on multiple levels. You can see how if you improve one area (e.g. flow), you can have a positive impact elsewhere (e.g. satisfaction). The same goes the other way. If you don’t think about how you collaborate, your activity is going to go down. You’ll also see how team productivity really is a team matter. It’s not just individual contributors that have to increase their activity or performance, the team does, and managers have to build a system that lets this happen.

As you are building out your metrics for the SPACE framework, consider not just the outcome you want from your software development process, but how individuals fit into that. What metrics work for your core team, might not work for contractors. Your goal is to go from business outcome to team productivity to individual performance, making your team a great place to work for everyone, and a place that gets great work done.

If you are seeking to hire developers that operate in a productivity framework such as SPACE, sign up today for your risk-free, 2-week guarantee.