Evolution of Developer Relations: How DevRel Helps to Build an Employer Brand

As a DevRel practitioner who operates in a global market, I’ve noticed an evolution in the approach to Developer Relations as a business function over the past few years. Starting as a technical role in product teams, DevRel is now also helping to attract technical talents and establish employer brands. In this article, I have tried to cover and synthesize all approaches to Developer Relations and create a structured up-to-date overview of the function.

What exactly is Developer Relations?

Generally, DevRel involves establishing relations between a company and the IT community. Initially, DevRel specialists were engaged in promoting developer software products among developers. But over time, DevRel as a function began to be used by businesses to work on the company’s brand as an employer.

So why did Developer Relations stand out as a special function? Because setting up communications with developers and the IT world is a big challenge for businesses in general. Today, DevRel helps address many business challenges by communicating with communities and creating new ones around the company’s products and employer brand.

Here are some examples:

1. The largest IT companies have developers-for-developers blogs on Medium, for example, the Slack Platform blog and Google developers on Medium.
2. Google and Amazon have built global communities around their products and technologies, such as the Google cloud AI developer community or AWS community.
3. Companies that provide IT outsourcing services pay even more attention to creating communities around their expertise, for example, Epam events.

Developer Relations is a complicated business function that can deal with goals related to both b2c and b2e. By this, I mean:

• The DevRel department at JetBrains, for example, will be involved in promoting Kotlin, building a community around this programming language, and communicating closely with the Kotlin community. This activity lies in the b2c (business-to-customer) market.
• DevRel in companies that do not make a product for developers will focus on working on the company’s image as an employer (through conferences, meetups, blogs). This is the b2e (business-to-employees) market.

Thus, b2c or b2e goals determine some differences in DevRel roles and KPIs. In my experience, IT companies in Eastern Europe and CIS markets use Developer Relations for building their employer brands by establishing relationships with IT communities (b2e approach). On the other hand, DevRel as part of a product team role is more common to Western Europe and the U.S.

Let’s now look at the differences and similarities of these two approaches to Developer Relations.

DevRel roles in product teams

A software company that creates products for developers needs classic promotion strategies as well as user feedback to improve the products and attract a larger audience. Developer Relations cover these objectives.

DevRel focuses on:

• establishing communications with users;
• working with a loyal audience, collecting and processing feedback;
• attracting new users through the community.

Developer Relations consists of different roles, such as Developer Advocate, Developer Evangelist, and Community Manager.
Often, I see companies hiring one person to handle the entire DevRel scope, which is not always a bad thing. However, when there is no clear differentiation, it is difficult to understand what competencies a person requires and how to evaluate the results of their work.

Let’s look at the difference between these roles.

Developer Advocate. Communicates with users, i.e., developers, to promote and improve the product by building long-term relationships and trust between users and the company. Often this work involves public speaking, training, and lots of networking. It requires not only a high level of technical knowledge, but also empathy, emotional intelligence, and the ability to put yourself in the user’s shoes. The Developer Advocate directly influences the development of the product, makes suggestions for changes, and works closely with the product team. Therefore, it is essential to be able to correctly interpret and convey feedback from user developers to product developers.

Developer Evangelist. The Evangelist is a speaker, a mediator between the company and its employees and an external audience. He speaks on behalf of the company at conferences and meetups, blogs in tech media, instructs user developers on how to best use the product, talks about the benefits and opportunities, explains how the product solves problems, and helps developers do their jobs.

Community Manager. This person organizes and supports the community, develops it, and provides impetus to move forward. It requires very strong organizational skills, plus an understanding of how the community functions, as well as what is interesting and excites the audience.

A more detailed description of all the roles in DevRel can be found in this article by Kim Maida.

Developer Relations for an employer brand

DevRel has become a vital instrument for establishing an employer brand in IT. This approach to DevRel originated mainly in Western Europe and is often associated with HR practices, but actually, it’s not.

The business goal of DevRel in this case is to build a trusting, long-term relationship between the company and members of the IT community as potential candidates. In addition, it presents the company as an active member of the community, contributing openly and honestly to the accumulation of knowledge and the development of technologies.

Well-designed Developer Relations play a huge role in recruiting. Judge for yourself - many people want to join Google or Amazon because they are inspired by the brand, technology, and these companies’ contribution to the industry.

In the b2e approach, DevRel deals with the image of the company. The target audience here will be developers, but also all other IT professions. This gives rise to a new set of factors to work with - these are the criteria for choosing an employer. According to the annual study by Habr and Ecopsy, salary, medical insurance, and office environment are no longer as important. IT professionals are attaching more importance to interesting tasks and technologies. They are looking for opportunities to grow and learn, and they want to be surrounded by experts and only work in a company that makes the world a better place. Therefore, Developer Relations focuses not only on external communications, but also on internal ones, creating communities and influencers inside the company.

DevRel in b2e differs from b2c to a greater extent precisely because of the presence of a huge layer of work with company employees.

External DevRel in b2e deals with:

• work on the brand and image, tech PR;
• building external communications with the IT community;
• developer marketing and recruiting support.

Internal DevRel involves:

• promoting a culture of knowledge sharing within the company;
• creation of infrastructure and base for internal communities;
• expert development.

The relationship of these two zones illustrates well the principle of “external reflects internal” - without a configured DevRel inside, you will not achieve high-quality external communications.

A knowledge-sharing culture is a key component of Developer Relations. Even if a company doesn’t produce its own product, there are still difficult technical dilemmas that must be solved internally, and the experience of solving these dilemmas can be useful to other IT professionals and engineers.

DevRel’s internal scope has to do with not only communications, but also:

• establishing infrastructure for DevRel processes;
• building these processes;
• creation and development of internal communities;
• supporting experts and thought leaders inside the company;
• creation of mechanisms for non-material incentives for active employees, etc.

To sum up

In this post, I wanted to consider various approaches to Developer Relations, their features, and tasks. In any area of application, DevRel is truly a cross-functional role. Given how overheated the IT market is today, it is vital for companies to build relationships with candidates, or they will lose out in the competition for people.