Technical Communities Are Made of People, Too

There are no communities without the people that fill them.

That may seem like an obvious statement, however, that is far from the case. Technical communities, as in, for example, groups centered on languages, frameworks, and tooling often lose sight of that critical truth.

Every GitHub issue created, every pull request raised, every feature request mentioned on Discord comes from a real, living human being.

(Yes, some pull requests are opened by automation processes. I know there are those of you thinking that already!)

Why does it matter that technical community is composed of people? How does that impact us practically?

In my talk at DevRelCon Earth 2020, Roots for Advocates: Applying Community Organizing Principles to Developer Relations, I broke down the import of this fundamental fact into two distinct categories:

• Power
• Self-Interest

Let's look at each one briefly.

Power

What is power?

Power is the ability to act.

Powerful people are people who have a voice in the decision-making process. They are empowered to speak freely. They know that their opinion will be heard. They know that they matter.

Prior to entering software, I worked as a member of the clergy for a decade. In my time in congregational life, this idea was reinforced repeatedly.

For example, there were times when a member of the congregation was sick in the hospital, and I was expected to know they were sick even if no one reached out to inform the community. I was expected to know because they assumed that they mattered, and their absence would be felt.

Technical communities that are successful are communities that cultivate the spaces for people who are invested in the product, framework, language, tool, etc. to matter. One of the most disempowering acts is when a member raises a pull request, speaks their mind, offers feedback, and is completely ignored. It may have been ignored because no one noticed and not out of malice, but the impact on the person is the same.

Self-Interest

It is hard to find a more loaded term in our society than self-interest. We are often conditioned to be selfless, to put others before our own needs.

Those acts of altruistic living are indeed praiseworthy, admirable, and virtuous. Yet, amidst all the selflessness, one cannot and ought not to forget a person's own self.

The Midwest Academy Manual defines self-interest as "self among others". It is not prioritizing your interests above everyone else, but simply recognizing that your interests are important, too.

The job of the organizers of a technical community is to harmonize the dissonance of competing interests.

There are many tools in the toolkit of an organizer, and chief amongst them is the 1-to-1 conversation. A successful 1-to-1 provides the organizer with the data needed to empower more people, understand the self-interest of those in the community, and take action collectively.

There is a lot written on the foundations of a good 1-to-1 conversation. Here are some of the bullet points:

• Introduce yourself
• Ask open-ended, not yes/no questions
• Listen more, speak less
• Build common ground
• Make a follow-up action
• Don't come with a prepared "ask", let the conversation discover the next steps
• Take notes immediately after, not during the conversation
• Debrief with another organizer soon after

Ultimately, understanding that your community is made up of people means you must think about two things:

The value you are creating for your community, and the value you are empowering your community to create for itself.

Creating value, communally, requires us to take another definitional journey into understanding that pivotal word. Value means more than what we might think it does.

Value

What is value for a community? How do you know you are creating value for a community?

I know something is valuable for me, as an individual, when I see it does something positive for me, perhaps increasing personal productivity, enhancing a workflow, saving me time, etc.

What does it mean though to add value for a collective?

That question precisely underscores why we must know our community. The more conversations we engage in, the more assessment of self-interest we undertake, the more we build the power for everyone at the table, the more we can understand what is valuable.

What could be worse for a product team than to invest significant R&D time into something that very few are interested in?

As you build an understanding of collective value, something else begins to emerge as well. We can call it a shared currency of communication.

There are particular ways of understanding that emerge in different and diverse communities. This is true in technical communities just as much as in other communities. It is why if you are a committed PHP developer, you may feel a bit out of place at a React meetup, and it's not just because the concepts and terms are new to you.

The community itself becomes valuable because it creates shared understanding amongst its people. This shared understanding will differ based on the commitment level of each individual. The most bought-in, the most committed, will completely inhabit the shared language and shared framing, while those on the margins will not. Understanding the different levels of commitment of each person is also crucial to building technical communities.

How a community makes space for the least committed, which may be a newcomer, can speak volumes about the kind of community it truly is.

What does this mean for you? Perhaps you are building an established community around a product, or you are trying to create a new one? Maybe you are a committed member and want to help your community grow and mature more?

Let's take a moment to share some practical takeaways and tips from all this conversation, which can seem somewhat theoretical.

Practical Tools and Tips

To empower people in your community, to understand their self-interest, to grow a shared currency of communication, you need to know who your community is. It is a very good first step to remember that a community is not an abstraction, but rather a collection of humans. Now you must know those people.

Tooling

Fortunately for you, there are tools that can help you keep tabs on your community. Some of them are pretty low-tech, like a good and classic spreadsheet. If you go down the spreadsheet path there are things you are going to want to track for each person:

• Activities
• Duration between activities
• Types and areas of involvement (i.e. Twitter, GitHub, Slack, Stack Overflow, etc.)
• Member outreach (i.e. How much do they bring others in?)
• Member inreach (i.e. How much do they expand the seats at the decision-making table for others?)
• Notes of 1-to-1 conversations, key decisions, etc.

At first, this is manageable in a spreadsheet, but very quickly, it is going to get unwieldy. Orbit is a great option that provides you with a framework to track and understand these data points, and a lot more, on the individuals who make up your community.

I have begun using it for my newsletter community, and in a short period of time, it's taken a lot of that manual work away from me, and let me spend more time on the actual community and less on the data collection.

For example, if someone shares my newsletter on Twitter, I can see that easily in a unified interface. As an organizer, I will want to follow up with that person and begin to build a relationship. I want to know what value they gain from it, so I can continue increasing that value over the long-term.

Tips

Once you have begun to see your technical community as primarily about the people in it, there are some very important things to hold close to your heart as an organizer. I want to hone in on one.

Primarily, remember feedback is an expression of investment on behalf of the person who offers it. Someone who doesn't care or who is not interested says nothing. Only someone who is invested offers feedback. This is especially important to recall when the feedback feels personal.

After my years in the clergy, this is one of the most critical tips I can offer in building community, technical or otherwise.

The more you begin to empower others, to listen to them, to build matterness for those using your product, tool, library, etc. the more people are going to speak up.

An organizer listens, analyzes, creates opportunities for collective movement forward, and also minimizes knee-jerk reactions and defensiveness.

You are also a person though, and your defensiveness is a legitimate feeling to be acknowledged. If you can't scream back at the person, what are you to do with it?

One of the bullet points for a successful 1-to-1 conversation was Debrief with another organizer soon after. This is not just because it will help you concretize the things learned in the conversation, but also because it can be a place for you to vent, and to validate your emotional experience.

It is crucial you have a trusted confidant, this could be a co-organizer, a friend, a partner, someone who cares about you and this work, to debrief with. You need that space, because in lifting up others in your community, you, too, need to be lifted up and validated.

A journey that begins with acknowledging that technical communities, no matter how technical the subject area, are comprised of human beings, does not end there. That acknowledgment begins a path of building, data discovery, experimentation, growth, and value creation.

The growth of your community, and your product, is inextricably bound up with the people invested in it. Empower them, get to know them, build a shared currency of communication, drive the value they derive from it, and your product/tool/framework will experience the benefits.