Here is my mental model:
First off I should establish my bonafides: I was ~top mod for /r/reactjs for 3ish years, seeing it grow from 20k to 220k by the time I stepped down. I then cofounded Svelte Society from scratch (it's at 20k at time of writing). I then continued to seek out more challenges and became a lot more commercial - running a paid community for my book, a private Discord for devtools-angels and now Latent Space, and was always community adjacent working in devrel at Netlify, AWS, and (too briefly!) head of DX for Temporal and Airbyte.
Community is the lowest prestige of the 3 major devrel disciplines - "community manager" is often the lowest paid, least technical, lowest on the totem pole in a devtools company, often defaulting to frontline support or events coordinator. "Technical Community Builder" was briefly the hottest new job in tech but that proved to be a zero interest rate phenomenon (for now).
However a company with a great community can scale so much more effectively than one without: the Get Together book and podcast is a chronicle of the world's most successful communities for everything from cloud appreciation to notetaking software. You may want to study that book more in depth than I have and discount some of the B2C lessons to think more B2B.
However here I will lay our some of my strongest beliefs that I keep returning to after years of devrel advising and operating.
Rule 0: Have a strong Mission
The way a community is presented to a new joiner matters. If the first time they encounter it is always as the fastest way to get support on some kind of bug, then they'll come for that and only that. But it'll be hard to get them to think of coming to your community first for anything else, whether it is answering your surveys or showing up for your events.
Claire Carroll of dbt calls theirs a mission-driven community. By design or accident, the Analytics Engineering movement struck a chord in the industry and that percolated down to dbt's community, elevating their Slack and events to be the place to be to stay on top of this trend.
This is "Rule 0" because community managers can only do so much at this level. The ultimate responsibility for this usually rests with the founders. Mission sucks? Work with the founders to refine.
Good Missions are Schelling Points.
The longest lived communities happen when you expect your association to outlast your current job.
A nice fallback for a mission that sells itself is a good product. Linear doesn't really have a great mission but still has an enthusiastic community because people love the product experience. Product sucks? Work with product & eng to make it loved.
In the absence of good product, communities can form around good content (which is really just "non-recurring infoproducts"). I often say that "Content is the Minimum Viable Community". These relationships are often superficial and parasocial, you can look at the "communities" that form around singers (Swifties?) and Tiktok/YouTube/Instagram influencers - they are big, and not high value as a rule, but will convert if they simply like the creator enough.
This is so important that I might recommend not even hiring for community until mission or product or content has found market fit. For Svelte, this took 3 years and 3 major versions before I finally saw it was ready for a community effort.
Rule 1: Show Up
Every day. If you don't love being in your own community why the heck should anyone else join?
Rule 2: Role Model reasons to stay (fulfil the Jobs to Be Done)
One of my clearest memories from my time at AWS was when we tried to get "the AWS Amplify community" going. On our first Discord group call somebody immediately asked "why am I being asked to do free support work for a trillion dollar company?" Substitute "trillion dollar" with "venture backed" to taste.
This is a sign that we didn't think or explain enough from a user centric point of view, and were only trying stuff because somebody randomly decided to set a "community OKR" at AWS.
Inspect the reasons that you yourself spend your free/highest quality online social time in certain communities. Ultimately people join communities for a small set of reasons (aka the Jobs to be Done of Community):
News (they like to be the first-to-know something, or have first reaction to something)
Status (we are all status monkeys)
Insights (benefiting from someone's experience or perspective - instead of being the first-to-something, the goal here is to foster an environment that encourages the most credible people possible to offer the definitive, final word on an important topic)
Feedback (esp response time - even if I get none of the above, if I just hear back faster from your community compared to everywhere else where I shout into the void, then I'll keep coming back.)
Opportunities (jobs, access - if I get my job or my next hire through your community, you bet I'll be loyal. Ditto speaking or other smaller opportunities)
Humor (some people forget to have fun! But some people have too much fun. Find a happy medium.)
All of these have to be done by role modeling a baseline level of positive and negative reinforcement - positive by starting things (if you want people to discuss news in your community, start by posting news and sharing your thoughts), and negative by discouraging things (the traditional role of a moderator). Monkey see, monkey do.
Rule 3: Know Your Community Member
Take an active interest in why they're here, what they're working on. Constantly try to connect them with people who share their interests.
You can require onboarding in order to make this happen. Most communities start off low-friction, but end up low-energy. Onboarding rituals flip that equation. Often better to have a smaller but highly engaged community than a large but inactive one.
This is one of those "do things that don't scale" sort of things - obviously you can't really keep on a good ongoing relationship with hundreds of people, but if you have good mental models of a few dozen people you'll be able to be their advocate internally within the company or reach out to them when you really need their help for something.
Your ultimate goal, of course, is kickstarting many-to-many relationships, but "many" starts with one, and that's you.
Rule 4: Periodically heat up your community
A hot-only community cannot last, and an always cold community doesn't convert.
This is a close cousin to the now deprecated Orbit model:
Basically you want to have a strategy for your:
Most engaged active users: daily-weekly
(optional) kinda engaged users: weekly-monthly
Least engaged interest groups: quarterly-annually
Usually this involves a combination of a bunch of the tools of the trade of community, including (in increasing heat):
Regular content channels (eg YouTube Tiktok et al)
Twitter Spaces/Discord Stage/Slack Huddle
- the 2hr Cocktail Party is a source of particular alpha rn
VIP/Superuser group engagement (a separate blogpost on this is warranted)
- eg GitHub Stars or Stripe Advisory Board
This is just a brain dump of items, please comment below what I forgot and I'll also try to add over time.
Rule 5: Measure When You Have The Basics
I think people rush too quickly for community dashboards like Orbit and CommonRoom. It's nice to see pretty charts, and everyone wants to see a community that goes up and to the right, but the investment and active actions that need to be taken for those things to happen involve cycles much longer than OKR periodicities.
Because community is the part of the company that deals with the squishiest human factors, the feedback loop is long and nondeterministic, meaning industrialized measurement is probably final step, not the first one.
It's still good to track vanity metrics on individual items but most startups do not have their analytics shit together enough to calculate MQLs attributable to community or anything like that to evaluate performance or to guide investment.
Every interaction is an infinite game - the only "win" is to keep playing. You have to have a gut feel and raw love for the people you serve, or why else are you in this business?
When you're ready, you can head to Measuring DevRel.