Journey to the center of DevRel - Part 1
In this series of articles, we will explore the different aspects of the DevRel role, why and how we do it at SparkFabrik, and how we see it evolving in the future.
Introduction
Developer Relations, also known as DevRel, can be defined as the set of activities a company undertakes to build and maintain a relationship with the developer community, both internal and external. It is a relatively new role, and it might be a bit philosophical as a job description: you will see that it involves many company departments, from marketing to engineering, from sales to HR.
Last year we decided to start a DevRel program, and we’d like to share what we’ve learned. We want to talk about why we did it, the process we followed to get the role and the team up and running, the activities we carried out during the year, and the results we achieved. For those who are considering starting a similar program, and for those who are already doing it and want to compare their experience with ours, we hope this series of articles will be useful.
Let’start with a bit of history.
DevRel through the years
The role of DevRel has been around for a long time, but it is only in recent times that it has become a job title. In the past it was often associated with the role of evangelist, a term many believe was coined by Guy Kawasaki in 1983 when he was working at Apple. In his book The Macintosh Way he wrote about it in the context of a software company:
An evangelist. A good evangelism program has a champion running it. This person lives and breathes the program. He is the figurehead, guiding light, and godfather for developers. He must thoroughly understand the company’s product and technology.
And added:
Constant contact. Evangelizing developers is like bonding with a child. You need constant contact with them — talking to them on the phone, seeing their products, and taking them to lunch. A good practice is monthly mailings of technical notes, tips, tricks, and examples. Not only do the developers get information, they also get vibes that the company is on top of things and cares about them.
Apple sells hardware and software, so the goal of their evangelists was to convince developers to use their products by demonstrating that they were the best choice. Things change when we talk about a service company or a consultancy: we will come back to this later.
Apple’s customers were not just developers, and the same was true for companies such as Microsoft or Adobe, but getting them to advocate for their product was a great way to reach a wider audience. “The dentist’s favourite toothpaste” is a claim we are all familiar with, and this is more or less the same strategy.
In fact, it was popularised in the early 2010s by companies like Twilio and New Relic, which were among the first to hire developer advocates and create a developer relations team.
The marketing team at these companies understood that they needed to target developers, and when developers are your target audience, traditional marketing strategies don’t work, as noted in the seminal book Developer Relations by Caroline Lewko and James Parton.
So they started creating content for developers, speaking at conferences, organising meetups, and generally connecting with developers where they were, using their language: our language. This quickly became a trend, and many other companies followed suit: today virtually every major tech company has a DevRel team, as do many startups and even some open source projects.
Now that the role of DevRel is well established, the competition is tough and even for a company that can invest a lot of resources in it, it is not easy to stand out from the crowd. As developers, we not only want to use the best quality tools, the hottest frameworks, the coolest technologies, but we also want to work with companies that share our values, that have a culture, that are inclusive, that make us feel part of a community.
When we started this journey at SparkFabrik, we had all of this in mind: Developer Relations is about building a community that includes our employees and every engineer that comes in contact with us, it is about sharing our principles and vision, and it is about sharing our knowledge and experience with the community, contributing to open source projects and creating content that is useful to others.
So, we had an understanding of the history of the role in our industry and a somewhat clear idea of what we thought it should be, but since we are a service company and we are not selling a product, even before starting to think about how to do it, we had to answer a fundamental question: why should we do it?
Why DevRel?
The first question we asked ourselves was: why should we do DevRel?
The fact that it is a trend in the industry is not a good enough reason to do it, and what works for other companies may not work for us, especially in the Italian market where we could find very few examples to follow.
Many projects and big decisions at SparkFabrik are the result of a collaborative process, and this was no exception: we started a workshop! We involved different departments, from marketing to engineering, from sales to HR, because we wanted to identify the impact of the figure in different areas of the company, and from the very beginning we recognised that we needed to divide it into two main categories: external and internal.
You can usually apply this to traditional marketing: you want to attract new customers and new talent, and you also want to retain existing customers and employees. So you need to build brand awareness, establish thought leadership in the industry, be a place where the best people want to work and customers want to work with.
Developers are involved in all these aspects, often including the decision-making process when a company seeks a partner for a new project. By engaging with the community and demonstrating expertise and values, a company’s services are more likely to be chosen when solutions are sought.
In terms of talent acquisition, we agreed that developers tend to favour companies that engage with the community, contribute to open source projects, and offer resources for skill development. By participating in events, supporting hackathons, and maintaining a visible presence in the community, a company can attract potential customers and talented individuals.
All of this requires relations. The success of a services company is increasingly intertwined with the developer ecosystem. As technology becomes more complex and interconnected, developers play a key role in driving innovation, service adoption and influencing decisions: by establishing a dedicated DevRel team, we have recognised the importance of strong relationships with the developer community.
DevRel acts as a bridge between our company and the developer community, facilitating open communication, gathering feedback and creating a collaborative environment.
Investing in DevRel is becoming an integral part of staying ahead in the competitive technology landscape.
Starting with a question such as “Why do we need something?” is an effective way of articulating the purpose and rationale behind a particular initiative, it resonates with different stakeholders, leads to a critical thinking process of analysis, and sets the stage for continuous evaluation, because as circumstances change the answer may evolve, and periodically revisiting the question ensures that the initiative remains relevant and aligned with the company’s objectives.
Having agreed on the fundamental “why” of implementing a Developer Relations program, we began to discuss more practical aspects of the team: defining goals and objectives, designing activities and strategies, and evaluating results and impact.
This will be the subject of the next article in this series, so if you are interested in learning more, stay tuned!