DevRel Strategy & Leadership

Building a DevRel function from zero starts with company goals, not tactics.

1. Understand the business: company goals, target developers, product maturity and go-to-market motion. Interview leaders in product, engineering, marketing and sales.
2. Write a mission: one sentence connecting developers' success to company success.
3. Pick a focus: you can't do everything. Early-stage products often need DX and content; mature products may need community and advocacy programs.
4. Define metrics (North Star plus supporting) and a reporting cadence.
5. Plan resources: people, budget (events, tools, swag, travel) and dependencies.
6. Run a 90-day plan: quick wins to build trust, one foundational program and a first report.

Present it as a strategy doc with clear asks. Mary Thengvall's advice, "first, understand the company goals", is the most important step.

OKRs (Objectives and Key Results) connect ambitious objectives to measurable results.

• Objective: qualitative and inspiring. "Make our platform the easiest way for Python developers to add real-time features."
• Key results: 2–4 measurable outcomes. "Reduce Python time-to-hello-world from 15 to 5 minutes", "Increase 30-day retention of Python sign-ups from 20% to 30%", "Grow member-answered community questions from 30% to 50%".

Good DevRel OKRs:

• Are outcomes, not activities ("give 10 talks" is a task, not a key result)
• Ladder up to company OKRs visibly
• Mix leading indicators (you can influence now) and lagging ones (business results)
• Are few: 2–3 objectives per quarter

Review progress monthly, grade at quarter end and learn. Measure What Matters and John Doerr's TED talk are the canonical introductions.

Senior DevRel turns developer and community data into strategic recommendations executives can act on.

The shape of a strong insight:

• Observation: what you see ("40% of churned trial accounts never created a second project")
• Evidence: data plus developer quotes
• Interpretation: why it's happening
• Implication: why it matters to the business
• Recommendation: what to do, with options and trade-offs

Deliver insights regularly (a quarterly "state of the developer" report works well) and target the right audience: product for roadmap, marketing for positioning, leadership for strategy. Over time, being the person with the best understanding of developers makes you a strategic partner rather than a service function.

DevRel depends on other teams to succeed, and rarely has authority over them. Influence without authority is the core senior skill.

Relationships to build:

• Product: feedback loops, roadmap input and launch planning
• Engineering: technical accuracy, SDKs, docs contributions and bug escalation
• Marketing: positioning, campaigns, events and content distribution
• Sales and success: customer insights, technical enablement and developer-qualified signals
• Support: common issues, docs gaps and community routing

How to influence:

• Understand each team's goals and pressures; frame your asks in their terms.
• Give before you ask: share insights, help with launches, make their work easier.
• Make it easy to say yes: clear, small, well-evidenced requests.
• Establish rituals: monthly syncs and shared dashboards.

Hiring well is the highest-leverage thing a DevRel leader does.

• Hire for the strategy: match roles to your priorities (DX engineer, community lead, educator, advocate).
• Write clear JDs: outcomes the person will own, the skills required vs nice-to-have and who they'll work with. Avoid "rockstar" and unicorn lists.
• Interview for real work: a portfolio review, a short technical exercise (explain an API, review a doc), a presentation, and a community scenario.
• Evaluate: technical credibility, communication, empathy, judgment and self-direction.
• Onboard deliberately: a 30-60-90 plan, stakeholder introductions and early wins.
• Grow people: career ladders with clear expectations per level, regular feedback, and sponsorship for speaking and visibility.

Diversity matters practically: a team that reflects the developer community reaches more of it.

DevRel attracts endless requests: "Can you speak at this?", "Can you write a post about that?", "Can you join this call?". Without ruthless prioritisation, you'll be busy and ineffective.

Tools:

• Impact vs effort: score requests; say yes to high impact and low effort, plan high/high, decline low impact.
• Strategy filter: "Does this serve our OKRs?" If not, the answer is usually no, or later.
• Intake process: a simple request form with goal, audience, deadline and success measure. It makes trade-offs visible.
• Capacity planning: reserve time for planned programs, reactive work and learning.
• Saying no well: "Not this quarter, because we're focused on X. Here's what would change that."

Ship consistently. A predictable rhythm of good work builds more trust than occasional heroics.

Technology, developer behaviour and the DevRel profession all change quickly. AI-assisted development, for example, is changing how developers discover and learn tools.

Build a learning system:

• Curated inputs: DevRel Weekly, industry newsletters, the Stack Overflow survey and your ecosystem's release notes.
• Communities: DevRel communities, DevRelCon and local meetups.
• Hands-on time: build with new tools monthly; your credibility depends on it.
• Reflection: a short monthly note on what changed, what it means for your developers and what you'll try.
• Share it: turn your learning into content, which reinforces it and helps others.

Block time on your calendar for learning. If it's not scheduled, it won't happen.

Senior practitioners develop a sense for what developers are feeling, often before the data shows it.

Practices:

• Listen more than you post: read community channels, forums, social media and competitor communities daily.
• Hallway conversations: at events, ask open questions ("What's the hardest part of your week?") and listen.
• Pattern tracking: keep a running log of recurring themes, frustrations and excitement.
• Sentiment reviews: periodically summarise the mood in your community and ecosystem for your team.
• Watch the edges: new communities, emerging tools and where early adopters are moving.

Translate what you hear into strategic signal: "Developers are increasingly asking about X. Competitors have started Y. I recommend Z."

Champion, ambassador and MVP programs turn your most engaged developers into an extension of your team, multiplying reach far beyond headcount.

Design:

• Purpose: what do you need (content, local events, community answers, product feedback), and what do champions get (recognition, early access, growth, community, swag, travel)?
• Criteria: clear, public criteria for joining, based on contributions not follower counts.
• Tiers: optional levels that reward sustained contribution.
• Support: onboarding, a private community, regular calls, content and speaking support, and direct lines to product.
• Expectations: light and flexible. These are volunteers.
• Measurement: champion-created content, events, answers and influenced sign-ups, plus champion satisfaction and retention.

Good programs are relationships, not transactions. Invest in champions' growth and they'll invest in your community.