Beyond agency, motivation, and learning, a sense of support and belonging shouldn’t be overlooked as a key driver of developer thriving.
What are some of the things that create long-lasting and high quality code in the world? Perhaps it’s certain software practices, cutting-edge tooling, and sophisticated approaches to error management, risk protection, and security. But that risks overlooking a key finding of our research: that developers report writing better code, making better decisions, and ultimately feeling more productive when they have a strong sense of belonging inside of their organizations.
At Pluralsight Flow’s 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. I have already written about the importance of developer agency, motivation and self efficacy, and building a learning culture. Now we will tackle the final factor we measured towards Developer Thriving: support and belonging.
A scientific approach to measuring belonging
To measure support and belonging, 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 we have already discussed, developers’ scores on support and belonging significantly predicted how productive those developers reported being.
Belonging is an example of a metacognitive belief. This is 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 skill sets 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 would argue against feeling supported in the workplace being a good thing. But even when we agree that belonging is important, we often struggle to create it on our teams. To understand why, we conducted in-depth qualitative interviews. One developer told us that they “feel safe when ideas and contributions are valued equally, whether it’s an architect, someone that’s been at the company for 15 years and built the whole thing, or an intern that just started.”
Many developers also acknowledge 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. In an industry that continues to struggle with creating inclusive organizations, fostering belonging is even more vital.
How can we raise belonging for our engineering organizations?
Many of the software developers who participated in our research shared experiences of adversity, feelings of imposterism, and exclusion. These 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.
This can only be mitigated 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, saying, “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 speaks up for you in order to help you find your path.”
This is a great example of a “microinclusion”. These are small but powerful actions that demonstrate a positive stance towards another person and show them that we value their contribution. In a recent large scientific paper comprising four different research studies, the researchers 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. This is the fear and anxiety that underrepresented and marginalized people can experience when worrying about whether others are seeing them through the distorted filter of a stereotype.
Microinclusions are particularly powerful because they can change the way that we experience ambiguous moments, or times where we are trying to decide if 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 they can really succeed there.
Leaders should take this impact seriously. One of the reasons that we believe support and belonging to be so powerfully predictive of developers’ productivity is that this fundamental experience of belonging can either unlock or block many of the behaviors that allow developers to solve difficult problems together.
For example, a developer who feels like they are 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 reported high levels of stress and anxiety in our research.
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. Inclusive hiring practices also deeply impact belonging, and engineering organizations should pride themselves on accessible, equitable hiring experiences that allow everyone with the chance to succeed.
This may mean 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.
