The goal of this article is to provide an explainer sharing my thoughts on what Developer Relations is, what its core tenets are, and what important questions DevRel works to provide answers to.

The Four Pillars of Developer Relations

Developer Relations, or “DevRel,” is a field in technology whose practitioners focus on improving and nurturing the relationship that an entity (be it a commercial product company, an open source organization, a platform, or other type of technology offering) shares with its developer users.

There are many different roles within Developer Relations. These include titles like Developer Advocate, Developer Evangelist, Community Manager, Developer Programs Manager, and more. There are several areas of DevRel which I see as equally important pillars that make up the greater Developer Relations ecosystem. In order for a Developer Relations team to be successful and productive, all four of the following pillars should play a part in the greater whole.

Developer Advocacy

Developer advocacy focuses on championing the developer users and representing their interests and input both externally and internally.

The job titles “Developer Advocate” and “Developer Evangelist” are often used interchangeably in the industry. In terms of practice, advocacy and evangelism are not identical — and both are important aspects of Developer Relations. In fact, most DevRel folks who hold a title of either “Developer Advocate” or “Developer Evangelist” actually do both advocacy and evangelism in their day-to-day job.

“A Developer Advocate’s job is to cultivate trust from both the product and the developers they represent by reaching across the table, listening, trying things for themselves, and understanding context and roadmaps.” –Ashley McNamara

Developer advocacy is centered around advocating on behalf of the developer user to the company. Some of the primary traits necessary for practicing effective developer advocacy are user empathy and emotional intelligence. When it comes to products whose primary users are developers, being able to understand the developer’s point of view and communicate user feedback effectively to make change in the product is key.

Developer advocacy is about taking on the lion’s share of the responsibility to reach out to the developer user community, help bring forward appropriate messaging, training and resources, and elevate the voices of the community both publicly and also inside the company.

Developer Evangelism

Etymologically, the word “evangelism” arises from the Greek “εὐαγγελίζεσθαι” (euangelizesthai): to preach the gospel / to spread the good word.

“A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers.” –Christian Heilmann

Developer evangelism centers around representing an organization and demonstrating what benefits the organization’s offerings have for developers. How does the product solve problems and help developers get the job done? They speak, engage, and instruct on behalf of the company to share how the products and services can better help developers to accomplish things.

Developer Experience

The Developer Experience is about cultivating, enhancing, and supporting a delightful experience for the developers who are using a software product, effectively using knowledge, research, and creativity to solve challenges and make improvements.

“Developer Experience (DX) is the equivalent to User Experience (UX) when the user of the software or system is a developer.” –Sam Jarman

DX can mean many things at different companies. For an open source organization, a significant portion of the developer experience may focus on OSS contributors in the community. How are contributors supported when they submit issues and pull requests? How can they get access to resources and guidance to make meaningful contributions? DX also includes enablement of a developer’s learning journey with a product. Are there helpful materials and tutorials available to pave their path to success with the product?

DX can also include:

• Tools and dashboard interfaces
• Documentation
• Tutorials and demos
• Onboarding experiences
• Avenues for getting developer support
• Ways for developers to provide product feedback
• Transparency around public product roadmaps

…and much more.

Community

Community refers to the current users and also potential users of a software or technology. This includes everyone from students and people just learning to code to senior architects to internal employees. Anyone who uses a technology, talks about it, advocates for it, provides feedback on it, etc. is a member of that technology or organization’s developer community.

“Community includes a company’s employees (at the very least, the relevant product division), current customers, as well as prospects, and anyone who could in the future be interested in using the product… which is a fairly broad group of people.” –Mary Thengvall

Community is about bolstering, nurturing, and cultivating the developer community with compassion and governing its interactions fairly.

Developer Relations Asks These Questions

When working in Developer Relations, we should be seeking to provide answers to two variants of three questions:

1. 💁🏽‍♀️ How can we help?

How can we help the developer community?

We do this in many ways, and are always on the lookout for more ways to do so. Some examples:

• Creating content resources (e.g., giving talks at events, writing blog posts, producing videos, courses, livestreams, etc.)
• Answering questions (e.g., staffing forums, Twitter and social media, responding to direct outreach, reaching out to the community to find out what questions developers have, etc.)
• Supporting developers who wish to provide their own resources (e.g., sharing important messaging, offering content creator training, supporting meetups and events run by the community, connecting content creators with internal subject matter experts, holding office hours, offering paired programming sessions, etc.)
• Requesting, receiving, and aggregating feedback from the community and championing that feedback within the company to improve the product

How can we help our organization?

The same question should be asked from the perspective of the organization we work for. Ways we can use our position in Developer Relations to help our org include (but are not limited to):

• Establishing developer feedback channels and managing communication to ensure that feedback is appropriately delivered and acted upon by teams within the org (such as Product, Engineering, Documentation, Design, etc.)
• Supporting feature launches with community engagement, content, and proactive anticipation of community responses
• Providing internal resources and opportunities for fellow employees to get involved with employee advocacy

2. ⚔️ What challenges can we resolve?

What challenges can we resolve for the developer community?

Developer Relations teams should also be strongly focused on problem-solving, identifying challenges, and crafting sustainable solutions. For example:

• Do developers have a clear path and good experience contributing to open source?
• Are developers confused about the way features of the product work, and can resources be provided to clarify?
• Is community feedback received and followed up on appropriately and do community members know their input is valued?
• Are there ample resources for developers with all different levels of experience to work productively with the software or platform?

What challenges can we resolve for the organization?

Within an organization, there are many ways Developer Relations can create and improve processes, set up new workflows, and collaborate cross-functionally across teams and departments, such as:

• Are teams in the company communicating effectively with each other to ensure that developers receive the best experience possible? (E.g., is marketing aligned with product and engineering?)
• If the organization has a focus on open source, how are issues and PRs triaged efficiently and sustainably without overloading any single team?
• Is there strong messaging around the organization’s goals and purpose, and how can this messaging be amplified to and by the community?
• Do teams within the organization feel confident that they are connected to and aware of important feedback and sentiments of developers who use the product?

3. 🧰 What can we build?

What can we build for the developer community?

Developer Relations also has a responsibility to create and build. In doing so, we provide platforms to elevate community voices and to offer opportunities to developers. We can build things like:

• Ambassador programs to mentor, support, and grow community members who are interested in spreading the word about a technology offering
• Community platforms such as forums, real-time chats, user mailing lists, and more
• Demos, samples, tutorials, guides, showcases, and more

What can we build for the organization?

Within the organization, we can also build internal tooling, such as:

• Programs for beta testing, early access, and community advisory groups to bring actionable and early feedback into the company
• Workflows and dashboards to track community sentiment and growth
• Apps and automated tooling to manage community programs, incentives, swag, event support requests, etc.
• Bots and API integrations to support moderation, contributor assistance, metrics, frequently asked questions, and more

It’s About Making a Difference

Developer Relations team members work on a myriad of different problems and tasks, and face unique challenges to craft creative and remarkable solutions. Developer Relations is exciting because it’s different across every organization: it is so intrinsically tied to that organization’s technology, audience, goals, and area of focus. You will never do the same DevRel job twice at two different companies — though the underlying traits and overall thematic elements will remain consistent. Much of this boils down to answering one question (albeit with lots of variation and nuance): How can I help?

Do You Want a Job in Developer Relations?

If you’re interested in working in DevRel, I would encourage you to do it because you want to help — not for personal glory or to become industry-famous. A great DevRel team member is a champion for the developer, the organization, the community, and the user experience. Compassion, kindness, and empathy are truly valuable skills for anyone interested in Developer Relations. If you don’t come at it with a deep caring for the success of others, the early sense of fulfillment from fame-and-glory will fizzle out quickly.

As a developer marketing leader, my job is to design and engineer the vehicle that drives the voices of others forward. I am not the racecar driver who crosses the finish line and is rewarded with a wreath and a trophy; I’m the unseen engineer who makes sure the racecar has been built to operate in the most performant and high quality manner that it can. Developer Advocates often get to build their personal brand in a big way; but leading DevRel frequently means being comfortable and feeling fulfilled from behind the scenes.

I’d love to share thoughts and tips on how to get started landing a job in Developer Relations, but that’s a blog post for another day. 🙂

• Category: Developer Relations
• Tag: career, developer relations