Community Building.

Communities are not built by accident; they are built by deliberate design and sustained attention. Many DevRel teams treat community as “we have a Discord,” which is the equivalent of treating customer support as “we have an email address.” This file covers what community building actually requires.

What a community is for

A community serves four primary functions, in roughly increasing order of value to the company:

1. Peer support. Users help each other; reduces support load.
2. Distribution. Members share content, recommend the product, attend events.
3. Co-development. Members contribute code, integrations, content, translations.
4. Strategy input. Senior members influence product roadmap, identify needs, validate direction.

Programs that only deliver #1 are useful but limited. Programs that deliver all four are strategic assets.

The hierarchy of community foundations

Before any tactic works, certain foundations must be in place:

1. A product worth being a community around. This is not negotiable. No community-building skill compensates for a product nobody wants.
2. A reason for members to be in the same room. “We make X” is not enough. The shared interest must be in the work, not just the vendor.
3. A space where conversation can happen. A Discord, Discourse, Slack, or equivalent — designed thoughtfully, not slapped together.
4. Visible, consistent staffing. Members need to see employees being helpful, on schedule.
5. Recognition mechanisms. Ways to acknowledge contribution.

Skip any of these and the community will fail in predictable ways.

Designing the space

The architecture of a community space matters more than the platform. Generic guidance:

• Fewer channels than you think. Excess channels fragment conversation.
• Welcome flow. First-time members should encounter a clear, friendly orientation.
• Rules visible. Code of conduct linked everywhere.
• Escalation paths. How to report problems; who is reachable.
• Predictable rhythms. Weekly office hours, monthly AMAs, quarterly events.

The first 100 members

Communities have phase transitions. The first 100 members are essential and behave differently than later members:

• Personally invite them. Don’t broadcast.
• Convene them regularly. A weekly office hour with the founder.
• Take their feedback seriously enough to act on. The first 100 should see the product change because of them.
• Recognise them explicitly. First-100-member badges, founders-list mentions.

This is the founder-led-community phase. It does not scale, and it is necessary. Skipping it produces communities that fail to ignite.

The next phase: 100 to 1,000

• Identify and support emerging leaders. Members who answer other members’ questions, write content, organise local meetups. These are your future ambassadors.
• Codify what works. Document FAQ patterns, common workflows.
• Start a regular rhythm of recognition (e.g., monthly “community shoutouts” in your newsletter).
• Introduce roles or trust levels. Discord roles, Discourse trust levels, “verified member” status.

Scaling beyond 1,000

• Move from staff-helps-everyone to staff-supports-helpers. Your job becomes enabling the volunteer community to scale.
• Start an ambassador or champion program. See ./ambassador-programs.md.
• Regional structure. Local user groups, language-specific channels.
• Sub-communities by interest. Beta program, contributor team, educator group.

The Orbit Model as operating manual

The Orbit Model (see ../03-frameworks/orbit-model.md) gives you concrete language for tracking how members move through community phases:

• Explorers → Participants → Contributors → Advocates.
• Love × Reach = Gravity.

Operationalising this requires:

• Instrumenting member activity across channels.
• Scoring activity for love.
• Estimating reach (follower counts, conference history, GitHub influence).
• Reviewing the orbit distribution quarterly.

Reciprocity is non-negotiable

The single most common failure mode of corporate-led developer communities is extraction without giving back. Symptoms:

• Members are asked to contribute content, code, or evangelism, with thin or no recognition.
• The company benefits visibly; members do not.
• Members notice. Other members notice. The community thins.

Defences:

• Every program member should be measurably better off for being in the program: career visibility, network, learning, recognition, swag, money where appropriate.
• Pay community moderators when possible. Free-volunteer-mod-only models break at scale.
• Make recognition tangible. Public credits, conference speaker placement, ambassador titles, swag with actual taste.

What kills communities

A short list of patterns that consistently kill communities:

• Inconsistent staffing. Long gaps where no one from the company is visibly present.
• Marketing posts in the community space. Promotional content where members come to ask questions.
• Unanswered serious questions. A question marked “support” that sits for days.
• Rule inconsistency. Some bad actors moderated; others not.
• Founder departure or de-prioritisation. Communities that lose their internal champion often atrophy.
• Acquisition or restructure. Many acquired communities never recover.
• Spam tolerance. A few unaddressed spammers kill engagement quickly.

Community team composition

A scaled community function typically includes:

• Community Manager. Operates the space day-to-day.
• Community Engineer. Can answer technical questions credibly.
• Community Program Manager. Runs ambassador/champion program.
• Moderators. Often paid contractors at scale.
• Engineering volunteers. Engineers who rotate through community shifts.

Metrics

Track these continuously:

• Member growth (gross and net).
• Active members (DAU, WAU, MAU).
• Contributor return rate at 90 days. (Healthy: 25–40%.)
• First-time-poster outcome. Did their first post get a response?
• Sentiment. NPS, in-platform sentiment, qualitative survey.
• Cross-platform contributions (code, content, talks).

See ../04-metrics/community-metrics.md for detail.

When you don’t need a community

Some companies build communities they didn’t need:

• Pure-enterprise companies whose customers’ developers do not want to be in a community with each other.
• Single-purpose tools whose users have nothing to discuss with each other.
• Companies with no product staff who can engage.

A community that is not engaged with by company staff cannot survive on member enthusiasm alone.

See also

• ../03-frameworks/orbit-model.md
• ../04-metrics/community-metrics.md
• ../08-tools/community-platforms.md
• ./ambassador-programs.md