Developers and the organizations they work for are always searching for ways to improve productivity. However, most strategies leave a lot to be desired. Learn why developers prefer the SPACE framework for tracking and improving productivity.
Here is a fun fact for you:
According to the SEO software Moz, the monthly search volume of the word "productivity" in the United States is between 11,500 - 30,300.
So, assuming 20,000 people searched for "productivity" in August, it means that every day in August, at least 600 people were looking up the word "productivity." Not to mention the tons of related searches like "productivity apps," "productivity formulas," and other forms of queries around the term that would cumulatively amount to at least 3,225 searches daily.
Sounds like a lot? Well, it is.
The truth is, although humankind has constantly sought ways to maximize efficiency while increasing impact, productivity can still be notoriously tricky to define—and measure.
This is particularly true for developers. When it comes to developer productivity, the benefits can scale exponentially.
For this cause, having a practical productivity framework is instrumental to providing team leaders, managers, developer supervisors, and developers themselves with the ability to improve performance and effectiveness.
It also explains why many developers have switched to using the SPACE framework, which will be covered in this article.
Too often, developer productivity gets over-simplified to a few easy-to-understand but potentially flawed metrics, creating tension between team leaders and their developer team.
Here’s what I mean.
Many developer productivity frameworks and tools can sometimes feel linear and narrow, giving off an A-B or robotic dynamic.
For example, these narrow productivity tools may come in the form of engineer intelligence tools that push managers to determine their developers' productivity by measuring how many times they write documentation, analyze code, send inputs, pull tickets, etc., or track how much time they spend doing those things.
But, in reality, those approaches and tools don't do justice to the complexities of their jobs. These tools tend to focus on output in a one-size-fits-all manner rather than drilling down on developer productivity in a more meaningful (human) way, essentially doing the developers no favor.
Eirini Kalliamvakou, a senior researcher at GitHub, expressed similar sentiments when she said:
This is where the SPACE framework comes in for many developers and their managers.
The SPACE framework is one that encapsulates and measures organizational, team, and developer productivity in a multidimensional and holistic manner. It was the result of collaborative efforts from researchers at GitHub, the University of Victoria, and Microsoft.
In many ways, the SPACE framework is a pivotal scheme for engineering teams, validating that one cannot just look at telemetry data or a set of universal metrics to determine and measure productivity.
Before now, some of the worst metrics have been used in the software development world, with engineering managers determining output via imprecise and impractical metrics like lines of code. Of course, it’s part of the process, but from a candid viewpoint, a line of code that doesn't fix a problem is as good as a non-existent one, maybe worse. Not to mention that it does no favor to the organization's wallet; a developer paid for every line of code can (deftly) earn just about any sum without providing actual value.
Measuring productivity in terms of KPI calls, bugs fixed, ticket closes, the number of mouse clicks, etc., is just as inefficient since developers can find ways around those situations. A developer with a bug count, for example, can choose to formulate software with bugs, then create fixes to meet that bug count. Besides, can any developer really do excellent work under these prying conditions?
Of course, this is not to say productivity shouldn't be mentioned. Choosing not to measure productivity at all is quite frankly a recipe for disaster.
Thus, because of the narrowness of these existing frameworks (or the lack thereof), there arose a need for a framework that thought about developer productivity in a very inclusive way and functioned as a balance between measuring way too much and not measuring nearly enough.
The SPACE framework presents five dimensions to measuring productivity:
S - Satisfaction and wellbeing
P - Performance
A - Activity
C - Communication and collaboration
E - Efficiency and flow
Note that the SPACE productivity framework provides a way to think about productivity in a much more nuanced sense and choose metrics carefully that reveal not only what they (the metrics) mean but also their limitations if used alone or in the wrong context.
Engineering management has since evolved from a focus on simply delivering software faster or compelling engineers to produce more output to aligning teams with the organization's direction, making conscious improvements, and representing engineering on the organization's executive team (as an essential decision-maker).
Modern engineering management helps engineering teams and individual engineers succeed in a complex business enterprise setting.
Broadly speaking, the role of engineering managers can be split into 3 categories:
Why is this vital information?
Because as an engineering manager, your productivity metrics must cut across all three categories. This is where SPACE comes in again.
The SPACE framework is an excellent option as it allows you to use several metrics along its five dimensions (Satisfaction, Performance, Activity, Communication and Collaboration, and Efficiency) while aligning with the core categories of engineering management.
Let's see how.
Engineering execution encompasses all deliverables (products and services) and the process (level of efficiency, quality, and duration of release). Satisfaction, Activity, Communication, and Collaboration are the SPACE dimensions that align with this category.
People management encompasses engineers' training, development, motivation, and day-to-day management. Satisfaction, Communication, and Collaboration are the SPACE dimensions that align with this category.
Business alignment occurs when all activities of the engineering team fit and complement the organization's core goals. Performance is the SPACE dimension that aligns with this category.
You can find some examples of metrics that capture these dimensions in the original publication.
Business alignment is the only engineering management practice covered by one SPACE dimension (Performance).
Its implication? If you ignore Performance, you would be disregarding arguably the most critical dimension of the SPACE framework for your organization and missing out on a crucial piece of engineering management.
The Performance dimension determines the return on the organization's investments (both human and otherwise) and gauges the extent to which the organization's goals are achieved—business alignment.
Engineering and development teams have been trailblazers of tech-centralized work dynamics that use sophisticated work methods. Now, as the world progress, engineering teams have an advantage in leveraging this expertise to rebuild productivity, growth, and innovation—the first step being changing how engineer and developer productivity is measured by adopting the SPACE framework.
This is where Scatterspoke comes in.
We use AI to intelligently combine SPACE (qualitative and quantitative) metrics from development teams to help them track and understand developer productivity. We also help analyze their organizations’ goals and the journey to those goals, in addition to identifying potential problems.
The result is that teams have all the context and know what needs to change. We empower teams (not managers or leadership) to set their own goals within the SPACE framework, putting them in the driver’s seat to get more done.
What can you actually do to make effective retro a reality? The good news is, it’s not as difficult as you might think. We’ve broken it down into 5 elements to make it as easy as possible to massively improve your sprint retrospectives.
Most engineering managers instinctively think of productivity as complex processes like workflows, solutions, and deliverables expressed in purely quantitative terms. The result is a dynamic that’s usually counterproductive. But there is another way.
Often that dynamic plays out in metrics and misguided attempts at fostering engineer productivity, usually by measuring the wrong things and offering the wrong incentives. Fortunately, there are better ways to use metrics to genuinely empower engineers to accomplish more.