Ambassador programs | DevRel Almanac

Ambassador programmes recognise and support external community members who contribute to a product or technical community. They can extend peer support, teaching, and local event coverage, but poorly specified obligations can make participation feel like unpaid promotional work.

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 substantial contributions, recognises them publicly, and provides benefits that support continued participation.

Selection uses criteria. Use nominations or assess applications against contribution, conduct, and programme-fit requirements.
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.
Benefits match the requested contribution. Account for members’ time, travel, expertise, and public work through access, visibility, merchandise, or payment where appropriate.
Terms are bounded. Annual renewal cycles prevent calcification.

Causes of programme decline

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 programme manager leaves without a successor, and benefits, communication, or reviews stop.

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. Track whether the programme covers the regions it intends to support.

Benefits that work

In rough order of impact:

Direct line to product and engineering. Often among the benefits programme members value most.
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.
Useful or well-designed merchandise. Offer member-only items rather than defaulting to generic T-shirts.
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. Use it alongside interviews and renewal rates to identify dissatisfaction.

Member satisfaction as an early indicator

Survey members at least twice a year. If satisfaction declines, check renewal and participation, publish the findings, and state which programme changes will follow.

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.