I’ve been reading about role-based belonging. This is a paper I’ve come back to several times in the last few months. I especially like this very clear first paragraph:
As individuals engage with roles—whether starting a new job, entering a new friendship network, or declaring a new major—they ask whether they belong in that specific role: Do I fit here? Belonging is a “general inference, drawn from cues, events, experiences, and relationships, about the quality of fit or potential fit between oneself and a setting” (Walton & Brady, 2017, p. 272). Although who is present in a role is an important cue to belonging, other cues matter as well: What is being done, how it is being done, and why it is being done. Thus, role activities can cue whether an individual belongs or not. We contend that the study of role based belonging—a sense of fit to a particular social role—can expand knowledge about cues to belonging and about the nature of belonging itself.
The what, the how, and the why – that struck me. These are things that matter a lot when we join a new team, they’re things that our new teams are often telling us.
Software teams talk a lot about the what and the how (perhaps not enough about the why). In our research interviews I’ve heard software developers dissect these quiet messages, both together and individually. This is one way that teams pass along beliefs about values, frequently without ever making them explicit. “Here, we practice Agile…” “here, we don’t pair program, because we know the most important thing is focus time…” “Well, the solution you wrote works perhaps, but it’s not how we do things here…” “Here, we use X tool, not that one. We are X tool people!”
I don’t think we always think of these as cues of belonging. We also don't always think of these as the fences we may be putting around roles and our expectations of the role someone will play on our team. We think often that we’re helping people – you need to learn how we act. But so many people in our world come to our teams with a very salient, real, and strategic need to understand whether they will truly belong with us, or whether this is yet another environment in which they will need to be on their guard. We may be giving people this message at a time when they are making this decision about an entire career. It comes faster than you think.
When creating a set of measures to characterize thriving on software teams, I knew I wanted to include a sense of belonging measure (we coined our developer-specific construct Support & Belonging). Sense of belonging is important not just because it has a large impact on an individual person’s wellbeing and happiness in the moment (although it certainly has that), but because it predicts a lot of other things we care about. People’s persistence and motivation in a new environment, for example. Group gaps in sense of belonging are an important red flag–a flag that software classrooms and cultures continue to throw up. And I was gratified to read this preprint this morning that argues exactly what we thought when we created a software team measure of belonging:
For too long, organizational science has implicitly or explicitly endorsed job performance as the ultimate criterion (or the bottom line for organizational performance). We propose that a broader vision of well-being–or optimal functioning–should be the ultimate criterion.
Belonging isn’t just about interpersonal kindness and it isn’t just about individual optimal functioning. Perhaps is about what we owe to each other.
And at work, we communicate heavily about what we expect from people because they are in a role. What about what people expect for themselves, because of their role? I hear this in our research interviews constantly, too: software engineers are deeply and profoundly concerned with whether they are the right kind of software engineer, and what the world of software engineering thinks of them. I have shared this many times in many talks because I am so struck by it, a small grain of sadness I can’t stop noticing – so many fulltime and 100% employed-as-software-engineers tell me, halfway through an interview: “I know I’m not a real software engineer, not like…” or “You know, if I were more of a software engineer…” or “software engineers, they don’t like x, like me…”
Role-based belonging is fascinating to me because it helps us think about the chains of inference we make about what is enabled by our job. And how we go wrong with this, often in more subtle ways than the just being terrible to someone. For example you can be pouring a lot of your own effort into perfectly amiable code reviews that still lower your new developer colleague’s sense of belonging if you communicate, with kindness and warmth and all cheer: you can’t get what you value in this environment; we don’t value what you bring; I don’t even want to spend the time to unpack whether you are trying to get something else here. I'm not curious about why you asked if you could do something different, because I can only see it as a break in my expectations for your role and put a stop to it. This pattern, at scale, has outsize consequences. It can be a vicious cycle for an otherwise well-meaning software team. This is one of the reasons I think it’s important to measure belonging, above and beyond something as simple as “how happy did we feel today.” Even the individuals being impacted by it may not feel or contextualize this in the moment, but its cost compounds.
When we do measure it – when we ask developers whether they feel supported by their teams, and whether their teams allowed them to make mistakes, and whether they feel that they truly belong as a software engineer when they show up even if they show up sometimes in ways that surprise their colleagues – their overall belonging scores predict how productive they report being, how understood they feel, and how likely they are to say that they also do things like speak up when they have a new solution, jump in and help fix someone else’s mess, and pass their learnings along to others. So as usual, the science of developers matches the social science of humans elsewhere.
But sense of belonging is also something I wanted to include in our research because it’s possible to target it. It can be changed. It’s so powerful because it’s adaptive, it’s a thing we use to navigate and try to find success. Psychologists generally agree that it’s hard to target “happiness” or “satisfaction” – and when you don’t have the tools for complex measurement all you capture is a general state that can contain anything from “the coffee is good today” to “nothing ever goes wrong for me at work because everyone is too afraid to confront me.” Sense of belonging is inherently less individualized. When you ask software engineers about it, you learn about their teams, not just them. And that’s one of the things I think we really need to do more in this work. One of the tricks I like about belonging is that it is social structural in nature, it forces us to sample the environment, as this paper puts it:
We approach the study of belonging from a social structural perspective that examines individual behavior as emerging from and contributing to the broader environment. In this view, an individual’s cognitions and attitudes are derived from their position in the social structure, whether that is defined as social roles (Eagly & Wood, 2011), status (Ridgeway & Bourg, 2004), or other features of culture (Markus & Kitayama, 2010).
I'm working on a role-based belonging measure specifically for software teams now. There are some fascinating impacts out there, including guiding lights about how role-based belonging cues can help people to recover from hostile and damaging experiences. I think this is phenomenally important insight for us to bring from psychology into software research. As ever, I'll keep you updated with what we find.
Work learned from in this post: Belanger, A. L., Joshi, M. P., Fuesting, M. A., Weisgram, E. S., Claypool, H. M., & Diekman, A. B. (2020). Putting Belonging in Context: Communal Affordances Signal Belonging in STEM. Personality and Social Psychology Bulletin, 46(8), 1186–1204. https://doi.org/10.1177/0146167219897181
Cheryan, S., Ziegler, S. A., Montoya, A. K., & Jiang, L. (2017). Why are some STEM fields more gender balanced than others? Psychological Bulletin, 143(1), 1–35. https://doi.org/10.1037/bul0000052
Eagly, A. H., & Wood, W. (2011). Social role theory. In P. A. M. Van Lange, A. W. Kruglanski, & E. T. Higgins (Eds.), Handbook of theories in social psychology (Vol. 2, pp. 458– 476). SAGE.
Markus, H. R., & Kitayama, S. (2010). Cultures and selves: A cycle of mutual constitution. Perspectives on Psychological Science, 5(4), 420–430. https://doi.org/10.1177/1745691610375557
Ridgeway, C. L., & Bourg, C. (2004). Gender as status: An expectation states theory approach. In A. H. Eagly, A. E. Beall, & R. J. Sternberg (Eds.), The psychology of gender (pp. 217–241). Guilford Press.
Tay, L., Batz-Barbarich, C., Yang, L. Q., & Wiese, C. (2023). Well-Being: The Ultimate Criterion for Organizational Sciences. https://psyarxiv.com/4v2y5/
Walton, G. M., & Brady, S. T. (2017). The many questions of belonging. In A. J. Elliot, C. S. Dweck, & D. S. Yeager (Eds.), Handbook of competence and motivation: Theory and application (2nd ed., pp. 272–293). Guilford.