What is Developer Relations?

What is DevRel?

Here’s my take.

Developer Relations (or DevRel) is the part of an organization that focuses on making sure a product is ready for adoption when the intended user is a software developer. A technical product is different because the audience for consuming it:

• doesn’t typically respond to traditional marketing tactics
• doesn’t typically respond to traditional sales
• is well informed and often capable of solving the problem themselves

A product that is an API available on the cloud is a prime example, developers can either recommend or block the buying decision. Therefore, DevRel exists as a cross-functional team that aspires to earn that developer’s recommendation.

This can be done by ensuring a great developer experience, evangelizing the product to increase awareness, building a community within larger software ecosystems, advocating for changes in the product that help developers with adoption, and providing the support needed for developers to be successful building their own project by using yours.

Many large technology companies have DevRel teams and programs including AWS, Dolby, Google, Intel, IBM, Microsoft, Salesforce, Samsung, Twilio, etc.

“Technology is increasingly being driven by bottom-up, rather than top-down, adoption… The days of recruiting developers to where you are is over. You have to go to where they are.” — Stephen O’Grady, The New Kingmakers

What Does DevRel Do?

There are a number of activities that can be grouped into the domain of Developer Relations. Depending on the stage of a product in its journey from development to general availability in the market will drive where DevRel’s priorities are.

• Attend, speak, and sponsor developer events such as meetups, conferences, and hackathons
• Build interesting projects, prototypes, and demonstrations by using the products and APIs first
• Create technical documentation both formal getting started guides or tutorials as well as informal blog posts
• Deliver content through a variety of modalities — webinars, live coding sessions, recorded videos, podcast interviews, in-person workshops or presentations, etc.
• Work with partnerships & alliances for joint go to market collaboration opportunities with complementary services needed in building something
• Grow communities online & offline through newsletters, VIP programs, etc.
• Provide technical support across channels that are convenient for developers including in-person events, online forums, stack overflow, quora, social media, etc.
• Develop tools and SDKs that help enable developers to onboard and have success faster and with less pain

Digital Volcano Case Study — look at my other story on a developer campaign that demonstrated some of these activities in action.

To accomplish these activities DevRel must work in close collaboration with participation and interlock from many other departments across the organization such as Product Management, Engineering, Marketing, Communications, Public Relations, Legal, and Customer Support. This is part of what makes placing DevRel within an organization a common challenge. The whole organization must contribute to the mission, DevRel just focuses on it full-time across functions.

Hoopy’s State of Developer Relations 2019 (link)

What Skills Does Somebody in DevRel Have?

The #1 most important skill for Developer Relations to have in their skillstack is empathy.

I was once told that at Google, the Developer Advocate is viewed as customer zero — an early stop in the release process to feel what the end developer will experience when trying to use an API in a project. This is not the same objective as Quality Assurance (QA) but more like user acceptance testing to get “Hello World” running efficiently within a developer’s preferred toolset. This means making sure the service is easy to learn, can be used in different environments, and can be used in combination with other products offered by the same company.

A DevRel organization requires a cross section of skills like:

• Software Development —a background in solutions architecture, polygot full-stack development use of web APIs, etc.
• Communications — such as technical writing and public speaking, cross-functional interpersonal relationships
• User Experience (UX) — such as User Centered Design, building developer productivity tools, etc.
• Business — such as business development, partnerships & alliances, public relations, etc.

Depending on any individual’s specific strengths might prepare them for one of a number of typical developer relations roles (this is not the structure of a team, just examples of titles you might see):

• Developer Evangelist / Technical Evangelist — definitions vary, but frequently associated with representing the company to the community in order to sell the dream of what a product can do
• Developer Advocate — often puts greater emphasis on representing the community to the company, expressing the feedback gathered from developers in the community to help shape the product direction while giving support
• Community Manager / Events Manager — networker and facilitator for looking after the community, sharing information, making connections, or planning events
• Developer Experience / Developer Programs Engineer — often works within the company by focusing on usability and engineering of developer tooling, hygiene around the APIs, building SDKs, tutorials and portals
• Content Manager / Technical Writer — skilled at communicating clearly and effectively to audiences
• Developer Marketing / Growth Hacking — succinctly crafting the message around what a product does so that it resonates with the developer audience trying to find it by cultivating social media, advertisements, and related tactics.

Summary

I have been practicing Developer Relations for a number of years with direct visibility across multiple organizations so felt I could finally synthesize my perspective on what DevRel is for its impact on a business and industry. Many other sources influenced my point of view, so I’d call your attention to these other resources for additional perspectives:

• Christian Heilmann’s Developer Evangelist Handbook
• Matthew Revell’s DevRelCon and devrel.net
• Phil Leggetter’s Defining Developer Relations
• Brandon West’s The 3 C’s of Developer Relations
• Mary Thengvall’s The Business Value of Developer Relations and What Is Developer Relations (And Why Should You Care?)
• Ashley McNamara’s What is Developer Advocacy?
• Robert Nyman’s What Developer Relations Is and How to Do It
• Reto Meier’s The Core Competencies of Developer Relations
• …and many more