Guest blog: Building, in partnership with communities by Shog9

Labor unions are in the US tech industry news again, with the National Labor Relations Board determining that Google violated labor laws. Amazon reported to have hired the Pinkertons - an agency so notorious for strikebreaking that it appears in both Sherlock Holmes fiction and an act of the US Congress - to infiltrate a worker strike.

This news has me reflecting on a conversation I had at the start of the year with a negotiator for a labor union here in the 'States, in which he described a meeting he'd had recently with the representatives of a particular large company. The representatives argued that the contract under discussion ignored their industry's economic reality of decreasing profits and increasing expenses.

...The negotiator responded by pulling out the company's notes from a recent call with their shareholders, in which they'd argued the exact opposite. And then negotiations began.

"It's important to avoid antagonism in these things," the negotiator told me. "We're on the same side: if the company does well, the workers do well; if the workers are doing poorly, the company will do poorly. Management sets the direction, but the workers have all of the critical information and skill; for any of us to succeed, we need to work together."

It resonated with me. The shape of the situation was familiar: groups with everything to gain by working together, but frequently at odds anyway. I've seen this too often within software development: devs vs. QA, ICs vs. Management, sales vs. everyone. And mostly, software creators vs. the communities that use their software.

Both sides have every reason to collaborate in these cases, but they are still too often sliding into antagonism and distrust. When it comes to communities, developers have the most to gain. A healthy and collaborative community of end-users can sustain their work far beyond what would otherwise be possible. Yet, too often, I've seen software teams take an apathetic or even antagonistic attitude toward the communities that form around their work, in extreme cases going so far as to enlist the equivalent of Pinkertons to break up these groups.

I've been there myself. Prideful of my work and fearful of what it would mean to admit that others might have a stake in it, perhaps even an understanding beyond that which I held, I resisted collaboration with the folks who used my software, even as I depended on them. It took far too many conversations with users, in which they, like my negotiator friend, demonstrated both a solid understanding of my work, a better understanding of the needs the software was meant to address, and a willingness to work with me to further that understanding... Until I was able to overcome my fear and pride. That experience changed my life, but I put up far too much resistance getting there because I couldn't imagine anything else. So... I'd like to share some of the advantages of working with a community.

Definition of an end-user community

There are multiple definitions of community, and multiple types of communities. Over the past few years, the term has become a buzzword, and in the process, it has lost some of its meaning. For this essay, I will avoid focusing on a specific type and put forth the following definition:

An end-user community is a group that talks within itself about the software.

Many different groups could be considered a "community" with this definition. For example,

• Those who help each other learn to use the software
• Those who help each other learn to perform specific tasks with the software.
• Those who help develop the software (e.g., open-source communities)
• Those who help each other build on the software (platforms, integrations, "mod" communities)
• Those who gather to share their enthusiasm for, or commiserate over the pitfalls of, the experience of using the software

When a large group of people uses your software, there will be multiple communities along these lines. Some people will likely be members of more than one, and folks will move between them without much fanfare. Suppose you picture each end-user as a node in an undirected graph. In that case, each conversation involving your software becomes an edge connecting them. Each conversation has a purpose that defines the edge. Each group of nodes connected by multiple edges becomes a community. The more conversations, the stronger the connection between members of the communities; the more people, the larger or denser the graph as a whole; the more varied, the more distinct forms of community exist.

This definition serves only to provide a framework for recognizing communities; it does not attempt to define their value or purpose. Crucially, this definition avoids making the mistake of considering every end-user to be "part of the community" - if they aren't talking to each other, even if they are talking to you, then you have a bunch of disconnected people. This is fine, but it implies something many of us have realized while standing on the edge of exhaustion: when every conversation about your software, every learning experience, every bit of feedback... goes through you... Then YOU, your time, your team's time, are the practical limit for all of these purposes.

This definition also highlights something else... Your software might well have one or more communities associated with it, but you are not an intrinsic part of them! Like the management team in the story I told above, your choice lies in whether or not you want to be a part of these conversations.

So let's talk about why you might.

Advantages of being a part of your software's communities

The most obvious reason to join in these conversations is access to information: you want to know what your communities know! What they're using your software for, what they're struggling with, what they'd like to see added or changed. You can (and should!) ask them directly: feedback, surveys, and user testing are indispensable parts of research and development. But they require extra effort, above and beyond the conversations that are already happening. I might be willing to spend time talking with someone I know but disinclined to devote that time pushing feedback into the opaque (and possibly dusty) suggestion-box that is your dev team's feedback channel. By joining the communities, you remove that distinction by making yourself part of the graph. The time I spend sharing information with my peers now includes sharing it with you.

This may seem a bit... self-serving. Will these communities even want to include you? But it doesn't have to be; by joining in the conversations, you can bring your information and perspective to them as well! You may not have the wealth of experience that some of your users do. Still, you likely do know a fair bit about the software itself and the reasoning behind various decisions in its design and implementation. This brings me to...

Community as partners

Perhaps this story sounds familiar: after months of arduous work, you release a new version of your software: new features, contemporary design, new documentation. You're exhausted but happy - until the feedback starts rolling in. Folks are confused; options have changed; they don't like the new icons; the documentation is confusing and unhelpful. There are bugs you missed in testing or didn't have time to fix.

You find yourself on a survivalist blog, reading about goat farming.

It is a story as old as our industry; even as we've developed better tooling, more flexible release methods, strategies like TDD... Even as The Internet has made large-scale beta testing widely feasible... Releasing updates is still too often a shot in the dark: you don't know what end-users will think of your work until they start to use it.

...But what if you did? This is the real power of developing with a community: when you work in public, present your ideas early, are open about the goals you're working towards and the constraints that limit you, with the folks who depend on your work... Then, like my negotiator, you can move past those antagonistic barriers and collaborate on solving problems together. Their goals become yours. Your constraints are also theirs, each release a collective effort.

Will there still be unhappiness, disagreements, conflicting goals? Hell yeah, we're talking about humans, not utopians. But if you participate openly as a member of these communities, you will no longer stand alone on one side of a conflict. That others may disagree with specific ideas or decisions is its advantage after all...

Community as a Red Team

As stressful and demoralizing as disagreement can be, the most wearying jobs I've had have been those where dissent was absent, teams where my ideas and approaches went unchallenged, times when I was left to fail with no warning. For some projects, this is no big deal - a failure is just the price of a lesson that can be learned. Sometimes, that cost becomes too great, and it is all but essential to have a bit of push-back to encourage robust design and implementation work. In some circles, dedicated groups - "Red Teams" - are formed to provide precisely this sort of opposition: their mission is to attack ideas, designs and systems to identify weaknesses so that they can be addressed before being released into the unforgiving world.

A healthy community of end-users can provide much the same benefit by offering differing perspectives. By engaging with critical or contrarian end-users, by defending your approaches and considering alternatives, you too have the opportunity to strengthen your work. Your goal in this situation should not be to satisfy or placate everyone; quite the opposite, you should push back until (unless!) it is clear that you are wrong! But, it is just as important that you listen - be wary of writing off criticism that sounds hyperbolic or angry; read past the tone, consider the underlying ideas carefully... Then thank folks for taking the time to help you put your ideas to the test.

The cost of being part of a community

This all sounds pretty great. So what's the catch... Well, in the immortal words of Horse_ebooks: "Unfortunately, as you probably already know, people"

Time and effort

The highest single cost to being a part of a community is... the time it takes to do so. Every minute you spend conversing is time away from building; every hour locked in a debate is an hour that could have been spent improving your software. Even if you excel at context-switching (and most of us aren't as good at that as we like to think), you cannot physically be typing in two places simultaneously. The larger your communities grow, the greater the temptation and opportunity to spend a disproportionate amount of time engaged with them.

Be wary of this. Set limits for yourself, and stick to them. With care, you will save far more time than you spend engaging; without care, you will have no time left to save!

Myopia

Per the definition I proposed above, these communities do not include everyone who uses your software, much less everyone you might wish to use it. You can and should rely on other sources of information to identify the full spectrum of needs and wants that you work to fulfill. Be careful not to over-value any single source of information!

Be up-front about this, with yourself and with your communities! If you're making a decision based on feedback from other sources, then say so. Almost all of us have struggled in trying to satisfy different, conflicting needs, and most of us will empathize with you, possibly offer aid in reaching out to folks not currently represented, even suggest compromises you may not have thought of!

Emotional well-being

Different people have different tolerances for... well, people, especially when those people are talking about something as personal as your work, especially when they're critical, especially when there's no polite way for you to ask them to stop.

There can be an addictive quality to this as well... And it is ugly.

I often think of stepping into a new community as feeling similar to standing on top of a ski slope, ready to go down: a heady mixture of fear and excitement! One of the first things that a good ski instructor will teach you is how to fall. Because you will fall, and an unpracticed fall is a great way to get hurt so badly that you won't do any skiing. And this is just as true for interacting with groups of people.

With practice, you can learn how to compartmentalize such interactions, remember to limit the time you devote to them, and limit their effect on your mood and health. But... Not everyone does learn this, and if you get hurt too severely before you get practice, you'll likely stop.

Recognize going in that engaging with any group is potentially treacherous; start slowly and practice your falls.

Conclusion: you were built for this

This might sound idealistic, even unrealistic. And I'll admit, it is a challenge: both of your abilities and how you look at the world and your place in it.

When I first realized that collaborating with end-user communities was even an option, I spent several years poking at the idea timidly, trying little bits of outreach here and there, dipping my toes in the water. Then I joined the team at Stack Overflow and found myself neck-deep in a pool with no bottom! I swam there for nine years. At that time, I realized that most of what I had been afraid of wasn't real. People use my work because they want to; they're talking to me because they want to work with me; they're critical because they see a problem and want to work with me on a solution. Some of them are really bad at it, but then again, I'm not always great at it either - only by persevering do we find ways to surpass our failings and help others do the same. For the past nine months, I've been working at EDB, a company that exists due to collaboration between its teams and the great PostgreSQL community. If there was ever proof that this approach does work, indeed, this is it...

But of course, outside of our still-young industry, this approach has been used and been working just fine for millennia. We are only able to have specialized professions such as "programmer" because our ancestors learned how to work together, to draw on each other's unique skills and knowledge, to build communities and work within them.

You and I exist today because our predecessors learned not just to build, but also to build for others, and collaborate with those who came to rely on their work. Let's continue that tradition!