Jossie Haines has spent 22+ years as a software engineering leader and is an inclusive engineering leadership and executive coach. She was most recently the VP of Software Engineering and Head of DEI at Tile, and has held management roles at Apple, Tile, Zynga, and American Express. As a coach, Jossie empowers technology leaders to build diverse, inclusive teams that drive innovation by leveraging empathy and compassion. She has given over 100 talks, workshops, and podcasts on topics such as retaining women in tech and engineering leadership.

Developer productivity is always top of mind for software engineering leaders. However, industry trends like "quiet quitting" and mass layoffs have created even more urgency around leveling up team performance.

As a leadership coach, my goal is to help software engineering leaders make teams more productive. I have found that the best and most sustainable approach is to build inclusion.

On an inclusive team, every person has what they need to thrive. This support is based on recognition and appreciation of everyone's differences.

Major surveys from Wiley and the Kapor Center indicate that lack of inclusion in company culture is one of the top reasons tech workers leave their roles. This is especially true for people from marginalized backgrounds.

My work with engineering leaders supports these findings. Lack of inclusion tends to diminish team productivity in 3 key areas:

1. Engagement

   • Developers disconnect from their work in an unwelcoming environment.

2. Turnover

   • Developers are more likely to leave when they feel unwelcome and unsupported by leadership.

3. Innovation

   • On non-inclusive teams, people from marginalized backgrounds feel less safe sharing their perspectives. This leads to conformity of thought and makes it difficult for teams to generate new, creative ideas. 

It's clear that inclusion is tied to productivity. But how can you assess inclusion on your team, let alone track it over time? The path to implementing new metrics can feel daunting and unclear.

Fortunately, there's no need to reinvent the wheel here. Instead, I advocate for expanding one of the most popular developer productivity frameworks, SPACE, to support your inclusion efforts.

Today we will review each of the 5 SPACE dimensions to discuss how we can embed inclusion in the framework – and in your team culture.

• What is SPACE?
• How can SPACE measure inclusion?
  • Satisfaction and well-being
  • Performance
  • Activity
  • Communication and collaboration
  • Efficiency and flow
• Getting started 

What is SPACE?

The story behind the SPACE framework starts with DORA, a set of 4 metrics designed to measure developer productivity.

Over seven years, the DevOps Research and Assessment (DORA) team conducted surveys exploring the practices, processes, and capabilities that enable "elite" software developer teams. Based on this research, DORA identified 4 metrics that indicate software delivery performance.

1. Deployment frequency
2. Lead time for changes
3. Time to restore service
4. Change failure rate

Despite its popularity, DORA has significant limitations. It is highly output-focused and doesn't paint a full picture of what drives productive teams.

The 2018 book that published these metrics, Accelerate, actually discusses 24 capabilities that we should consider when assessing team productivity. However, most engineering teams focus on the four "north star metrics" above because they are easier to capture.

Eventually, the researchers behind DORA moved towards a more holistic approach to measuring developer productivity. After additional research, this team published the SPACE framework.

SPACE resists the idea that productivity can be measured by team or individual output. It presents a multidimensional framework that managers and developers can use to better understand their work and its impact.

SPACE has enabled developer teams to expand their understanding of the factors driving productivity.

Given the massive impact that inclusion has on team performance, I propose taking SPACE one step further to intentionally embed inclusion in each dimension.

How can SPACE measure inclusion?

Traditionally, SPACE uses 5 dimensions to measure developer productivity. Let's review the dimensions and discuss how we can integrate inclusion into each of them.

Satisfaction and well-being

• Satisfaction: how fulfilled developers feel by their work, team, tools, or culture
• Well-being: how healthy and happy developers are, and how their work impacts it

An inclusive environment has a tremendous impact on developers' satisfaction and well-being. Every team member wants to feel that their opinions are valued and that they are part of a greater company mission.

When I left my role at Apple in 2018, I did not feel this way at all. In fact, I left because of the cumulative toll of gender-based microaggressions – what I call death by a thousand papercuts. This experience is all too common for tech workers from marginalized backgrounds. Over time, it erodes team morale, leads to burnout, and pushes great developers out of tech.

To understand how inclusion impacts developers' satisfaction and well-being, give team members opportunities to share their experiences. As part of SPACE, you can expand self-reported surveys to ask about your team's experiences of inclusion. 

Performance

• Performance: the outcome of a system or process

Often when we discuss performance, we think about quality: to what extent does each developer's work positively impact the product? As part of this question, I encourage engineering leaders to ask: how does inclusion impact the quality of developers' work?

The reality is that performance isn't just about volume. You can produce 20,000 lines of code, but that doesn't mean much if the work isn't high-quality. An effective team creates value for customers and a strong foundation that others can build on in the future.

How does inclusion come into play here?

As we discussed in the previous section, a lack of satisfaction and well-being diminishes developer motivation and performance. However, we also want to consider how an inclusive mindset helps us deliver value to customers.

Here's an example. Recently I was washing my hands in an airport bathroom in Tampa. As I lathered up, I saw a Black woman wave her hands under the automatic soap dispenser. She tried over and over, but the sensor did not respond. The woman remarked that this has happened to her countless times, and asked a white woman to try waving her hands under the dispenser. This time, it worked perfectly.

While I had a positive experience with the soap dispenser, it's clearly not a quality product for everyone. That's why it's so important to challenge our idea of "product success." Are developers delivering value to all customers, or just a select few? Asking this question will help your team build a more inclusive mindset – and better products.

Activity

• Activity: a count of actions or outputs completed in the course of performing work

This dimension focuses heavily on operational activities, such as code reviews and documentation. Common metrics include "volume of code reviewed" and "number of documents written." A key limitation of these metrics is that they fail to capture how operational activities impact employee experience.

For example, code reviewers don't always consider their tone when writing feedback. Instead of approaching feedback from a place of open curiosity, code reviewers may pose questions in an accusatory manner: "Why did/ didn't you do this?" This approach undermines developer confidence and psychological safety on your team.

Of course, there is value in tracking "volume of code reviewed." But if your high volume of feedback is delivered without empathy, it may do more harm than good. Pairing quantitative metrics with qualitative metrics, such as "use of empathetic language," can give you a fuller picture of your operational activities and their impact on the team.

Collaboration and communication

• Collaboration and communication: how people and teams share information and work together

In an ideal work environment, all team members feel comfortable adding to discussions, asking for help, and partnering with colleagues to achieve shared goals. However, power dynamics related to factors like race and gender can prevent some team members from feeling included. 

We often see these dynamics play out in brainstorming sessions. For instance, are you hearing from the same few people over and over again? If so, you are missing out on perspectives that could benefit your product.

Efficiency and flow

• Efficiency and flow: ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system

Lack of inclusion is detrimental to efficiency and flow for two key reasons:

1. Anxiety in the workplace makes it difficult to get into a productive flow.

When team members don't feel that their opinions are valued, they are more likely to lose confidence and second-guess their opinions. Those nagging voices in the back of your head can get in the way of productive work time and discourage creativity.

2. In a non-inclusive environment, team members are less likely to feel comfortable setting boundaries that benefit their work.

For instance, let's say a manager urgently pings one of their developers at 5pm. The developer is busy trying to take care of their kids and plans to catch up on messages in the morning. However, the developer doesn't feel comfortable letting their manager know that they will respond later. This request ultimately disrupts the developer's routines and makes it more difficult for them to do their work effectively.

Getting started

In my experience as an executive coach, most software engineering leaders want team members to feel a sense of safety and belonging. The challenge is knowing where to begin. I have written extensively about best practices for building a more inclusive culture on software engineering teams. But today we are focusing on the very first step: gathering data.

SPACE has incredible potential to jumpstart your inclusion efforts. Expanding the 5 dimensions is a much easier lift than implementing a new system. In addition, the holistic nature of SPACE makes it a natural fit with the qualitative metrics we've discussed today.

Of course, every organization and team is different, and I encourage you to take this context into account as you define your metrics. The data you gather will help you to implement and refine inclusive management practices that make your teams more productive.