community management

Okay, so we know community is important -- whether for developer relations for your product or other types of communities -- but how do we measure the success of community initiatives and even artifacts (like events or schwag), given how indirect and long-cycle so much of it is? How do we know we're even measuring the right things, and is there one key metric or KPI for measuring the health of a community? Where do "meta communities" or where does engaging key community leaders come in?

And when it comes to developer relations specifically, where should devrel sit in an organization (product, sales, engineering)? Who should you hire first? How do you reconcile developer as customer vs. developer as community member? And what's the difference between evangelism and advocacy?

Amir Shevat -- former VP of Product and Developer Experience at Twitch and former Director of Developer Relations at Slack who also previously worked at Google and Microsoft -- drew on his experiences to share insights and answers to these questions, as well as provides an overview of key concepts, followed by a Q&A with Mikeal Rogers, who works on Community Operations at Protocol Labs, and was formerly Community Manager of the Node.js foundation (and has shared insights on the changing culture and community of open source on a previous episode of the a16z Podcast).

This episode is based on a conversation that took place at a portfolio workshop event from a couple years ago organized by former a16z crypto partner Jesse Walden, because crypto gives developers the ability to build on top of and extend any protocol or application in the space, and developer relations and community building is an important part of that being realized. You can find the latest on company building best practices for crypto at a16z Crypto Startup School and see other pieces in our ongoing community series at a16z.com/community.

We're living in an unprecedented era of online collaboration, coordination, and creation. All kinds of people are coming together -- whether in an open source project or company, an R&D initiative, a department in a company, a club or special interest group, even a group of friends and family -- around some shared interest or activity. But the word "members" is faceless, and doesn't help us really understand, support (and better design for) these communities.

So in this special book launch episode of the a16z Podcast, Nadia Eghbal -- author of the new book Working in Public: The Making and Maintenance of Open Source Software published by Stripe Press -- shares with a16z editor in chief Sonal Chokshi the latest research and insights from years of studying the health of open source communities (for Ford Foundation), working in developer experience (at GitHub), researching the economics and production of software (at Protocol Labs), and now focusing on writer experience at Substack.

Eghbal offers a new taxonomy of communities -- including newer phenomena such as "stadiums" of open source developers, other creators, and really, influencers -- who are performing their work in massive spaces where the work is public (and not necessarily participatory). So what lessons of open source communities do and don't apply to the passion economy and creator communities? How does the evolution of online communities -- really, social networks -- shift the focus to reputation and status as a service? And what if working in public is also about sharing in private, given the "dark forest theory of the internet", the growing desire for more "high-shared context" groups and spaces (including even podcasts and newsletters)? All this and more in this episode.