Culture and engagement in community onboarding

Onboarding new participants into a community, whether it be consumers or contributors, carries with it a good deal of responsibility and effort. As discussed in previous posts, user and contributor onboarding should be intentional and, ultimately, designed to reduce barriers to entry for newcomers to a project.

Beyond the logistical challenges of bringing new people into a community is the harder-to-define part of bringing people into a community in a welcoming way. It’s one thing to have all the right signs in place that help new community members find what they need to use or contribute to the project. It’s often another thing to have them feel a part of the community. There are two paths to success here: the path of culture and the path of safety. 

The path of culture

Every community has a culture. It can be something as simple as the summer town festival or an in-joke that people in the community enjoy. Culture can take many forms, and participants can participate in it sometimes not without even knowing it’s something unique to them. I grew up in a US city that celebrated Dyngus Day, and until I was older, I didn’t know that the rest of the country didn’t celebrate it, too. But my city was a city of eastern European immigrants, and their traditions, culture, and food were interwoven throughout the city’s social and political activities each spring.

Online communities have their own cultures, too. Events, for instance, often generate excellent examples of cultural touchstones. If I mention (somewhat derisively) “hotel bar” to any past attendee of the SCaLE conference, they will probably nod their head in understanding, recalling the one establishment at the venue hotel that people invariably gravitated to, because the hotel was near the Los Angeles International Airport, which was not a neighborhood with a lot of other dining and entertainment options. So, despite a strong desire, many people always ended up there out of convenience of the location.

Or, those in the know within the OpenStack community will likely know why the 20th release of the project’s software was called “Train.” My colleague Rich Bowen retells the tale of when the 2017 Project Teams Gathering in Denver was in a venue near the city train tracks, and how the meetings were interrupted every five minutes by the very loud sounds of nearby trains passing.

Cultural elements like this are plentiful in free and open source software communities. People tend to naturally create and hold on to these, because these elements make us feel like we belong to a larger group. As social creatures, it’s almost irresistible. It’s fun to be in the know, even if people look at us funny. If someone mentions a certain text editor, and I sardonically start advocating the other text editor in the great vi/emacs debate, it’s not about the editor I prefer anymore. Now it’s become the in-joke, the counter-sign that says “Hey, I’m a nerd, too.”

There are problems, of course, with culture touchstones like this. The most obvious one is that, by their very structure, they tend to be exclusive at the same time they are inclusive. That which makes people feel like they belong can immediately make others feel the opposite. In-jokes and terms can make newcomers feel ostracized. 

There are some steps you can take to mitigate this. A fun little glossary or introduction document to your community can let some into the jokes a bit. Be deliberate about explaining the meaning behind a catchphrase or insider knowledge when it rolls by in a conversation. Making culture a part of your onboarding process is just as important as outlining procedures and processes.

The path of safety

In a recent conversation, Sarah Finn, Agile Coach for Red Hat’s Community Platform Engineering team, highlighted one of the onboarding concepts she brings to the communities she fosters: “psychological safety.” For Finn, the idea of psychological safety is about creating an environment where all community participants feel like they belong and can participate how they want. A community that deliberately creates an environment where all can actively engage.

This is a direct application of Dr. William Kahn’s 1990 study “Psychological Conditions of Personal Engagement and Disengagement at Work,” which focused on the concepts of employee engagement and retention, but can also easily be applied to participants in open source communities.

For psychological safety to work in an open source community or work team, according to Finn, participants need to not only believe they will be heard when they communicate, but also that they can communicate in the first place. This is more than just a pat on the head and saying “It’s OK, go ahead.” Participants should be:

• Given the appropriate procedural background so they know how to communicate effectively in the community. It does little good to say something brilliant to the wrong group of people.

• Given an environment where communication is encouraged from all. Newcomers especially need to be empowered to share their ideas with the larger group.

It should be noted that engagement does not mean that all new ideas will be accepted. Not all ideas will work. But even when someone comes to the group with a solution that might not be the best, if the environment is safe for that person, they will not feel trepidation about coming back again with another idea later. 

Psychological safety is an important strategy to apply to an open source project because it should also foster communities that are far more diverse and inclusive. Feeling safe to be one’s self is a critical component for all members of a community. 

Onboarding continues to be beneficial for community members, even beyond their initial entry into the community. A measured approach to sharing a project’s culture can help attract and retain participants, and building an environment of psychological safety can help encourage engagement and participation for all participants.