I started a small online community consultancy and it's been a rough go, if I'm honest. Because we are increasingly interacting with each other virtually, a trend which was accelerated by a pandemic, "community" has become something every company believes they need. That's good for business, right? Not the way I do business, I'm afraid.

The conversation goes something like this:

Potential client: We need a community!

Me: Why? It's very difficult to start a new community from scratch. And even after doing the work to get started, there's no guarantee it'll thrive. And even if it grows in a healthy way, mostlikely it won't help your business grow.

Potential client: Uh. Ok... Don't call us; we'll call you.

The way I look at it, communities require considerable investment because they store considerable value. If it were easy, every company would have healthy and productive communities. It's not the sort of thing to do on a whim or because it's trendy. If I'm going to help create a community, I must know that the company will support it for the long haul.

I'm fascinated with Conway's law, which asserts a correspondence between an organization's internal structure and what it produces. One formulation comes from Conway's original paper:

To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces. The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon.—Melvin E. Conway

I saw this pretty directly at Stack Overflow. Before I joined, the company was very flexible in how it communicated. They weren't divided into departments because everyone picked up whatever was most urgent and important that needed doing. If that meant a developer answering support tickets or an executive assistant hanging curtains, so be it. As the company grew, people gave up their Legos and specialized.

By the time I'd joined, the company was pretty well divided into departments. When I first visited the New York office, I was warned not to interrupt the salespeople because they were busy making money. Sales worked in a huge open office plan even though our CEO was known as a proponent of private offices. A few years later, I was invited to give a crash course to new salespeople so that they would understand Stack Overflow and be better at selling it. We had fun, but I suspect it didn't help because they were selling a product that was largely disconnected from the Stack Overflow community.

Confusingly, the product they sold was branded as Stack Overflow, but it was created by people who weren't directly involved in the Stack Overflow site for programming questions. The job site called Stack Overflow Talent had a little blue box¹ in the sidebar of the main Stack Overflow site and that was pretty much the extent of how the two Stack Overflows were connected. It wasn't until years later that Stack Overflow sold something that resembles Stack Overflow. Having completely separate products was (depending on your interpretation of Conway's Law) a consequence or cause of the divisions in the company.

When I talk to potential clients, the conversation starts with the CEO/founder. But our primary contact person inevitably turns out to be someone in marketing. The idea seems to be that an online community is a proprietary social media site and marketing is usually responsible for social media campaigns. It's an understandable attitude, but remember Conway's law. A community started by marketing will never become more than an outlet for marketing.

I recently gave a presentation to our Chief Marketing Officer at EDB. I highlighted the role of documentation during the sales process. To sum up, documentation, if it is to be useful for developers, reflects the reality of our products, warts and all. As a result, savvy buyers of software products consult documentation as a part of their purchasing decisions. Documentation doesn't lie.

We have some control over how our documentation is designed and it might be tempting to smooth off rough edges. But that effort is doomed to futility because our documentation needs to be accurate if we want developers to be successful. We'll have a much harder time getting customers to renew if they don't actually use our products. Only by fixing the underlying product can we hope to show our best face to the world.

In the same way, a community works more like a mirror than a megaphone. If your product inspires passion in users, they will talk about it somewhere. You can suppress negative chatter in a community you control, but that just means people will talk about it in some other forum. Better to think of your community as a standing research panel rather than an audience for your marketing message.

In 1966, Ronald Reagan (then known as an moderately successful actor) ran for Governor of California. About the same time he decided to quit smoking and took up eating jelly beans instead. At a campaign event, fellow candy enthusiast Russ Albers (inducted in the Candy Hall of Fame) introduced Reagan to a brand of smaller and more flavorful jelly beans. For the rest of his life, Reagan was a devoted fan of Jelly Belly jelly beans. That's the sort of publicity money can't buy.²

The true value of a community is relationships. You just never know when a Russ Albers will introduce the future president of the United States to your product. A community creates thousands of authentic connections between people that creates trust and opportunity. A well-managed community produces passionate users and honest feedback that just can't be purchased.

In an ideal world, everyone in a company would have their ears to the ground listening to customers. But nowhere is that more important than the people who make the product that's being sold. How often do you see companies selling solutions to problems nobody in the history of the world has ever had? That doesn't happen if product development is listening to customers.

As a developer advocate, I spend approximately 0 effort convincing developers to use EDB's products. Instead the job is cultivating an environment where developers can be successful using our products. We are immeasurably aided by the PostgreSQL community, which supports each other when it comes to the open-source software our products are built on. Database software is incredibly complicated. Since it's beginnings as research project, the community has made it possible for almost anyone to use Postgres productively.

Fundamentally, people derive joy from helping others. It's why people answer questions for no compensation and how you can visit a foreign country without a guidebook.³ Communities that tap into that fundamental desire provide value to companies that happen to be in the same ecosystem. Unfortunately, that benefit can be difficult to measure directly.

Ideally, I'd like to work with companies that start a community as long-term project with no particular promise of resulting in sales. But I can see how that might look like I'm selling snake oil where the benefit comes any day now. So my second favorite mode of community is as a place where customers can support each other (with input from the company's employees). It's especially useful if the community informs the development of the company's products.

For most companies, the community isn't the product. But it can be a place for people (including employees) to have authentic conversations about whatever the company is selling.

---

Footnotes:

1. Fellow employees will recall another adjective used in place of "little". ↩

2. All the pictures on this page besides the one of the Gipper, were from when our family visited the Jelly Belly factory and paid to go on a tour. We're not in an online Jelly Belly community or whatever, but the company has created a sort of fandom that gets people excited about their brand. ↩

3. Unfortunately, there are also people who like to cause trouble and those people make it harder to trust answers on the internet or directions on the street. This is were community management steps in. ↩