Developer productivity is a complex subject connected to many metrics and engineering processes. Its importance concerning the success of a software company is unquestionable. That’s why describing, managing, and tracking it is necessary, as it helps engineering leaders make the software development process more efficient. But quantifying it can be intimidating. But don’t worry; we’re here to help!

That’s where the SPACE Framework comes in. Instead of relying on one magic metric to quantify productivity, SPACE takes a holistic approach by looking at 5 dimensions that contribute to productivity. So if developer productivity is a mountain, the SPACE framework is the sherpa that will guide you through it.

In this blog post, we’ll jump into the world of the SPACE framework and show you how to implement it effectively for your engineering org.

Ready? Let’s start climbing!

What is the SPACE Framework?

The SPACE Framework is a methodical approach to understanding and enhancing developer productivity. Its findings were published in the research paper titled “The Space of Developer Productivity.”

The main idea behind the research is that productivity cannot be measured with a single conventional metric like cycle time, number of bugs or lines of code written. Rather, to completely understand the concept, it’s essential to consider multiple factors that affect productivity.

That’s why the SPACE Framework goes beyond DORA metrics to give a more comprehensive and accurate picture. It breaks down developer productivity into five parts: Satisfaction and Well-being; Performance; Activity; Communication and Collaboration; and Efficiency and Flow.

Satisfaction and well-being

“Satisfaction is how fulfilled developers feel with their work, team, tools, or culture; well-being is how healthy and happy they are, and how their work impacts it.”

Studies have shown how employee satisfaction and productivity are interconnected. When people feel positive about what they do and the environment they work in, it is more likely that they’ll achieve higher productivity. On the off-hand, if workers feel unhappy at their job, they won’t perform well.

The same holds true in the world of software development. Burnout can be pretty common for software engineers due to heavy workloads, understaffing, long roadmaps, and other reasons. In fact, according to Haystack Analytics, 83% of software developers feel burnout due to their work, and 81% mentioned feeling more burnt out due to the COVID-19 pandemic.

These problems are a huge roadblock to the productivity of the organization as well as the health of employees. That is precisely why the satisfaction and well-being aspect of the SPACE framework focuses on the necessity to assess how team members feel about their workplace if they feel efficient or are on the brink of burnout, and if they have the necessary tools to get the work done.

The study encourages organizations to conduct frequent employee surveys to determine how satisfied software engineers are with their work and team. With the data collected from these surveys, you can get a clear idea about any existing problems engineers face in their day-to-day lives, identify areas of dissatisfaction that might lead to burnout, and create effective strategies to counter these pain points.

Performance

“Performance is the outcome of a system or process.”

Quantifying software engineering performance is quite difficult. So is establishing a connection between individual efforts to larger business outcomes.

According to the study, merely writing code quickly doesn’t necessarily lead to high-quality code. High-quality code doesn’t mean you’re delivering customer value. Features loved by customers are not always positive for the business. Even if you could tie a single developer’s contribution to business outcomes, it isn’t always an accurate reflection of performance because maybe the developer might be working on a less impactful task. Moreover, software is written mainly by teams rather than individuals.

Because of these problems, the creators of the SPACE Framework for developer productivity suggest evaluating developer performance based on outcomes rather than outputs.

It means that instead of assessing developers on the amount of code they’ve written, it’s better to evaluate based on whether the code reliably does what it was meant to do. Some metrics that can help capture this dimension are:

• Defect Rate and Change Failure Rate
• PR Throughput
• Customer Satisfaction
• Reliability

Activity

“Activity is a count of actions or outputs completed in the course of performing work.”

Measuring developer activity can offer valuable (yet limited) insights into engineer productivity and system efficiency. However, in reality, it can be challenging to get an accurate picture of developer activity because all of it can’t be quantified, like attending meetings, brainstorming sessions, or helping a fellow developer. While a little challenging to measure (though not impossible), these activities are integral to a developer’s job.

But if you have a well-instrumented engineering system in place, you can capture activity metrics throughout every touchpoint in the software development life cycle to assess developer productivity at scale. These metrics can include:

• Pull requests, commits, and code review
• Number of incidents and alerts
• Number of deployments and releases
• Number  of design documents
  

Communication and collaboration

“Communication and collaboration capture how people and teams communicate and work together.”

Teamwork makes the dream work. In fact, teams who communicate effectively can increase their productivity by up to 25%.

Software development is no different. It is a collaborative process involving extensive communication, collaboration, and coordination between team members. The hallmarks of highly effective teams are transparency, awareness of teammates’ activities, discoverability of necessary documentation, and alignment with team and business goals. Needless to say, the importance of communication and collaboration for developer productivity can’t be dismissed. Teams that can do so efficiently are more likely to solve problems faster, choose better alternatives, and brainstorm new ideas more successfully.

But how do you measure something invisible? While communication and collaboration can’t be measured directly, you can use these metrics as proxies:

• Quality of work reviews
• Discoverability of documentation
• Team health checks
• Network data that reflect interconnected elements
• Onboarding times for new developers

Tracking these metrics can help you identify whether your team prioritizes healthy communication and collaboration.

Efficiency and flow

“Efficiency and flow capture the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system.”

In the SPACE framework, flow means a zone of individual efficiency where work can be done promptly and with minimal interruption. It is a state of mind where a worker is fully immersed in the job at hand. When developers are “in the zone,” they can be incredibly productive. To gauge flow, you can look at these components:

• Ability to stay in flow and complete work
• Timing and frequency of interruptions

Efficiency, on the other hand, is mapped on a system and team level. It includes the steps required to take software from idea to execution to the end customer. You can calculate efficiency through several metrics collected from multiple stages in your workflow. Some example metrics are:

• Number of handoffs in your process
• Change lead time and time to recovery
• Time measures (total time, wait time, value-added time)

How to implement the SPACE Framework?

No matter the size or nature of your team, it’s worthwhile to give SPACE a shot. By implementing it at individual, team, and organizational levels, you can derive insights into engineering productivity. However, remember that it’s important that you tailor the metrics according to your team and organization’s specific needs.

With that in mind, here are some general guidelines engineering leaders can keep in mind when using the SPACE framework:

Be transparent

Introducing metrics in a new setting is always challenging, and, naturally, some people might be apprehensive about the change and have questions. That’s why transparency is crucial when introducing SPACE into your organization.

You should keep an open communication channel and address any doubts raised by your team. More importantly, it’s best if you convey that the goal of introducing the SPACE framework is for the overall benefit of everyone in the organization and not to keep an eye on developers.

Pick the Right Metrics

The originators of the SPACE framework emphasize the importance of using several metrics across the dimensions to understand developer productivity. But they also warn against the pitfalls you might encounter if you go overboard and end up picking too many metrics.

You know the saying that too many cooks can spoil the broth? Well, the idiom extends to SPACE as well. That’s why the researchers advise against measuring all five dimensions at once and recommend picking up a minimum of three that make the most sense for your business.

Look at metrics contextually

Quantitative data won’t give you the full picture so it’s better to pair them with qualitative information to get the full picture.

Doing so helps you get a well-rounded sense of your dev team’s productivity and you avoid falling into the trap of half-truths and unwarranted conclusions. Aside from high-quality quantifiable metrics, engineering managers should capture qualitative data through surveys, meetings, and feedback forms.

Ensure data accuracy

Accuracy isn’t just important in a math exam — it’s also relevant in getting an authentic glimpse into your organization’s productivity. To do so, it’s essential to capture information correctly and consistently.

You should create a process to instrument data capture across all activities in the engineering life cycle and create a system to check for accuracy across multiple data sources like source code, project management, incident management tools, and more. Although some teams do this internally, a better alternative might be to use specialized tools like DevDynamics to do this.

Roll out slowly

Instead of going beast mode, it’s best to test the waters by gradually introducing the model to only select teams. Onboarding a few teams is the best way to maximize the chances of success. As an engineering leader, you should educate them on the advantages of tracking engineering productivity and get them excited about implementing the metrics into their day-to-day work. You are also more likely to gain critical insights at this level.

Ultimately, your aim is to show teams that the SPACE framework is beneficial for improving the software engineering process. Then, when you experience success, you should share your progress organization-wide to generate interest and get other teams on board.

Conclusion

There are countless metrics in software development. The SPACE framework, on the other hand, gives you a clear and comprehensive view of developer productivity. It gives you the right metrics to make data-driven decisions that boost team productivity and result in positive business outcomes.