Support & Belonging: a final key to Developer Thriving

What are some of the things that create long-lasting and high quality code in the world? When we talk about this in tech, we might talk about favorite software practices, cutting-edge tooling, and sophisticated approaches to error management, risk protection and security. But one piece might be a surprise: developers report writing better code, making better decisions with software, and ultimately feeling more productive when they have a strong sense of belonging inside of their organizations. 

At Pluralsight Developer Success Lab, we study how the most innovative software teams work, learn, and thrive. We recently asked more than 1,200 developers about how they felt their teams were doing on four key factors that measure what we call Developer Thriving. In my first articles, I share about Developer Agency, Motivation & Self Efficacy, and Learning Culture. In this article, we’ll tackle the final factor in Developer Thriving which we measured on software teams: Support & Belonging.

In our Support and Belonging measure, we asked developers whether their teams celebrated them, allowed them to grow, and were supportive when they made mistakes. We also asked developers whether they felt that they belonged on their teams and in their orgs as a whole person, with all their identities and different experiences. Along with the other factors in Developer Thriving, developers’ scores on Support and Belonging significantly predicted how productive those developers reported being. 

We believe belonging is a critical piece of developers’ experience inside of their organizations because it taps into the expectation that a developer has about whether people “like me” can succeed where they are right now. Belonging is an example of a metacognitive belief; an internal model of the world that we use to guide our decisions and behavior. Belonging can include interpersonal warmth–for example, teammates who notice and amplify your contributions during a meeting, or provide space for you when you share something difficult–but it can also include careful evaluations of whether your skillsets and way of thinking belong in your role, team, and type of work.

Social science has measured Belonging across large numbers of people and contexts and found that improving this factor can be a powerful lever for helping more people succeed. One large-scale study across 22 universities with more than 26,000 students found that strengthening students’ beliefs about their belonging with an intervention actually helped to raise tangible performance outcomes like grades, and was particularly powerful for historically underrepresented students. 

Few developers would argue that feeling supported is a good thing. But even when we agree that belonging is important, we often struggle to create it on our teams. To hear more about why, we also conducted in-depth qualitative interviews along with our quantitative research in our Developer Thriving research. One developer told us...

But many developers acknowledged that technical teams can have a culture that rewards posturing, where learning is seen as remedial, and where junior colleagues can feel afraid to speak up. And in an industry that continues to struggle with creating inclusive organizations, fostering belonging is even more vital.

We all know the world isn’t perfect. Many of the software developers who participate in our research share experiences of adversity, feelings of imposterism, and exclusion. These deep experiences have a profound impact on developers as human beings and can also have a profound impact on the way that we build software in the world. What can we do? 

One way that developers can help to mitigate this is by cultivating a strong supportive culture inside of their teams. Think local–find small, actionable steps to celebrate, affirm, and show others their contributions matter. Practice asking your colleagues more questions about why they did something a certain way, and what kind of help they need from you. Be mindful of making assumptions when you’re surprised by someone working differently, and bring curiosity and respect to technical dialogue. Practice being generous about praising and noticing someone else’s work, and do it in public. 

A developer in our research highlighted the powerful impact of this sponsorship and support, especially for developers seeking recognition of their technical contributions: “You find that across lines of gender, race, age, just difference, that some folks [don’t have] a fair shot. Sometimes it's harder [to get recognition or visibility] if you're from a certain demographic versus others….I think it's very important that somebody speak of you in order to help you in your path.”

This is a great example of a “microinclusion”: a small but powerful action that demonstrates a positive stance towards another person in our environment, and tells them that we value their contribution. In a recent large scientific paper publishing four different research studies, Muragishi et al. found that microinclusions can increase people’s belief that they fit in a technology company, increase their commitment to an organization, and even reduce negative experiences such as stereotype threat. 

Microinclusions are particularly powerful because they can change the way that we experience ambiguous moments–times we are trying to decide whether or not we can belong to a new group. This might look like a developer joining a new team, but it also might look like a developer trying a new skill at work, or taking on a new initiative with cross-functional partners. And where developers encounter environments that do not have examples of different types of people and backgrounds succeeding and being celebrated for technical contributions, this prompts questions about whether someone “like me” can really succeed here.

Leaders should take this impact seriously. One of the reasons that we believe Support and Belonging is so powerfully predictive of developers’ productivity is that this fundamental experience of belonging can either unlock–or block–many of the behaviors that allow us to solve difficult problems together. For example, a developer who feels like someone like them is more likely to be criticized may hold back from pointing out a security risk they notice. A developer who feels their hard work is unlikely to be celebrated by their teammates may decide that their team is inherently competitive, and be less likely to help others. Belonging matters because it impacts developers’ wellbeing, but it also matters to the bottom line because it changes what developers see as possible inside of their team environments. 

To understand what developers are experiencing, leaders should think deeper than just measuring “engagement,” and consider asking how supported developers feel in their daily experiences by the rest of their team and organization. Leaders should also affirm belonging among engineering managers, who often report high levels of stress and anxiety in our research. For example, cohort-based peer groups for managers can be an important source of feedback and community.

On the structural side, businesses should commit to both listening and caring about whether their engineering organizations have a strong supportive culture, and taking active steps to build a belonging culture. Engineering organizations can run specific surveys about developer experience, and commit to real action based on the feedback and ideas from developers (no one wants to take a survey that doesn’t lead to action!).

 Inclusive hiring practices also deeply impact belonging, and engineering organizations should pride themselves on accessible, equitable hiring experiences that allow all the chance to succeed–for example, thinking critically about ensuring job requirements do not select for a single school or background, and designing technical interviews with developer wellbeing in mind. This strengthens belonging not only for candidates, but for the engineers already inside of your organization who can see this as proof that inclusivity is valued. 

Organizations can also demonstrate their commitment to a belonging culture by ensuring that they elevate diverse voices in panels, learning events, and high visibility initiatives. Engineering managers can bring attention to their team’s culture of belonging by asking developers what language makes them feel supported, and setting an example of clear policies for support in moments of failure. 

Even though failure, friction, and exclusions are profoundly difficult to experience, the science of belonging says we can do a lot to support each other at work. When we notice and affirm each other’s belonging, we can actually build protective communities that thrive despite the frictions and challenges that we experience.