Usually, the first thing that comes to mind when thinking about Developer Relations is Developer Advocacy. Indeed, 9 times out of 10, the first role that’s hired in a new DevRel team is a Developer Advocate. So much so that Developer Advocacy is often perceived as the only, or the single most important role, in Developer Relations.
There is so much more to DevRel than Developer Advocacy.
There are many reasons and a pile of history for this misunderstanding. When Developer Relations first started with Apple back in the early 80s, Guy Kawasaki as the Chief Evangelist was such a fierce promotor, that an indelible mark was left on the field of DevRel. Still today, Developer Advocates/Evangelists* are typically the most visible representatives of your DevRel program in external technical communities and normally front your technical marketing efforts. Unsurprising, given their mandate and skillset, which combines technical skills with communication skills.
What is certain is that the Developer Advocate role and philosophy of serving developers and advocating on their behalf is a crucial function of DevRel that sets the tone for the culture surrounding DevRel.
Developer Advocates act as an information valve for a company (see Figure 1 below). In this role they communicate out to the development community as well performing the “voice of the developer” role inside their company, providing valuable feedback about the product, the developer experience, and the reputation of your company within developer circles.
As we set out in our blog, A Framework for Developer Relations, we put forward that DevRel is made up of four functional areas:
All in service to the Community.
We received some feedback expressing surprise that Advocacy wasn’t named as one of the functional areas. Our response - advocating for developers necessarily takes place across all four of those functional areas, illustrating why Developer Advocates are often referred to as “Swiss Army Knifes” or ”Jack/Jill’s of all trades.”
Check for the traps though, especially in early-stage teams:
Just because someone can do a bit of everything in DevRel, it doesn’t necessarily set them up for success by expecting them to do a bit of everything.
In addition, we often find that Developer Advocates enjoy high levels of empowerment and autonomy, but are typically hired into IC (Individual Contributor) roles. Consequently, they may not be intimately involved in the strategic planning and budget setting for the overall program.
Therefore, if you have a Dev Advocate on your team:
Overlook a Dev Advocate’s insights at your peril.
Consider career progression paths for them and your team overall.
Additionally, to give your DevRel program the best chance of success, we encourage you to look at DevRel from a higher and more strategic perspective. Advocacy is key, but don’t forget about all of the other roles which contribute to your program. These will be roles that exist inside the core DevRel team, as well as co-workers in adjacent teams who need to collaborate with your DevRel team to deliver an optimal and friction-free Developer Journey.
*Developer Advocate is more commonly used today, rather than Developer Evangelists, as an advocate is seen as a more comprehensive term, and one more in service of developers, rather than simply promoting or evangelizing the product.