I can not count the number of times I have had to explain what "Developer Relations" is. At an abstract level, DevRel is a service of a company/product that engages with developers in a manner that yields mutual benefits. Examples of activities/deliverables that are usually associated with DevRel include blogs, videos, meetups, presentations, hackathons, and so forth. So are all DevRels basically the same? No.
What makes one DevRel different than another if both seem to be producing the same kind of activities/deliverables? I invite you to consider the following points that are distinguishing factors:
Scope of Work
The potential of what DevRel could do is so much! While some companies reserve DevRel for evangelism/advocacy activities only, note many of the initiatives that could be brought into scope:
- Product feedback
- Community building
- Ambassador/Champion program
- Forum support
- Presales support
- Social media engagement
- Documentation
- Self-Serve (developer experience)
- Tooling (utilities, IDE extensions)
- Integrations (platforms, marketplaces, directories)
- Developer Marketing
- Events (conferences, meetups, hackathons)
- Technical artifacts (code demo, apps, configs)
- Content (blogs, tutorials, decks, videos)
- Live Streaming
And I am sure I forgot something. Needless to say, so much could be done. Oftentimes, some of the items listed above are directly handled by other teams in a company. Examples include presales support, developer marketing, tooling.
How would DevRel know which items to take on, which to prioritize? This leads to our next points.
Available Resources
Available resources include people and budget. How big is the team? Is it possible to create cross-functional teams with others in the company? Could contractors be utilized? Is there budget for travel, events, merchandise? Is there budget for tooling/equipment, software if needed? DevRel can only scale to the extent it has available resources.
Measurement
Perhaps one of the greatest differentiators between one DevRel to another is how they determine how to measure success. I have observed some in DevRel that measure activities (# blogs, # views, # presentations, # likes, # comments, etc.) of which might be valuable metrics, but should never be the goal. I have also seen (and have been part of) DevRel that puts a revenue number on the group. Depending on the scenario there may be benefit, but I feel that should not be the goal either.
What should be the goal, the "north star" of DevRel? There is no single answer, but if it speaks to growth of users or activities, it is likely on track. Here are some examples:
- Number of new users who joined over a period of time
- Increase of overall product activity or downloads
- New logos (companies)
- Increase of monthly active users
I have seen many variations, but the idea is that DevRel promotes engagement with product.
Domain
The kind of company/product also separates one DevRel from another. The strategy to gain blockchain developers will likely vary greatly from a strategy to gain enterprise DevOps. Some products have wide appeal to the masses, others are very niche.
In conclusion, I posit that not all DevRels are the same. Factors that contribute to a DevRel's identity include scope, available resources, how it is measured, and the domain it is targeting. Trying to compare one DevRel to another could be like comparing apples to oranges.
Top comments (2)
Absolutely.
In my ~15 years in DevRel roles I've worked in teams with similar missions but attached to completely different parts of the org. Lots and lots to unpick, particularly around goals and roles, but broadly I've worked in these different sorts of pillars.
In each of these cases though, it's also a hugely cross-functional and multi-skilled position, which is among the many reasons that I've stuck with it as a career!
Related: the annual State of DevRel report just got published yesterday, always an interesting read!