Made by
Made by
DevRel’s rapid growth during the relatively short time it has existed as a profession means that we lack the common understanding of job titles and team structures enjoyed by disciplines such as marketing, sales or engineering.
Job titles shape expectations and, together, a team’s job titles paint the picture of what the organisation values. Career ladders give people a map to follow on their professional journey. They give them clarity about where they can enter an industry and how they can progress through it.
For our latest report, DevRel Job Titles and Career Progression, we spoke to DevRel leaders to understand the job titles in use across the industry and we propose a standard set of definitions for those job roles, along with a reflection on DevRel career ladders.
And you can watch our video summary of the report on YouTube.
The structure of your DevRel team, and the job titles found within it, depend on what your team is seeking to achieve. Some common strategic drivers for DevRel programs are:
To achieve the team’s goals in alignment with those drivers, you execute your work in some combination of four distinct areas – the four pillars of DevRel:
In the report, we examine how DevRel job roles align to each of the four pillars of DevRel. We also look closely at DevRel job titles and the key responsibilities and hiring requirements for each of them.
Our research shows that there are probably three core developer relations job roles. By “core”, we mean two things:
Arguably, we are cheating a little bit in saying there are three core roles. That’s because the Developer Advocate role comes in four forms. However, they are close enough to each other and often share the “Developer Advocate” job title that we believe there’s still value in thinking of it as a single role.
So, here are those three core individual contributor (IC) DevRel roles:
In the report, we show what function each of these roles plays and how they relate back to the four pillars of DevRel.
As teams get larger, they take on supporting and emerging job roles. These enable the core DevRel roles by bringing their own specific skills to the team. However, we consider them supporting roles because they are neither essential to a DevRel team’s function nor are they exclusive to developer relations.
Those supporting roles are:
We recognise that, although we can categorise job titles and tasks, there isn’t a standard developer relations career path. This means the career journey map is incomplete for practitioners. And, for managers and leaders, a lack of rubric means it is harder to fairly evaluate candidates when recruiting and promoting.
Our research showed, though, that some teams are adapting engineering career paths to the needs of developer relations. Bear Douglas’s work at Slack, for example, sets out one approach.
Bringing together the DevRel IC career paths that we found, we propose that a DevRel IC career path might start at Junior and top out at Distinguished. Each stage on that career path considers five aspects of the individual’s work:
Developer relations is a fast-moving discipline. However, it was clear from our research that there is increasing commonality between companies on what’s expected from people with the same job title, and what’s expected of them if they are seeking a new role or promotion.
We would like to thank Common Room for sponsoring this report, and all the people who provided us with their insights to inform our research.
Download the report free of charge and without having to provide any personal information.