Community Building Antipatterns for DevRels

Do not treat the community as just an audience, avoid overly-monetizing folks (especially in challenging times), and be sure to provide opportunities for growth!

Last week, I was privileged to chat with Sarah Drinkwater, Solo GP at Common Magic, who invests in products with community at their core. The conversation was great fun, and it was abundantly clear that Sarah is extremely knowledgeable in community building. Her Medium account is full of great insights for folks building communities, and her guest appearance on the 20Angel podcast is well worth a listen if you’re also interested in the related seed/VC funding aspect.

As I looked back on my ~15 years of community-building experience—initially done for fun with the OpenJDK initiative and the London Java Community, and later as part of my professional DevRel roles—I was reminded of a lot of good times and also of some antipatterns I had repeatedly seen. I’ll start with my thoughts on “community” and then launch into the antipatterns.

What is a community, and why should I care?

I’ll keep this section short, as there have been many great things already written about “community” from the perspective of developer relations.

Your first stop should be Mary Thengvall’s awesome book “The Business Value of Developer Relations”, which has the word “community” in practically every chapter heading.

There are also several great DevRelCon talks, such as Dawn Foster’s “Lessons about Community from Science Fiction”, Akanksha Bhasin’s “My community building journey”, and Jonathan Ashong-Lamptey’s “Diversity and Inclusion for your Company and Community Practical Steps”.

In a nutshell, I share the same belief as Toby Lowe, in that:

A community is a group of people who share an identity-forming narrative

In the communities I work in, this narrative is typically formed around a technology (e.g. Java, Kubernetes, AWS), a practice (e.g. agile, TDD, architecture), or a movement (e.g. cloud native, DevOps, platform engineering).

People join communities for a number of reasons, including fixing a problem they are encountering, learning, contributing, career development, or just “nerding out” with fellow geeks. All of these are valid reasons, although you may want to optimize the communities you are building to achieve a specific goal as part of your broader company goals.

Is community-led growth the next evolution of product-led growth?

I was fortunate to spend time with Patrick Woods, co-founder of Orbit, last year at the DevRelCon conference party (drinking honey-flavoured beer in a boat on the Vltava River in Prague, no less!). The Orbit folks are obviously all over the value of community, and after I talked about the value of product-led growth (PLG), he made an excellent pitch for community-led growth (CLG) being the next evolution of this.

I’m increasingly bumping into a bunch of smart people talking about this, including Sarah and Patrick and folks like Camille Rickets (on the awesome Lenny’s podcast, “How Notion leveraged community to build a $10B business”) and Sharath Kuruganty (“The era of community-led growth”).

I personally don’t think choosing a PLG or CLG go-to-market motion is an either/or choice, much in the same way that PLG can co-exist with (or augment) sales-led growth. Regardless, all this chatter about the power of community points towards community-building becoming an increasingly important skill for DevRel folks in the coming future.

Community building antipatterns

In a future post, I can dive into some of the community-building playbooks I’ve run over the years, but I often think it’s instructive to look first at what not to do! Here are my top three antipatterns that I see repeated in developer communities.

Treating the community as “just an audience”

I’ve talked before about my take on DevRel, and a big part of this involves community building, empathizing with users, and acquiring feedback. These three things are intricately linked. If you are attempting to build a community and are not empathizing or listening to people in your orbit, you’re really just building an audience.

Now, there’s nothing wrong with building an audience if that’s what you are aiming for. However, most of us in developer relations aim to build communities that thrive on two-way interaction. Not only does this lead to a faster-growing community, but critically, there is a lot to learn from the community interactions.

When I joined and ran communities for fun, socialising and learning from others was a big part of why I was involved. When I started building communities professionally, I typically aimed to support users and get members' feedback about my products and the related problems. For this to happen, I had to “give to get”, build trust, and be open to hearing all kinds of feedback.

If you want to understand more about this concept, Divya Mohan wrote a great related piece, “The DevRel influencer trend.” In my experience (and no judgment here), most DevRel influencers aim to build an audience, not a community.

I like to build communities where everyone participating has the opportunity to be as involved as they want to be.

Trying to monetize the community too aggressively

Although this has long been a problem, the increasing adoption of product-led growth and more challenging macroeconomic conditions have encouraged some go-to-market teams to attempt to squeeze every last dollar/euro/pound out of people in their company’s orbit. And this often (unfortunately) includes the community.

I love this meme from Elena Verna. I almost spat out my coffee when I first saw it; it was so on point!

Elena Verna’s meme-building skills are off-the-chart, lolz!

As a DevRel leader, I often reminded others in the company that the community should not be treated as a marketing mailing list. When you sign up for a mailing list, you (kinda) know what you’re getting into; it will be transactional at best. It’s not the same with a community, though. Trust is one of those commodities that is tricky to build but very easy to lose.

Be very careful about letting your BDR, SDR, and sales teams jump into the community. Don’t get me wrong. I’ve seen some amazing BDR interactions in communities where these folks offer to help fix product problems, provide technical demos, and share interesting articles. They only jump into a sales motion when it’s obvious that the community member would benefit from the paid offering. However, I’ve also joined many communities to look around, and I’ve had sales folks reach out to me within minutes with a cold pitch 🤦

Not providing opportunities and progression for your superstars

The communities I’ve most enjoyed being a part of have provided opportunities and paths for progression. For example, the OpenJDK community opened doors for me to present at internal conferences, improve my leadership skills, and develop the ability to teach software developers of all backgrounds and abilities. The InfoQ community enabled me to hone my writing skills, learn from and network with interesting people, publish books, and more.

Therefore, I believe community-builders should consider this when cultivating their communities. Not every community member will be looking for opportunities or the ability to level up, and that’s fine (in fact, these folks are often the stalwarts of your community). Still, in my experience, the most passionate and committed folks will jump at the chance to get more involved.

As an example from my time leading the DevRel team at Ambassador Labs, we created an “Ambassador Ambassador” community champion program in 2020. Initially, we recognised key community members, gave them sneak peeks of new technology, provided extra learning materials, and invited them to conferences.

Over time (and with the leadership of my awesome teammate Cindy Mullins), this program grew into the Ambassador Community Advocates (ACA) program, which provided mentoring, speaking opportunities, and article-writing training.

Not only did these folks provide amazing product feedback and help spread the word about our tech, but we even hired some of them for full-time roles!

Want to know more about building communities?

I hope this post has helped to shed some light on community-building and several antipatterns I have seen.

Please comment below and let me know if you want more content on managing and leading in the role of developer relations.

And don’t forget to subscribe! I’m aiming to share a post every two weeks or so.