This post has been discussed at further length in podcasts with GitHub's Office of the CTO and Orbit.Love.

There's a big shift going on in how developer tools companies approach their userbase. In the past week alone, I've had 3 chats with startups that all concluded with some version of:

"By the way, we're really looking to ramp up our community effort right now. If you can think of anyone who can help us build a developer community, can you send them my way?"

One week, three pings. If this isn't a big trend already, it's at least worth writing about (per my Three Strikes rule). Who builds developer communities, why are companies investing in them, and why now?

Who's Job Is It Anyway?

Developers have had a long history of spontaneous community formation dating back to the IRC and BBSes of yore. (Misery loves company?) There is still a strong ethos of self organized community in modern dev culture, but the vast majority of this lies on the shoulders of a small group of under-funded volunteers.

But in the last couple decades, company-centric communities, where the community is almost the entire competitive moat of the company, have become a central part of developer life:

• StackOverflow serves 11m visits a day with community contributed Q&A's and sells ads and knowledge base software on the side.
• GitHub builds developer collaboration software, but at its core is a 56m-developer social network atop Git.
• Hacker News (serving at least 4m a day) is a big part of Y Combinator's unfair advantage in getting both founder mindshare and hiring talent.

You would expect that this realization would spawn a dedicated discipline to prioritize it, in the same way that Startups = Growth justifies the need for a Growth Hacker at every company serious about growth.

But as far as I can tell, it hasn't happened.

Sure, companies do hire community managers to groom their forums and post inoffensive memes (j/k of course, good community managers do much more than this). Some developer advocates may focus on community, but most developer evangelists create content and do outreach to other communities, to "meet developers where they are". Marketing folks might run the company mailing list, host webinars, or organize conferences, all mini-communities in their own right. Everyone intuitively gets the importance of community, and does their best within given boundaries.

But who's job is it to define the overall community strategy, and has the resources to develop it as aggressively as engineering? If this describes someone in your management team, great. But often the community builders are at the bottom of the totem pole.

The Venn diagram of people who can scale code and people who can scale community is going to be exceedingly valuable. You don't strictly need to be technical to run community — Ben Popper, StackOverflow's Director of Content, is still new to code — but developers can tell when they aren't talking to a technical person and that limits the depth of conversation. A technical community builder will have instincts informed by direct personal experience, and be able to empathize with member needs and make targeted recommendations.

The job title probably won't stay "community builder", by the way. Patrick McKenzie once observed that the DevOps movement led to "a once-in-a-lifetime upgrade in status, impact, authority, and career prospect" for sysadmins. I think a similar rebrand is due. As community goes from a side activity to a core driver of product, support, and marketing (great thoughts from Lisa Xu on this), the status and pay change will need a new name for people to rally behind.

What shall we call it? "Community Tummler"? "Community Developer"? Let me know if you have a better name. I've settled on "Technical Community Builder" for now, in the same way that Microsoft and Amazon have Technical Product Managers.

Why Invest in Community?

TL;DR: Traditional marketing and support isn't cutting it.

Devtools companies get that "build it and they will come" usually doesn't work. The sub-industries of technical marketing and developer relations are well developed enough now that there are books and conferences about it. We get that marketing can be just as important as product. (Let's leave the topic of "how much devrel and marketing overlap" for a future post...)

But a buyer's journey can start long before — and continue long after — their first contact and passage through the marketing funnel:

• Marketing attribution in developer tools is kayfabe — we play at tracking Twitter clickthroughs and podcast direct response, but everyone in marketing knows you need at least 7-13 touches before someone really considers you. As a developer I often wait out an entire year after hearing about something before even trying it out, just to see if it has staying power.
• After buying into a solution, I still need help to be successful with the tool. Developer tools are ultimately creative tools, and sometimes the imagination needs a little inspiration. Setup hurdles need to be overcome. If I buy something and end up not using it, it's going into the do-not-use pile for a very, very long time before I ever give it another shot.

This adoption process needs to turn from a mostly-transactional, finite game, to a relationship-based infinite game. You might envision Community as carefully designing the broader environment around the traditional sales and marketing funnel:

Or you could reject the funnel altogether. To quote Patrick Woods:

"Characterizing the developer journey as a linear funnel doesn’t really tell the whole story, as it’s essentially scoped to awareness and conversation — the journey is much more complex. I think onboarding to the community itself, retaining over time, and advocating for others to join, is a huge part of the journey... In this world, you want to understand how folks are engaging with the community as well as with the company/product, with product metrics (activation, adoption, etc) existing as second-order effects of the community. The Orbit Model, versus the funnel, tries to tell this nonlinear and comprehensive story."

When most developers make technical choices, you are just as likely to hear them praise the strength of the "ecosystem" (aka a community, with thriving third parties) as they do the core technical merits. In terms of the Rogers curve, this is the kind of argument made by "mainstream" developers:

Community is how developer tools cross the chasm from early adopters to the majority. Every devtools company looking to scale eventually has to figure this out, whether consciously or otherwise.

Other arguments in bullet point form, but feel free to request elaborations:

• Retention: Build product and they may not come, but build community and they will stay.
• Hiring: Community can just as easily net you employees as it does users and customers.
• Marketing: Community is highest-signal social proof/word of mouth you cannot buy.
• Moat: Community is a "feature" that cannot be copied. By Hamilton Helmer's 7 Powers Framework (the strategy framework du jour), Community helps you gain Network Economies, increase Switching Costs and Corner one of the most precious resources on Earth: Developers!.

• Scaling: Community is many-to-many, where Marketing/Devrel is one-to-many. The value of a community-focused user base scales by Metcalfe's law instead of Sarnoff's law. A thriving third-party ecosystem scales by Reed's law — even better!

  

• Risks: But you also do not "own" your community - the best you can do is lead by example, encourage helpful behavior, and enforce clear codes of conduct. Community is "user-generated content", and that bears with it great responsibility. Poor handling can backfire horrifically.

• Free Work? Community members can answer questions to each other and develop integrations to help you grow beyond your limited resources. To avoid expecting members to "do free work", this effort must be reciprocated by careful stewardship.

• Lifespan: One of the best measures of community success is when your users' relationship with you outlasts their current employment. Come for the software, stay for the community. Help your users get jobs, help your customers hire your users, and you will have fans for life.

• Open Source: Commercial Open Source companies must foster a viable community to be successful open source, rather than being de-facto "source available". In Nadia Eghbal's terms, more Federations than Stadiums, but both are definitely preferable over Clubs and Toys.

• Product Insights: Speaking to users helps you build things people want, but often these conversations are done by outreach (user survey or feedback session) rather than observation (in situ, natural environment). Community is where your deepest and most authentic user insights will originate.

All in all — a devtools company that prioritizes an engaged and inclusive developer community will run circles around one that doesn't.

There are multiple ways to do this well, but I am particularly fond of community that "serves a bigger purpose". A community that is strictly centered around a company (eg Dreamforce → Salesforce) is less appealing than one with room for multiple players (eg No Code → Webflow, Jamstack → Netlify), at least while you aren't yet a decacorn. Every great community is a great marketplace (tbc in a future post...), and every marketplace is a kind of platform, and every platform must respect the Bill Gates Line with its participants.

Why Now?

Dev Community has felt fringe for as long as I've been involved. I always felt like a bit of a middle schooler talking about my /r/reactjs work to companies, like "that's nice dear, but let's talk about more serious work now". I have friends running other popular Discords and forums that feel the same way.

That's why this shift is meaningful. This thing we used to do for fun, in service to our community, is suddenly a legitimate and highly in-demand skillset.

I don't know why community building is trendy again (there have been several waves), but D'Arcy Coolican at a16z nailed the current wave with his thesis on the Power of Social+. Greylock is promoting the virtues of Community-Led Growth and investing aggressively. Patrick Woods also observes that VCs are pressuring founders to “have a community strategy” from the outset, and noticing that devrel hires are moving earlier from employee #20 to employee #5.

Clearly the pandemic forcing everyone online was a forcing function:

• People were displaced from their existing IRL communities and needed a replacement
• Geography doesn't matter for online community (modulo timezones)
• Online communities are far more discoverable (searchable, join with a URL) and scalable (no room limits on community!)

Community-building software has also gotten a lot better:

• Realtime: Twitch and Discord and Clubhouse
• Conferences: Hopin and Bevy
• Async: Circle (where I am an investor), Forem (the creators of Dev.to), and Hashnode
• Metrics: Orbit.love (Martin Casado writeup here) helps quantify developer engagement (Commsor is less dev centric but noteworthy) and Weavr offers a "Front for dev community".
• Aggregators: Common Room

I also think the developer relations field has reached a level of maturity where companies are feeling the limits of one-to-many content creation and hiring developer influencers, so they are exploring other ways to scale their community engagement as an enablement role.

Become a Technical Community Builder

One of the telltale signs that this field is rife with opportunity is how much cruft it lacks. There's no book or course or conference teaching you how to do this job. There's no set career path, and "Chief Community Officer" isn't really a thing. We don't even have a commonly-accepted name for this role! And we certainly lack role models and thought leaders and the rest of the paraphernalia that comes with a mature industry.

• If that excites you, rather than intimidates you, get in touch with me and I'll send you to the exciting startups hiring for this role: WorkOS, Render, Begin, Sourcegraph and more. (If you're hiring: you can add yourself to the technical-community-builders repo here!)
• If you're starting a company to help Technical Community Builders (or whatever we end up calling this), you can browse my angel network here for investment and advice.
• If you're building a community, check Patrick's tactical guide to kickstarting your community
• If you just want to keep up on this space, you can come subscribe to the DX Circle blog where we will discuss Developer Communities, Developer Tools, Documentation, and everything else Developer Experience!

deep thanks to Patrick Woods, Uma Chingude, Gareth Dwyer, Rob Ocel and others for reviewing drafts of this post.