📊 Part 5 of the DevRel Journey Series
This is Part 5 of "The Developer Advocate's Journey" series. Every post so far has leaned on numbers - developers migrated, cost savings, support ticket reductions. This post is about the discipline behind those numbers: how to tell which metric actually predicts business outcome, and which one just predicts a good-looking slide.
What you'll learn:
- 🚩 How to spot a vanity metric before a stakeholder does
- 📈 A worked methodology across four different companies and business models
- 🧮 How growth numbers and outcome numbers relate - and why you need both
- 🎯 A checklist for auditing your own DevRel reporting
The Question Every DevRel Leader Eventually Gets Asked#
At some point, a VP, a CFO, or a hiring panel asks a version of the same question: "So what did that actually do for the business?"
If the answer is a growth number in isolation - developer signups, API calls, pageviews, follower counts - the conversation usually stalls. Growth numbers describe motion. They don't describe whether that motion made the business more money, cost it less, or made its product stickier. That gap is exactly where DevRel programs lose budget, and where I've learned to close it with a specific measurement discipline rather than a bigger number.
Vanity Metric vs. Business-Outcome Metric: The Actual Distinction#
The two aren't opposites - a vanity metric is usually a real, honestly-measured number. The problem isn't that it's fake. It's that it's incomplete on its own: it tells you activity happened, not that the activity mattered.
Vanity Metrics vs. Business-Outcome Metrics
Numbers that describe volume or reach, reported without a connected outcome
✅ Pros:
- •Easy to measure and report weekly
- •Useful as a leading indicator when paired with an outcome metric
- •Good for spotting sudden drops or spikes early
❌ Cons:
- •Says nothing about revenue, cost, or retention on its own
- •Easy to inflate through low-effort activity (mass emails, content volume)
- •Doesn't survive a stakeholder's follow-up question: 'and then what happened?'
Numbers tied to a revenue, cost, or retention outcome the business already tracks elsewhere
✅ Pros:
- •Maps directly to what finance and leadership already measure
- •Survives scrutiny because it's traceable to a real ledger line
- •Compounds credibility - each proven outcome makes the next ask easier
❌ Cons:
- •Harder to attribute cleanly - DevRel is rarely the only input
- •Slower to show than activity metrics, especially in year one
- •Requires partnership with finance, sales, or product to validate
Four Worked Examples, Four Different Business Models#
The methodology only proves itself when it survives contact with real, different businesses. Here's how the same activity-versus-outcome split plays out across four companies I've actually worked at - each with a different reason DevRel existed.
Freshworks: Marketplace Ecosystem Growth#
The headline number for the Freshworks marketplace work is 10,000+ developers brought into the ecosystem from zero. That's real, and it's the number that gets repeated most often - but on its own, it's an activity metric. It doesn't say whether those developers built anything, or whether the business is better off for having them.
Freshworks Marketplace: Activity Number vs. Outcome Number
Developers Onboarded (activity)
Ecosystem size - describes reach, not value
Apps Published (depth signal)
Whether onboarded developers actually shipped something
Marketplace Revenue (outcome)
The number finance actually tracks
Community Growth Rate
A growth-rate vanity metric - meaningful only next to the revenue figure it produced
The 10,000+ developer figure earns its place in a report only when it sits next to the significant marketplace revenue and 500+ published apps it produced. A community that grew 3000% but published nothing would be a vanity number with no outcome attached. This one had both, which is what made it defensible in a budget conversation, not just an interesting chart.
Nissan: Platform Consolidation#
At Nissan, the temptation was to lead with 50+ systems integrated across nine global Sales Finance Business Units - a genuinely large number that looks impressive in a slide. But "systems integrated" is an effort metric. It describes how much work happened, not whether the business is better off.
Nissan Platform Consolidation: Effort Number vs. Outcome Number
Systems Integrated (effort)
Describes scope of work, not value created
Platform Users
Adoption depth across the consolidated platform
Deployment Speed
A leading indicator - faster releases usually precede cost savings
Operational Efficiency (outcome)
The figure that justified the consolidation initiative
The 60% faster deployment speed is the connective tissue here - it's the leading indicator that explains why consolidating 50+ systems into one platform produced meaningful operational efficiency rather than just a cleaner architecture diagram. Without that link, "50+ systems integrated" is just a description of effort expended.
Bazaarvoice: API Migration at Scale#
Migrating 50,000+ developers from REST to GraphQL is the number that sounds like the whole story. It isn't. A migration of that size that quietly broke things for a large share of those developers would be a failure wearing a big number.
Bazaarvoice GraphQL Migration: Scale Number vs. Outcome Number
Developers Migrated (scale)
Describes reach of the migration, not whether it went well
API Performance
The technical outcome developers actually felt
Support Tickets
The outcome metric that proves the migration reduced friction rather than adding it
Downtime During Migration
The number that made the scale figure trustworthy
Here, -30% support tickets is the metric that turns "50,000+ developers migrated" from a scale claim into a quality claim: the migration didn't just reach a large developer base, it left that base with fewer problems than before. That pairing - scale plus a friction metric moving in the right direction - is what makes a migration story credible instead of just large.
Oracle: Enterprise Retail APIs#
Early in my career at Oracle, the easy number to reach for was client count: 100+ retail clients on solutions I helped build. Impressive-sounding, but a client count alone doesn't tell you anything about whether the platform actually held up for them.
Oracle Retail APIs: Reach Number vs. Outcome Number
Retail Clients (reach)
Describes scale, not reliability
Cloud Migration
The outcome that actually mattered: moving legacy retail systems to cloud-native infrastructure
Database Performance
Tied to real checkout and inventory flows, not a vanity dashboard number
Project Value
The business outcome the reliability numbers made possible
For a retail platform, reliability under peak seasonal traffic is what actually matters to the client — a client count is only worth reporting alongside evidence the platform held up for them, not as a number on its own.
The Pattern Across All Four#
The Measurement Methodology: Activity → Depth → Outcome
The same three-layer check applies whether you're reporting on a marketplace, a migration, or a platform consolidation.
Start with the activity number, but don't stop there
Developers onboarded, systems integrated, API calls, developers migrated - these describe scope. They're the number stakeholders hear first, and they're legitimate context, not something to hide.
Find the depth signal that shows the activity was real
Apps published (not just accounts created), platform users (not just systems touched), support ticket trend (not just migration size). Depth signals separate genuine adoption from registration noise.
Trace it to the number finance or leadership already tracks
Revenue, cost savings, uptime tied to contract SLAs, ticket volume tied to support headcount. If you can't connect your metric to something already on someone else's dashboard, you haven't found the outcome yet - you've found another activity metric.
Lesson Learned
Thakur Ganeshsingh
The lesson that holds across every company I've measured this way: an activity number and an outcome number aren't in competition - they're different layers of the same story, and reporting either one alone leaves the story unfinished. "10,000+ developers" and "sizable marketplace revenue" are both true and both necessary. The first without the second is a vanity metric. The second without the first is a number nobody can act on, because it doesn't explain where it came from.
A Checklist for Auditing Your Own DevRel Reporting#
Whether you're building a stakeholder deck or evaluating a DevRel hire's resume, the same audit works in both directions.
Run This Against Any DevRel Metric Before You Report or Trust It
If a failed initiative could still produce this exact number, it's measuring activity, not outcome
Signups need a 'did they actually use it' number nearby - published apps, active integrations, retained accounts
Revenue, cost, support headcount, SLA compliance - if finance or support would recognize the number, it's an outcome metric
Scale claims (developers migrated, calls per day) need a reliability or friction metric alongside them, not just a bigger scale claim
DevRel is rarely the only input to revenue or retention - name the other contributing teams rather than claiming sole credit for a shared outcome
For Hiring Managers: Reading a DevRel Candidate's Numbers#
If you're evaluating a DevRel hire, the same three-layer check applies to their resume. A candidate who leads with "grew a community to 10,000 members" and stops there hasn't told you whether that community did anything for the business they were at. A candidate who can walk you through the activity number, the depth signal underneath it, and the business outcome it produced - even an imperfectly attributed one - has demonstrated the actual skill DevRel leadership requires: connecting developer-facing work to something the business can act on.
That's the distinction this whole post has been building toward. Vanity metrics aren't dishonest. They're just half a story. The other half is the discipline to keep asking "and then what happened?" until you reach a number someone outside DevRel already recognizes as real.
Next in the series: "Developer Experience Audit: A Systematic Framework for Evaluating and Improving DX"
How does your organization measure DevRel impact? I'm curious whether the activity/depth/outcome split holds up in other business models - share what's worked (or hasn't) in the comments.
Want more honest lessons from a decade across engineering and developer relations? Subscribe to get each new post in this series.
