This is the third post in a series on DevRel success measures. Read the introduction here and my OKR learnings here.
As I mentioned in the introduction, Developer Relations sits at the unique intersection of Product Marketing, Product Management, and Engineering. You will partner with and across multiple stakeholders simultaneously – bringing your unique insights and experience to improve each part of the business. To make the most of these internal relationships, you need find [and express] your unique value in an ever-changing environment.
Sitting at these crossroads brings organizational fluidity – the reality that what you do (and how you do it) will evolve as the product and market shifts. Your team may move between departments, the needs of your stakeholders will continually evolve, and your priorities might change as often as quarterly.
Rather than fighting this reality, a key career learning for me was how to better embrace that change. Specifically, learning to communicate two parts of my work:
- My unique position within the company that can remain constant over time
- My current business priorities that can adjust as organizational needs change
What I like about this two-part approach is that it enables you/me to communicate consistent role with relevancy to the current business challenge. It makes it easy for anyone/everyone in the company to remember your ‘why’ in a meaningful way.
This post explores how you can build these two parts, with some starter models to help tease out the right success measures. You can then use these insights and learnings to build your OKRs using the framework from the last post.
Part 1 – Defining your unique value to the company
First, let’s tackle the messy part – defining your value to the company is a particularly perplexing challenge for the DevRel profession.
While most of your internal stakeholders have clear roles to play – they build stuff, they ship stuff, or they sell stuff – each DevRel team is as unique as the team members that make it up. DevRel teams (and people that compose them) often wear multiple hats – attending events, creating blog content, nurturing communities, writing code samples or documentation, engaging on social, helping customers, writing SDKs, or more. While the fluidity of the role enables adaptability, it creates measurement challenges that the traditional metrics used by your stakeholder departments can’t address.
This, unfortunately, means that it’s up to you to find and define your unique position within the context of your team and company. A sad truth is that if you’re not comfortable with ambiguity, DevRel may not be the best career choice for you.
And to do this, I like to look at two things – looking at what you do and where you do it.
Part 1a – What do you do?
What do you do that nobody else in the company does? This becomes your measurement anchor point that remains stable while the world may change around you. As we discussed in the prior post, your differentiated value should be the core of your primary OKR objective, ensuring that it remains relevant over time.
At its core, DevRel builds better developer experiences while supporting business growth. This balanced, dual focus should help you maintain relevance as business priorities shift between growth, retention, and expansion. Digging into this a bit more, how you do this will likely depend on where you operate in the customer journey:
- Developer-first products (APIs, platforms, infrastructure) require DevRel to focus on adoption, engagement, and ecosystem growth. Your metrics likely emphasize user activation, community health, and platform usage.
- Developer-plus products (business tools or platforms with developer components) need DevRel to focus on influence and enablement. Your metrics likely emphasize consumption/usage growth, technical validation, and cross-functional support.
Part 1b – Where do you report?
In addition to what you do, I have found that understanding your reporting structure adds texture to your unique value definition and makes it easier for your leadership to understand how resourcing your team benefits their priorities.
DevRel in Marketing organizations
Marketing teams create campaigns and measure conversion, while DevRel teams within them will often create the authentic technical content that powers those campaigns and build genuine community relationships that shape those funnels.
- Suggested focus: Top-of funnel engagement and influenced pipeline
- Supporting approaches:
- Partner with demand generation to leverage DevRel content
- Create reusable technical content for broader marketing campaigns
- Build nurture content for newsletters that grow adoption and customer advocacy
DevRel in Product organizations
Product teams design features and track adoption, while DevRel teams within them provide real-world developer feedback and validate user experience assumptions.
- Suggested focus: Developer experience and product feedback loops
- Supporting approaches:
- Serve as Developer[0] for early product validation
- Provide Developer[n+1] insights from community engagement
- Partner with Product Management on developer experience improvements
- Bridge technical feedback into product roadmap decisions
DevRel in Engineering organizations
Engineering teams build reliable systems, while DevRel teams within them may validate usability and translate technical complexity into accessible guidance.
- Suggested focus: Technical community building and platform contributions
- Supporting Approaches:
- Focus on technical depth and engineering excellence
- Measure community code contributions and open source engagement
- Partner with engineering on technical documentation and samples
- Emphasize long-term technical relationship building
Part 2 – Defining your current business priorities
The second question should be more straight-forward – what are top existential risks/priorities that you are tackling to advance your part of the business? By design, these should be priorities achievable in 6-12 months with progress that is measurable monthly.
After expressing your consistent, resilient value to the business, this expresses the immediate value you’re advancing – challenges that are top-of-mind for your stakeholders and outcomes that they’re invested in. This provides a regular drumbeat of progress that your stakeholders want to hear about.
A few common examples:
- Establishing a developer community (e.g., local, digital, social)
- Building and executing an editorial calendar across stakeholders – aligning engagement and product launches
- Launching a developer portal / microsite
- Developing an authentic developer experience at a company event
- Supporting a major launch (e.g., docs, code samples, feedback, etc.)
The key principle to defining your priorities is to pick your top 1-3 priorities. This focus on a limited number helps you with both work prioritization and clear stakeholder communication.
To help you prioritize, you can score your current list of priorities on four dimensions:
- Business criticality: Does this address a current organizational pain point?
- DevRel ownership: Can your team meaningfully impact the outcome?
- Measurable progress: Can you show monthly advancement toward the goal?
- Stakeholder relevance: Do your key stakeholders care about this outcome?
The key here is disciplined prioritization. To be meaningful and remembered, your list needs to be limited and consistent as you beat your drum of progress.
Implementation tips
As you work to define your unique value proposition, below are a few pro tips:
- Stakeholder translatability: Ensure your core activities can be presented to different stakeholders with relevant context. For example, community growth becomes pipeline potential for Marketing, user feedback for Product, and platform engagement for Engineering.
- Resiliency: Create core measurements that reflect DevRel’s fundamental value regardless of organizational placement. Developer satisfaction, community health, and platform adoption remain relevant across all reporting structures.
- Contextually flexible objectives: Use the OKR framework [discussed previously] to adapt quarterly priorities while maintaining consistent measurement disciplines. Your objectives provide stability while key results adapt to changing organizational needs.
- Audit for alignment: And before finalizing framework:
- Map key stakeholders and understand their primary success metrics
- Identify metric intersections where DevRel activities serve multiple organizational goals
- Design dual-purpose measurements that demonstrate value across different perspectives (see ‘stakeholder translatability’)
- Document your rationale to maintain consistency through changes/time
Reminder – Be your developer’s advocate
As one final reminder – DevRel’s unique position allows you to propose innovative measurements that reflect your cross-functional value. Resist defaulting to easily trackable metrics that miss your actual impact. Instead, advocate for measures that capture true audience impact:
- Developer experience improvements that reduce support burden
- Community insights that inform product roadmap decisions
- Technical content that accelerates sales cycles
- Platform adoption that increases customer stickiness
Remember that your organizational fluidity is a feature, not a bug. Use your unique position at the organizational cross-roads to create value for your audience that your stakeholders will miss simply because their traditional KPIs don’t align with this value-creation.
Moving forward
Successful DevRel measurement requires that you embrace your unique position rather than conforming to existing departmental frameworks. Remember that there’s no universal “correct” way to measure DevRel success, there is only what is correct for your team, your organization/product, and your current business context.
Coming next: “Lesson 3: Communicate Relentlessly” – how to ensure stakeholders understand and remember your value through effective metrics communication and storytelling.
