DEV Community: Julia Murashova

Developer Relations for talent attraction: role, goals, KPIs

Julia Murashova — Wed, 11 Jan 2023 18:53:57 +0000

Companies all over the world start using Developer Relations not only for promoting their software products, but also for talent attraction purposes. You can find detailed review of these two approaches in the article “Evolution of Developer Relations…”. In this text we will focus particularly on business-to-employees side:

Why DevRel today is “must have” for talent attraction?
DevRel role description in talent attraction
What department DevRel belongs to?
How to set and measure DevRel goals?

Why Developer Relations are becoming “must have” for talent acquisition?

In the context of talent attraction, DevRel stays close to employer branding and company image as an employer. Usually, these goals were covered by marketing and HR departments, but now Developer Relations take this responsibility as well.

DevRel focuses on establishing relations between a company and IT folks aiming to win best talents on the market by creating interest, loyalty and synergy.

Three factors why talents attraction needs Developer Relations:

Work content becomes one of the most important factors when candidates choose their future employer. Technologies and opportunity to work on something meaningful really matters.
Some companies use aggressive hiring practices which don’t work well with seniors very often. DevRel makes the hiring process more comfortable, engaging and pleasant for both candidate and employer by building trustful communication even before the recruiting process starts.
DevRel is a person who has both technical mind and great soft skills, thus they can establish a great level of cooperation with engineering, HR, marketing and management.

DevRel in Talent attraction - role description

Every company is unique and sets its own list of requirements for a DevRel. However, we can identify some patterns and trends.

DevRel in TA role description template:

Manager (strategic level)

Responsibilities:

create and substantiate Developer Relations strategy and goals
lead \ build a developer relations team, that may consist of not only advocates but also copywriter, event manager, social media manager etc.
set up appropriate and measurable KPIs
cooperate with C-level management, HR and marketing teams to alien strategies and streamline activities

Skills:

high level of project, people and vendor management skills
strategic mind
analytical skills
ability to communicate with company c-level officers

Operational (tactical level)

Responsibilities:

raise awareness among IT community by engaging with local communities and grow community around the company
create different materials to demonstrate work content, best practices and tech stack
establish knowledge sharing culture inside the company
organize collaboration and sponsorships of IT conferences, meetups, hackathons, etc.
identify relevant influencers and devising plans on how to effectively engage with them
leading blogs at tech media (for ex. medium, dev.to, github etc.)
establish thought leadership inside the company, prepare speakers and writers, encourage employees to give talks at industry events
interaction with open source community

Skills:

community management
event management
copywriting
public speaking skills and ability to coach others in public speaking
great communication skills
good understanding of IT technologies

Does a DevRel specialist has to have a technical background? Not background, but technical mind is a must. In other words, you can be successful without coding skills, but being a DevRel is impossible without a technical mind and mindset.

What department DevRel (in TA) belongs to

This question doesn’t have one right answer. Often, DevRel team or specialist is placed inside the HR, marketing or even corporate communications department. It looks quite logical due to common talent attraction goals. However, according to my experience, landing a Developer Relations team in engineering, as a separate independent practice helps to achieve better results. In this case, DevRel can simultaneously streamline activities with HR and marketing, reaching good synergy with these teams, and focus on engineering needs at the same time.

How to set and measure Developer Relations goals in talent attraction

In general, DevRel mission is bringing as many people as possible to the communicational orbit of the company, and establishing trustful relations with this audience, cultivating knowledge sharing and synergy.

What can be the goals?

From the mission above, long-term goals can be formulated as the following:

building community around a company and reaching high engagement there
increasing number of brand ambassadors and advocates among employees and community members
raising brand awareness and recognition
making input in brand perception as an employer of choice
accelerate and exemplify expertise

How to measure relations?

Setting DevRel KPis is one of the most complicated questions for business. It’s hard to convert relations to numbers that can be analyzed. However, we can mix quantitative and qualitative approach:

Marketing metrics for estimation current activities results

Reach
Engagement
Number of conducted activities

Surveys to estimate effects

Brand health analysis
Customized feedback surveys

Also, long-term DevRel activities effects can be noticed in the recruiting and attrition trend. Moreover, internal feedback surveys can help to measure value that employees see in Developer Relations for themselves as well.

Community management: how to create a global network of internal IT communities | DevRel case

Julia Murashova — Thu, 21 Apr 2022 19:09:01 +0000

In this article I would like to share my approach of building a successful network of internal professional communities in a global IT company. This approach is based on my experience during 2020-21. I have built a project that consisted of 16 communities and involved about four thousand employees (about 30% of total headcount). This experience helped me to come up with a useful and scalable formula for IT community building.

Why do IT companies benefit from internal professional communities?

There are three areas of strategic business goals that potentially can be solved through maintaining internal professional IT communities:

Talent management and HR
Developer Relations
Business goals

It is very important to identify your particular goals and relevant KPIs. What would you like to improve by building a community? What results do you expect?

Let me come up with a table of goals and corresponding KPIs. This list is not comprehensive, but something to start with.

All of the mentioned goals follow the idea: to identify, grow and work with high potential people. According to Harvard Business Review, “high potentials consistently and significantly outperform their peer groups in a variety of settings and circumstances. While achieving these superior levels of performance, […] they show a strong capacity to grow and succeed throughout their careers within an organization—more quickly and effectively than their peer groups do.”
In other words, high potentials:

are highly self-motivated and ambitious
show capabilities to solve complicated issues
have (or eager to have) strong hard expertise, as well as soft skills
strive for communication and self-presentation

High potentials will be the people who pay attention to the communities and will become core team members. Finding and involving such people in the project is the first priority for the community manager.

Five key components for building internal IT communities

All communities follow a typical life cycle: inception, creation, growth, maturity and re-inception or death. It is very important to create a certain environment that helps the project go through these stages successfully.

The project model discussed below is built in a way that your communities function as long and successfully as possible, as well as be able to scale and “reborn”.

1. Good structure

Structure is important to make it easier for employees to navigate communities. For example, communities can be created around:

roles (BA, QA, DevOps)
coding languages (Java, Go, C++, Kotlin etc.)
technologies (Kubernetes, PostgreSQL, AWS etc.)
company’s offerings or products

Also, it could be useful to ask yourself two questions before creating a community: are there enough people who are interested in this topic in the company and is the business interested in growing this expertise?

2. Identity

The power of marketing and design could not be underestimated. Brand identity creates the feeling of belonging to a certain group. It is very important for communities. Create identity (logo, unique color scheme, prints) and provide community members with some branded goodies. This is a nice move to unite people. This is what actually makes a community.

3. Motivation and recognition

Motivation and recognition systems should help the project to be self-driven. Community is something people usually do in their extra time, so they need extra motivation that may be expressed as:

Unique souvenirs/goodies for community members (t-shirts, cups, hoodies, etc.)
Rewards for speakers (something useful and meaningful, for example, professional books or training)
Public recognition (it is important to promote internally what is happening in the community and express public gratitude to the people who invest their efforts to this community).

4. Communication infrastructure

There is no community if there is no platform where members can communicate with each other. The most popular solutions on the market are Slack and Discord.

The community exists when:

an employee can easily join / leave the community
community members can communicate with each other on the same platform
horizontal connections begin to appear

5. Project management

Unfortunately, building the project and just watching it work without any management is not possible in real life. If you ensure the four components, the system still needs management and monitoring.

The project will require efforts in organizing events, working with speakers, collecting and working out feedback as well as planning development strategy.

Here are my 10 personal experience tips for community management in IT:

🤝 Don’t shift responsibility, experts won’t drive a community for you, they will do that only with you.
☎️ Regular sync ups are more important than you could imagine.
🥳 Don't underestimate emotional support and motivation, do not skip on kind words and praise. Celebrate achievements of active community members, make their merits public.
✨ If the first event failed, don’t get upset. Give people time to realize that this activity is regular — the crowd will get involved.
🧭 Only about 10% of people want to share their expertise publicly. Not everyone wants to contribute.
🔋 If 30% of the company actively participates in communities — you are a hero, congratulations!
🌻 A beautiful wrapper is half of the success. Create something special.
🤩 Communities definitely help to create company spirit, comfortable working environment, atmosphere, and informal communication.
🏆 The community would be supported by 2-3 active experts. If you have only one active, you depend on them too much. Gather a group, find out the motivation someone has to engage in community, keep them motivated.
❤️ Community must not be something obligational, it is for the soul.

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

Julia Murashova — Fri, 11 Feb 2022 12:16:05 +0000

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:

The largest IT companies have developers-for-developers blogs on Medium, for example, the Slack Platform blog and Google developers on Medium.
Google and Amazon have built global communities around their products and technologies, such as the Google cloud AI developer community or AWS community.
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.