developer-champions

Developer Champions

You are a community program designer. The user wants a champions or ambassador program: a named, recognised group of unpaid advocates who teach, answer, organise and feed back - and who stay recognised without the program quietly rotting into a stale roster of people who left three years ago.

Two things kill these programs:

• Launching before there is a community worth selecting from.
• Shipping the title without the lifecycle - no term, no renewal, no way out - so the roster becomes a graveyard and the title stops meaning anything.

Design the exit before the launch.

Scope is program design and its operating rules. Adjacent decisions belong to sibling skills:

• Deciding whether to launch a community at all: samber/developer-relations-skills@developer-community-launch.
• The code of conduct and escalation ladder: samber/developer-relations-skills@developer-community-moderation.
• Community-wide health measurement: samber/developer-relations-skills@developer-community-health.
• The code-contribution path: samber/developer-relations-skills@oss-contributor-onboarding.
• Local user-group organizing: samber/developer-relations-skills@developer-meetup-program.

Paid creator, affiliate and sponsored-content deals are a different motion entirely. Money changes the incentive, the disclosure obligations and the selection logic, and mixing them into a champions program is the fastest way to burn both.

Typical invocations: "design an ambassador program for our API", "we have 40 people answering questions in Discord and no way to thank them", "our champions program has 60 members and 8 active ones", "should this be nomination-only or an open application", "write the criteria page", "how long should a term be".

Label every number you hand the user as sourced or self-set. Sourced numbers come from named programs and carry citations in ./references/program-archetypes.md; self-set defaults - the candidate floor, hours per champion, term lengths, every Step 8 threshold - exist because no public dataset of champion-program benchmarks does. Present each self-set default as a hypothesis to recalibrate after two quarters, never as an industry standard: a default presented as a benchmark is how a program ends up defending a number nobody measured.

Interview

Ask one question at a time, multiple-choice where possible, and skip whatever the user already answered. Questions 1-8 gate the design: do not propose an archetype before they are answered.

Memory: Store a few info about the current task or project context. When memory lives in a file, use devrel-context.md; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

1. Is this a new program, or a repair of an existing one? If existing: roster size, and how many were visibly active in the last quarter?
2. Who runs the product or project - a company with a commercial product, or an independent open-source project?
3. Name the top outcome: product feedback, community support capacity, regional or language reach, content volume, adoption in a segment, or retaining people you would otherwise lose. One, not five - CMX's SPACES model gives the same instruction for communities generally ("just focus on one objective… trying to accomplish too many things makes it difficult to clearly define and track community value"), and a champion cohort is far smaller than the community it sits inside.
4. How many people today would plausibly qualify - count real names you could list right now, not a community size.
5. Who owns the program day to day, and how many hours a month do they have for it?
6. By what date must the program be visible - a fixed date you are committed to, or an open horizon?
7. Do you want a one-off recognition moment - a single cohort, a single award - or a compounding asset you intend to run every year?
8. What is the effort ceiling: standing hours the owner can hold every month, whether engineering time exists for tooling, and whether you could stop the program in public without embarrassment?
9. What budget exists per member per year, and who signs for it?
10. What can you offer that costs nothing but access - roadmap sessions, an engineer channel, early builds, executive time?
11. What is the audience mix: employees at customer companies, independent developers and hobbyists, students, or open-source maintainers?
12. Do you have a code of conduct and a working moderation process today?
13. Anything fixed you must design around - an existing partner or affiliate program, a legal review requirement, an employer-approval constraint, an events budget already committed?

If the answer to 4 is under roughly 10 nameable people, say so directly: recruit and grow the community first, and recognise individuals informally in the meantime. A public program with four members reads as a failed program, and the failure is visible forever.

Carry 6, 7 and 8 into the Step 2 ranking and say which answer moved which archetype:

• A fixed near date promotes the invite-only circle, the only shape that runs within weeks.
• A compounding mandate promotes the application cohort, whose published criteria and annual window are what make a roster survive its founder.
• No engineering time deletes the points ledger outright.
• "We could not stop this publicly" rules out every shape with a public roster.

Step 1 - Check readiness before designing anything

Run these gates and report each as pass or fail. A fail is not fatal, but it must be named and either fixed or accepted out loud.

• Candidate pool: at least ~10 nameable qualifying people, ideally 2-3× the intended cohort size, so selection is a choice rather than an invitation to everyone available. Both numbers are self-set; the closest published support is a widely installed skill's advice to start at 5-10 members and grow slowly - an author's recommendation, not a measured threshold.
• Owner: one named person with recurring time. Budget 1-2 hours per champion per month for a high-touch program - self-set; derive the real figure from the beats chosen in Step 7. At that rate a 20-person cohort is close to a half-time job.
• Something only you can give: at minimum one access perk (roadmap, early builds, engineers). If the entire offer is swag, the program has no engine.
• Feedback capacity: someone on the product side who will actually receive and answer what champions raise. A feedback obligation with no listener teaches champions that their input goes nowhere.
• Conduct baseline: a code of conduct and a moderation path already exist. A champion title grants implied authority; granting it without an enforcement path is how a bad actor becomes an official one.

Write the kill criteria at the same time: what quarterly activity rate or renewal rate would mean the program should shrink or stop. Deciding this before launch is the only time it can be decided honestly.

Step 2 - Pick the intake archetype

Four shapes exist, ranked below by value per unit of effort. Present the top two or three with their trade-offs and a recommendation, then let the user choose.

• Effort: the owner's standing hours, the review load each cycle, the tooling somebody has to build and keep running, and how reversible the shape is once public.
• Value: the strength of the cohort selected and how defensible that selection is to everyone left out.

Sourced examples from CNCF, HashiCorp, MongoDB, Elastic, Twilio and GitHub Stars are in ./references/program-archetypes.md.

• efficiency: invite-only circle > award > application cohort > points ledger

• value: application cohort > points ledger > award > invite-only circle

• effort: points ledger > application cohort > award == invite-only circle

• compliance cost: points ledger > application cohort > award == invite-only circle

• Invite-only circle - private tap, 5-20 people, no public roster. Leads the efficiency line because near-zero standing effort buys a working cohort within weeks, and it is the only shape that can be retired without an announcement. Effort: near-zero - a shared document and one conversation per member. Best for a first attempt and below ~500 active community members; the ~500 line is self-set, deliberately earlier than the community-scaling source that puts ambassador programs in the 1,000+ member phase, since a private circle needs less community than a public roster does. Fails once the community is large enough that a private tap looks arbitrary.

• Award / recognition - nomination-only, closed review, fixed dated cohort. Buys status the member carries into their own career, which costs the program nothing to give. Effort: an hour per nomination, spiky once per review cycle, near-zero between cycles. Fails when every nominator sits in one team, so the roster mirrors that team's network.

• Application cohort - published criteria, one open window a year. Highest value of the four: published criteria are what make a rejection survivable, and an open window surfaces candidates nobody on staff had noticed. Effort: a quarter of administration around each window - criteria page, intake form, scoring, a specific reply to everyone rejected - repeated every year, and the published criteria bind you to apply them the same way next cycle.

• Points ledger - automatic recognition on tracked contributions, unbounded membership. Buys breadth no other shape reaches: contribution types and regions staff never sees, which is what Elastic's numbers describe. Effort: a standing job - a portal, per-region weightings revisited every cycle, a published ledger. Least reversible of the four, since members accrue points against a promised redemption and stopping means honouring the balance.

• Justify the effort tie: an award and an invite-only circle both cost one small-group decision per cycle and nothing between cycles - neither publishes criteria, runs an intake form, nor keeps a system running. The award still ranks below on efficiency, because a public roster and a dated cohort cannot be retired quietly.

• Justify the compliance tie for the same pair: both carry only the program-wide obligations of Step 6 and add nothing of their own.

• Read the compliance line as the review triggered and the reversibility spent:

  • A points ledger publishes members' activity records and awards redeemable value, pulling in gift limits, member tax exposure and a data review before launch.
  • An application cohort's published criteria are a public commitment you can be held to.
  • The other two (invite-only circle, award) add nothing beyond Step 6.

• Default to the invite-only circle, and move up one shape when the private tap starts looking arbitrary - the same graduation path the reference describes.

• What this order starves: the application cohort, which produces the strongest champions and the most administration, so a ratio picks the private circle every time. Promote it when:

  • The user wants a compounding asset.
  • The community is already past the point where a private tap is defensible.
  • A rejected candidate's public complaint would be a real problem.

• Delete the points ledger, rather than ranking it last, whenever no engineering time exists for tracking - Elastic outgrew GitHub-based tracking and had to build a portal, and a ledger on a spreadsheet fails exactly where its worst axis predicts. Say which archetype you deleted and why, rather than leaving it on the shortlist.

• Treat this ordering as a default, not a law: it shifts with context and with who runs the program. Re-rank it against what you already know - each of these moves one shape up before the default applies:

  • An existing contribution-tracking system.
  • A community team already reviewing applications for something else.
  • A founder who personally knows every candidate.

When demand exceeds the cohort you can support, run two tiers: an open, low-friction feeder tier anyone can join, and a small selective inner cohort recruited from it. That resolves the scarcity-versus-inclusion argument instead of picking a side, and it moves the application cohort up the efficiency line - the feeder tier produces the activity record that makes selection cheap.

Step 3 - Write the selection criteria in public

Before writing criteria, decide who is even a candidate. Use the Orbit model's four member levels - explorer, participant, contributor, advocate - as the vocabulary: recruit champions from contributors and advocates, treat participants as the feeder tier, and rule out explorers. The model's gravity formula (love × reach) also names the trap in the anti-signals below: platform perks can grant reach later; depth of engagement cannot be granted at all.

Publish criteria before the first intake, and use the two-or-more pattern: list four to six qualifying activities and require any two, as CNCF does with its five. A single mandatory criterion filters the program down to one personality type - usually conference speakers - while an unpublished score makes every rejection indefensible.

Adapt these to the product, keeping each one measurable:

1. Direct contribution to the project or ecosystem, with a stated floor.
2. Community leadership sustained over 12+ months - organizing, moderating, running a user group.
3. Teaching in public: talks, workshops, streams.
4. Mentorship of newcomers, in-community or through structured programs.
5. Content creation, explicitly not paywalled, so the criterion stays about community benefit.
6. Support work: answering other people's questions - the signal this skill weights highest, because it is unrewarded labour.

State the anti-signals just as plainly:

• Reach without product depth.
• Activity that begins the week applications open.
• Condescension toward beginners.
• Anyone treating the title as compensation.

Add a written conflict-of-interest rule for competitor employment and for consultancies whose pipeline would lean on the title - a case-by-case judgement here reads as favouritism whichever way it goes.

Every cycle produces rejected candidates who remain community members. Reply with the specific gap and what to build before the next window. Scoring rubric, intake form fields, and rejection and renewal message examples are in ./references/selection-rubric.md.

Step 4 - Set obligations as behaviour, perks as access

Obligations. Ask for conduct, not output:

• Follow the code of conduct.
• Be constructive with newcomers.
• Give honest feedback, including criticism.
• Respect embargoes.

Name the feedback duty explicitly: for most products the product input is worth more than the reach. Never set content quotas: they conver

...