Every day, millions of developers make decisions that impact which technologies their companies adopt. When Stripe grew from $5B to $95B in valuation, it wasn't through traditional enterprise sales, it was by winning over developers. When MongoDB displaced established relational databases, it wasn't through golf course meetings, it was through developer advocacy.
DevRel, or developer relations, is how modern companies build authentic, mutually beneficial relationships with the developers who increasingly drive technical decisions. It's no longer enough to have great technology—you need developers to discover, trust, and champion your solutions.
But developer relations isn't just about marketing products to developers. Companies invest in DevRel for many strategic reasons, each requiring its own approach and measurement of success. And before we get into the day to day of what DevRel people do, we should look at those strategic drivers because understanding them is the key to being successful in DevRel.
The strategic drivers of DevRel
While API adoption is the most visible part of DevRel, successful programs serve multiple strategic goals that go beyond just getting developers to use a product.
Most companies invest in DevRel because they want to affect:
- Adoption: This is effectively marketing to developers to encourage them to adopt a product and to build with it. Most DevRel programs have this as at least one of their strategic priorities.
- Contribution and ecosystem: Whether it's coordinating the development of an open source project or working with partners to create integrations, DevRel teams often focus on building and nurturing a wider ecosystem around their technology.
- Product-market fit: By maintaining close relationships with developers, DevRel teams provide feedback to their product and engineering colleagues about what developers need and how they actually use the product in practice.
- Developer enablement: Getting developers interested in and experimenting with a product is only useful if they can then get to work with it. Enablement covers education, docs, SDKs, and similar.
- Employer brand: Attracting top engineering talent is increasingly competitive. A strong DevRel presence can position a company as a place where developers want to work, helping to build an employer brand that stands out.
In practice, DevRel programs tend to mix at least a couple of these strategic goals.
The Four Pillars of Developer Relations
Understanding why companies invest in DevRel shows us what the DevRel team should do. But because DevRel is quite varied, it's helpful to put those practical activities into broad groups. Those groups are the four pillars of DevRel:
Developer advocacy: Acting as a two-way bridge between your company and developers, representing the developer perspective internally while also helping external developers understand your technology.
Developer marketing: Developer marketing is about reaching the right developers, surfacing your technology at the right time, and making sure they understand its value.
Developer enablement: Creating everything developers need to be successful with your product, from clear documentation and SDKs through to training materials and support processes.
Developer community: Building and nurturing spaces where developers can learn from each other, share their experiences, and collaborate around your technology.
Each pillar supports the others. For example, a strong community creates authentic marketing opportunities, while good enablement materials give advocates the tools they need to help developers succeed.
The right balance depends on what your company needs most. If you’re driving API adoption, you might prioritize marketing and enablement to lower friction for new users. If you’re fostering an open-source ecosystem, community and advocacy take center stage. The most effective DevRel programs adjust their mix over time as the needs of the business evolve.
Day to day DevRel
With those four pillars in mind, what does DevRel actually look like in practice? As with everything in DevRel, it'll vary from company to company but here are some of the most common activities, mapped to the four pillars:
Developer advocacy:
- Speaking at conferences and meetups to educate and inspire developers
- Writing technical blog posts, tutorials, and sample code to demonstrate use cases
- Providing product feedback from developers to internal teams
Developer marketing:
- Creating and distributing content that helps developers discover and understand the product
- Running campaigns, newsletters, and social media efforts targeting developer audiences
- Collaborating with product and marketing teams to refine messaging and positioning
Developer enablement:
- Maintaining SDKs, APIs, and documentation to ensure smooth onboarding
- Running workshops, webinars, and hands-on training sessions
- Building and improving developer tools, integrations, and starter templates
Developer community:
- Moderating forums, Discords, or Slack groups to support peer-to-peer learning
- Organizing hackathons, ambassador programs, or meetups to strengthen engagement
- Supporting open-source contributions and third-party integrations
This isn’t an exhaustive list but it gives you a picture. In many teams, didn't blends of these activities are now recognized as specific roles: Developer Educator, DevRel Engineer, Developer Advocate, and so on.
Measuring developer relations
DevRel teams face a common challenge: proving their impact while also gathering the operational data they need to work effectively. The key is understanding different types of metrics and how they work together.
DevRel teams need two distinct sets of metrics. Strategic reporting metrics demonstrate the program’s value to the wider organization, while operational metrics help the team optimize their daily work.
For example, a company might track monthly active users (MAU) as a core business metric to measure product adoption. However, MAU is influenced by multiple teams—marketing, product, and DevRel—so it’s not specific enough to reflect DevRel’s direct impact.
Instead, a DevRel team focused on API adoption might report on the specific engagement metrics that contribute to MAU growth, such as:
- Documentation engagement: Unique visitors to key documentation pages, time spent, and completion rates for getting started guides.
- Developer activation: Percentage of new sign-ups who create an API key, make their first API call, or complete a tutorial.
- Community engagement: Participation in forums, Discord/Slack activity, or open-source contributions.
- Content impact: Views, shares, and referrals from DevRel-produced technical blogs, talks, or videos.
One or two of these could act as reporting metrics to show how the DevRel team contributes to MAU, with the others serving as operational metrics to help identify the impact of the team's work at a more granular level.
Covering DevRel metrics in detail is the job of another article entirely. However, the key thing to know is that what a DevRel program measures and reports depends entirely on why the business is investing developer relations.
Where DevRel fits
You'll find DevRel teams in the marketing, product, and engineering departments of companies. Less often, there might be a dedciated community or DevRel department that reports directly to the C-suite or you'll see a DevRel team reporting to a sales leader.
The department that a DevRel team finds itself in will almost always influence its mission. And the same is true the other way. The company's reason for investing in DevRel will influene which department the team finds itself in.
Beyond the department, there are a couple of other ways of thinking about how DevRel fits into the organization. First, it's useful to consider the role that developers play for the company, such as:
- Whether developers are the primary users of their product (like Stripe or MongoDB) or are part of a broader user base (like Salesforce or Adobe).
- If their developers are decision-makers who select technology or implementers who work with prescribed tools.
Another way of thinking about that is to divide companies into those that are developer-first (that is, developers are the primary audience for the company) or developer-adjacent, where developers are just one of the audiences that the company considers.
It's worth noting that DevRel functions aren't always found it just one team. For developer-first companies, DevRel might be a shared responsibility, for example. Typically, you'll find the following organizational models:
- Vertically integrated DevRel: A single department or team takes care of every aspect of a developer’s engagement with the company, only collaborating with specialist departments (such as engineering or marketing) when there’s a beneficial overlap.
- Core DevRel: The developer relations team takes care of those functions that wouldn’t happen otherwise, such as developer community, but leaves other aspects to specialised teams (e.g. engineering, marketing, product).
- Company-wide DevRel: There isn’t a specific team or department for developer relations but, instead, DevRel happens throughout the company.
DevRel is about serving developers
Developer relations is a varied profession that can look very different depending on where it is practised. But its core characteristic is that it serves the developer audience.
Successful DevRel teams understand that developers have distinct needs and high standards for authenticity. They value technical depth over marketing gloss, peer learning over sales pitches, and expect genuine expertise from the people they engage with.