Looking at developer relations teams it becomes obvious that there is a mixture of roles, responsibilities and assignments. Actually, it can be quite confusing for developers to understand who does what exactly. And what they are doing it for… What has been the understanding from the get-go, though, is that DevRellers are developers themselves. Or are they?
To answer this crucial question let’s dive deeper and explore what developer relations are and what DevRellers do.
Are developer relations only technical?
Essentially, developer relations are the terminology for a strategic team which connects developers to a company, over an application or tool and to each other. In this, developer relations combine various methodologies and approaches. Consequently, DevRellers can employ community management, program management, marketing, teaching, technical writing, customer success management, consulting, event management, and a whole host of other fields.
Mary Thengvall put it aptly in her article on the subject: “Developer Relations is the umbrella term for the team whose primary responsibility is building a community both online and offline.”
When we look at existing teams, developer relations are mostly being practiced by developers proper. That means that your average DevReller will most likely have coded full-time in their previous career or at least delved deeper into coding than the standard tech company employee. Most have also established themselves as speakers, content contributors and community connectors.
The community factor
Reviewing the various manifestations of DevRel, it is not a given that DevRel equals developers in many of the teams we see today. Whatever it is that matches company and team strategy: developers entering developer relations need to establish a communication and community mindset if they haven’t yet done so. A lot of job ads actually ask for community or program building experience. This is essentially the asset which enables DevRellers to serve as approachable, relatable and engaging community leaders.
On the flipside of the coin, those who don’t have a technical background need to step up. There are the marketers who learn to code to be able to do product presentations. Community builders study technical documentation in order to answer questions from members. And how can a program manager organize a conference with a great event feel for developers if they don’t grasp the fun that’s in working with the product?
The best team mix
Indeed, we find that a not so small share of teams consists of developers and non-technical people. Folks with a previous career in community, project management or communications often have a special kind of love for developers. I proudly count myself among them. Why is that? It is because they have seen the magic developers do on a daily basis. In many situations, they benefit from this work, spreading the good news to external audiences.
So what is the best recommendation? Should teams be exclusively comprised of developers, engineers, data scientists and engineering managers? Does it make sense to encompass people with a different background, to hire people who have had a different outlook and experience? Or better said, how necessary is it that DevRellers understand the needs of their target group from a personal perspective?
Roles in a DevRel team
To answer that question let’s look into the different roles in a developer relations team.
Naturally, every team will have a leader. In developer relations speak the role is called developer relations manager or lead. This person directs strategy, manages staff, oversees everyday business and coordinates field trips. Apart from good manager characteristics this person needs to make sure that the team keeps aligned with what developers want and need. It is the lead’s responsibility to make sure that engagement keeps the focus on fun and learning. No developer wants to hear a sales message.
Next up we have the most common developer relations role. The developer advocate is the person of contact, technical bridge and general all-in-one explainer of the company’s technology. They ensure that anything that developers touch is understandable, easy to use and engaging by passing on feedback to product. Moreover, developer advocates evangelize the company’s technology at conferences, at meetups, in videos, on social media channels and in person to person interaction.This position is the most technical on the team. Without the developer advocate it would be tricky to have developers relate. Alternative names are developer evangelist or ambassador.
Other technically-oriented team members are technical program managers, technical community managers and technical writers. For positions with “hard” skills, I have even seen names such as “internet fairy” once. Keep in mind: developer relations is about engaging people! Essentially, it is about fun. Just because someone carries an unusual title that does not mean they are not competent or the best person to convey the message.
Developer advocates are often accompanied by a figure more focused on the organizational aspects. They are called developer relations manager, program manager, coordinator or project manager. The person is tasked with keeping up-to-date with all threads and ensuring effective communication. This manifests in organizing events and conferences, making sure that all stakeholders are aligned internally, advocating for resources, fundraising and budget management and smaller scale leadership. Often, the program manager is the person who has a link to everyone in the team and to a certain degree to the community.
And ultimately, it is not unusual to also find a non-technical community manager on the team. As the point of contact for the community, the CM establishes the community strategy, takes care of outreach programs and proactive messaging. Community managers typically know their companies’ technologies to a certain degree and are able to explain it on a surface level. For example, searching for StackOverflow posts and crunching the numbers is something that a non-technical person will do. When it comes to answering questions in detail, the developer advocate can take over.
Consequently, both the developer relations manager and the community manager do not necessarily come with a technical skill set. Nonetheless, they have a background working in technical companies more often than not. Coding is thus not a prerequisite – and it makes hiring and retaining talent with a love for developers a little bit more inexpensive.
So… do DevRellers need to be technical?
Now that the different roles of the developer relations team are clear – and the above-mentioned register is not exhaustive – can we answer the question of whether DevRellers need to be technical or not?
On the one hand a DevRel team made up exclusively of developers represents the community ideally. On the other hand, different perspectives will enrich the team’s way of thinking.
At its core, it depends on the company’s and team’s strategy:
- Why set up a developer relations team?
- What should be achieved?
- What is the audience?
- What is the message?
- How is success defined?
Depending on the answers it will become clear which roles will need to be established and filled. In some instances this means that a team will be completely technical as the activities will be focused on in-person interpretation or content. In other instances owned conferences, meetups and organizers will take up the majority of planning input. The degree of internal networking is also a crucial factor.
Once developers are hired they (and the employer) will want to spend as much time as possible on coding and interpreting. This is both applicable in the motivational and the financial sense. At the same time, there are folks who excel at everything that does not need coding experience. They perfectly add up to the technical expertise on the team.
To summarize: look at the goals first – and hire accordingly.
Make it balanced
As a non-technical person myself I naturally advocate for a diverse team. But I’m not only saying this from the perspective of a non-technical person (or should I say not-yet-technical?). I see it from the perspective of what diversity can bring to a team. Imagine adding perspectives of people who are just starting to code or people who might ask the so-called “stupid” questions. Or by having developers on the rota who are skilled in much more than coding. By considering that, you will speak to a broad user base already. In any case, the numbers clearly show that diversity increases the bottom line noticeably.
In developer relations teams, the ratio should not be skewed towards non-technical people too much, however. Combining technical expertise, communications and project know-how and a deep-rooted love for communities and their challenges is the right kind of recipe.
With that in mind, an amazing team will emerge. Happy hiring!