New DevRel programs

This chapter gives founders and DevRel managers a practical sequence for building a function, including the first hires, minimum infrastructure, and measures for each stage.

Step 0: Decide whether you actually need DevRel

Before any hiring, confirm:

  • Are developers your decision-makers, integrators, or amplifiers? If not, you may not need DevRel as a function: technical marketing and customer engineering may suffice.
  • Do you have a product that developers actually want to use? No DevRel program compensates for a product that fails for its target audience.
  • Are you willing to invest beyond one hire? Lone-evangelist programs fail. Plan for at least 2 to 3 people within 18 months.

Proceed only if all three conditions hold. Otherwise resolve the product, audience, or investment question before hiring.

Step 1: Articulate the strategy (before hiring)

Write a one-page document covering:

  • What goals from AAARRRP does DevRel serve at this company stage? Most likely a subset: often Awareness, Acquisition, Activation, and Product for early-stage; Retention and Referral added later.
  • Who is the target developer? Specific persona: stack, seniority, employer type, geography.
  • What is the success metric? Pick one to two for the first six months.
  • Where does DevRel report? Decide deliberately.

If you cannot answer these, you are not ready to hire.

Step 2: First hire: a Community Manager (or generalist with community lean)

The first DevRel hire should usually be a Community Manager or community-focused generalist.

Why:

  • Advocacy needs a maintained channel where interested developers can ask questions and continue participating.
  • Communities take months to establish, so starting early allows time to recruit members and develop operating norms.
  • A high-profile advocate is a risky first hire when support, documentation, and community operations are not yet in place.

What to hire for:

  • Community-management or technical-community experience.
  • Some technical credibility (can use the product, hold technical conversations).
  • Communication-craft excellence.
  • Empathy and operational discipline.

Within the first three months, this person should:

  • Build the community infrastructure (Discord / Slack / Discourse, depending on context).
  • Operate consistent presence (welcome new members, answer questions, run office hours).
  • Identify the first 20 to 50 highly engaged community members and develop relationships with each.
  • Document common questions and friction points.

Step 3: Second hire: a Developer Advocate / Evangelist

Once community operations exist, the Advocate produces public content, demos, and talks.

What to hire for:

  • Demonstrated public portfolio (blog, talks, video).
  • Engineering background; can credibly use the product.
  • Communication craft; writing-and-speaking competence.
  • Cultural alignment with the target developer audience.

Within the first three months, this person should:

  • Audit existing docs, samples, content; identify gaps.
  • Publish substantial first-flag content (e.g. quickstart improvements, a major blog post, a sample app).
  • Establish a content cadence the team commits to.
  • Begin conference-speaker submissions.

Step 4: Third hire: Developer Educator / Technical Writer

With community and publishing operations in place, the Educator owns documentation structure and the maintenance of learning material.

What to hire for:

  • Technical writing experience.
  • Information-architecture instinct.
  • Ability to code, even if not primary skill.
  • Calm operational temperament.

Within the first three months, this person should:

  • Restructure docs around Diátaxis (Tutorial / How-to / Reference / Explanation).
  • Audit and remove stale content.
  • Build a tutorial pipeline.
  • Improve the quickstart specifically: TTFHW is now a tracked metric.

Step 5: Operational infrastructure (parallel)

While hiring is happening, build:

  • A 12-month content roadmap mapped to AAARRRP goals.
  • Measurement instrumentation for at least three metrics from each of Layer 1 (program), Layer 2 (community), Layer 3 (activity).
  • Cross-functional touchpoints. Weekly sync with PM; monthly review with VP-level stakeholders.
  • A documented internal-feedback flow from community to product.
  • A starter ambassador / community-recognition program (don’t formalise until you have enough community to draw from: usually around 12 months in).

Step 6: Director or Head of DevRel

When the team is 3 to 5 people, install management. Without this, the team’s strategy can drift, cross-functional integration suffers, and senior individual contributors burn out as default managers.

What to hire for:

  • Prior senior DevRel leadership experience.
  • Strategic and operational thinking.
  • Comfort with executive-level reporting.
  • Coaching ability for the IC team.

If you cannot find a great Director hire, promote internally if a candidate is ready, or hire a more senior individual contributor (Staff or Principal level) with leadership potential.

Step 7: Expand by specialisation

After the core four roles, expand by specialisation:

  • Domain-specific advocates (AI, mobile, data, security) as appropriate.
  • Regional advocates if you have meaningful international audience.
  • Developer Marketing Manager for launches and distribution.
  • Community Program Manager for the formal ambassador / champion program.
  • Developer Success Engineer for activation-deep work.

What not to do

  • Do not hire a Principal-level evangelist as your first DevRel hire. Too expensive; no audience yet; structural mismatch.
  • Do not leave community operations unowned. Advocacy generates questions and participation that require follow-up.
  • Do not let the founder be the only DevRel for a year. Founders are great early voices, but founder-only DevRel does not scale and creates dependency.
  • Do not skip strategy. Without stated goals, hiring and activity cannot be evaluated against the business need.
  • Do not over-promise to executives. Be specific about what you can deliver in months 1 to 6 vs. months 6 to 18.
  • Do not optimise for vanity metrics in the first six months. Followers and stars do not measure activation, retention, support quality, or contribution.

Realistic timeline

MonthOutcomes
1 to 2Strategy locked; first community hire identified
3 to 6Community Manager in place; community space launched; first 50 engaged members
6 to 9Advocate in place; content cadence established; quickstart improvement shipped
9 to 12Educator in place; docs restructured; first measurable activation lift
12 to 18First three hires productive; Director hired; first ambassador-program members identified
18 to 24Team of 5 to 7; specialisation begins; influenced-pipeline measurement begins

Plan 12 to 18 months for the first three hires and initial programme. More staffing can shorten parts of the schedule; unclear strategy or delayed hiring will extend it.

What success looks like at 12 months

If the program is on track at month 12, the following are visible:

  • Measurable improvement in activation rate or TTFHW (the specific metric depending on goals).
  • An active community with at least monthly net positive contributor growth.
  • A weekly publishing cadence producing at least one substantial public artefact per week.
  • A recurring product-feedback review with decisions and resulting product changes recorded.
  • Executive recognition of the function’s value, defensible with data.
  • Hired three of the four foundational roles.

If these are not visible at month 12, the program has either been under-resourced or has had strategic clarity problems. Diagnose before doubling down.

See also