DEV Community

Cover image for DevRel != DevRel
Michael Palermo
Michael Palermo

Posted on

DevRel != DevRel

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.

Latest comments (2)

Collapse
 
andypiper profile image
Andy Piper

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.

  • reporting line to engineering: direct connection between engineering and product, and the developer community
  • reporting line to marketing: technical angles to enable marketing messaging
  • reporting line to biz dev/finance: strong business focus around platform enabling new business sales and opportunities

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!

Collapse
 
andypiper profile image
Andy Piper

Related: the annual State of DevRel report just got published yesterday, always an interesting read!