10 TACTICS ✣
Ambassador and Champion Programs.
Structured recognition programs for the company's most engaged external community members. When designed well, they are among the highest-leverage tactics in DevRel — multiplying the company's reach through people who genuinely love the…
Structured recognition programs for the company’s most engaged external community members. When designed well, they are among the highest-leverage tactics in DevRel — multiplying the company’s reach through people who genuinely love the product. When designed badly, they corrode trust and turn community goodwill into transactional exchange.
What these programs are
Variously called:
- MVPs — Microsoft, since 1999.
- Heroes — AWS (since 2014), GitLab.
- Champions — MongoDB, IBM, Salesforce.
- Experts — Google (GDE), Cloudflare.
- Ambassadors — HashiCorp, Snyk, Auth0, Datadog, MuleSoft, NVIDIA Inception (startups).
- ACEs — Oracle (four-tier).
- Stars — GitHub.
- Innovators / Wavemakers / Squad / SupaSquad — Snowflake, DigitalOcean, Supabase.
The common pattern: a vendor identifies external community members making outstanding contributions, recognises them publicly, and provides benefits that empower them to continue.
What good programs share
- Selection is meaningful. Either nomination-based or rigorous application; not “anyone who fills the form.”
- Recognition is visible. A public directory, a badge, a title.
- Access is real. Early product access, direct lines to engineering and product, advisory-board-style participation.
- Career value is real. Speaking opportunities, content amplification, visibility that matters when changing jobs.
- Reciprocity is balanced. Members give time; the company gives access, visibility, swag, and (where appropriate) money.
- Terms are bounded. Annual renewal cycles prevent calcification.
What kills programs
- Treating members as a marketing distribution channel. “Could you tweet about our new feature?” gets old fast.
- Inconsistent staffing. A program manager who departs and is not replaced.
- Recognition gap. Members feel less recognised over time as the company scales.
- Selection drift. Standards fall; original members feel devalued.
- Failure to deliver promised benefits. Promised early access that never materialises.
- Acquisition or restructure. The program manager is gone; the program staggers on.
Design choices
Open vs. selective?
- Selective programs (Microsoft MVP, AWS Heroes, GDE, MongoDB Champions) produce status value.
- Open programs (AWS Community Builders, DigitalOcean Wavemakers) build pipelines into selective programs and reach more emerging contributors.
Most large companies run both — emerging-talent program and elite recognition program.
Multi-track?
Some programs have multiple tracks for different contribution types:
- Supabase SupaSquad — Contributor, Content Creator, Trusted Host, Event Speaker.
- Oracle ACE — Apprentice, Associate, Pro, Director (tiers).
- IBM Champions — Multi-domain badges + Champion status.
Multi-track allows the program to recognise diverse forms of contribution.
Term length?
- Annual renewal (Microsoft MVP, AWS Heroes, Oracle ACE) is standard.
- Lifetime status is unusual and risky — calcifies the membership.
- Multi-year terms (Cloudflare Developer Experts) are intermediate options.
Geographic distribution?
For global programs:
- Regional ambassadors representing distinct markets.
- Local user-group support alongside the headline program.
HashiCorp Ambassadors span 31 countries; AWS Heroes span 57. Geographic diversity is both signal and outcome.
Benefits that work
In rough order of impact:
- Direct line to product and engineering. The single most-valued benefit by most program members.
- Early access. Beta features, previews, design feedback opportunity.
- Visibility. Featured in company blog, conference speaker placement, social amplification.
- Access to other members. A private Slack/Discord, an annual summit.
- Conference travel sponsorship. When members give talks about your product.
- Swag with actual taste. Generic t-shirts are insulting; well-designed members-only items work.
- Cash / vouchers / credits. Often controversial; works for some programs (AWS credits to Community Builders); risks transactional dynamics elsewhere.
- Career visibility. Reference letters, intros to recruiters at member-employer firms.
Benefits that don’t work:
- Vague “exclusive content” (members can usually find the info elsewhere).
- Webinars-only. Members already have access to public webinars.
- Discounts on products members don’t buy (developer-individual members usually aren’t the buyer).
Common program-management failures
- No dedicated program manager. Programs need an owner. Without one they decay.
- Slow nomination cycles. Inbound nominees go cold during long evaluations.
- Inconsistent recognition cadence. Some quarters celebrated; others silent.
- No clear path from emerging-talent to elite program. Community Builders should know how to become a Hero.
- Overlapping internal advocate work. Confusing whether company employees or ambassadors take a speaker slot.
Measurement
Track per program:
- Member count and renewal rate.
- Member-generated content volume (talks, posts, videos).
- Reach of member-generated content.
- Product feedback received through the program.
- Member-influenced revenue (where measurable).
- Member NPS. This is critical — your members can leave.
Member NPS is the leading indicator
If your members’ satisfaction is declining, every other metric will follow within 12 months. Survey members at least twice a year. Act on the feedback visibly. The decay-detection point is the place to intervene.
Sizing
How big should an ambassador program be? Some reference points:
- Microsoft MVP — ~4,000 globally across hundreds of technology areas.
- AWS Heroes — ~270 (very selective).
- Google Developer Experts — ~1,000 in 85 countries.
- MongoDB Champions — Several hundred.
- HashiCorp Ambassadors — ~100 in 31 countries.
- Cloudflare Developer Experts — Smaller, dozens.
- Oracle ACE — Several hundred across tiers.
Smaller-and-selective tends to produce more visible value per member; larger-and-inclusive tends to produce more aggregate reach. There is no single correct size.