If you came to this article hoping to get a complete overview of what being a Developer Relations professional really means, I’m afraid I’ll have to disappoint you. If you’re expecting a long list of criticisms or judgments about the work of a DevRel, this isn’t the right place either. And if you’re looking for some kind of enlightenment about the role, sorry, but you’re still in the wrong spot. What you’ll find here is a personal reflection on my two years as a DevRel, without claiming to teach anyone anything and without the intention of sparking debates or pointless discussions. My goal is simply to share how my perception of the role has changed over time, depending on the context in which I lived and worked. Just a lived experience, with no filters.
To be or not to be, this is the question#
Let’s get one thing straight right away: I work as a Developer Relations Engineer at a company that develops a closed-source product, which is part of a broader ecosystem—the Cloud Native space, as defined by the CNCF and illustrated in the well-known landscape. Why am I telling you this? Because everything that follows is based on this context. A DevRel’s experience can vary dramatically depending on the company, the product, and—most importantly—the business goals that drive the Developer Relations initiatives. Changing even one of these variables can completely reshape the role, like adjusting a small detail in a painting and seeing how it affects the entire picture.
So, the question:
“I give talks—does that mean I’m doing DevRel?” The answer is yes.
“I write articles—does that mean I’m doing DevRel?” Yes, you are.
“I mentor others or help build communities—am I doing DevRel?” Again, yes. But there’s a catch.
Here’s the thing: Doing something doesn’t automatically mean being something. Speaking at conferences, writing articles, and engaging with communities are all activities that fall under the DevRel umbrella. But doing these things alone isn’t enough to make you a DevRel. It’s not just about what you do—it’s about how and why you do it.
Don’t get me wrong: I’m not downplaying the value of giving a talk, contributing to a community, or sharing knowledge. These are vital activities for any DevRel. But without a clear strategy and a defined ROI for your company, these efforts—while valuable—might not deliver the outcomes you hope for. And, more importantly, they won’t truly elevate you into the Developer Relations role.
My little patch of land as a DevRel#
There’s a harsh truth I had to come to terms with when I started this journey. If you’re doing DevRel, you’re not part of marketing, engineering, or sales. Yet, it’s crucial that you are a bit of everything and, at the same time, nothing in particular. You’ll soon see what I mean by this.
We’ve all been taught, from early education, to analyze things using the 5 W’s (who, what, where, when, why). Let’s try to apply this framework here. Who is my target, and what do I do to reach them?
My targets are four: the current product user base (our customers), the potential product user base (the market the product fits into), the industry the product belongs to, and the community of people the product is aimed at.
To reach these targets, the activities vary and hold different weights and values for each persona. The goal with the current user base is to make their lives easier. But easier in what way? Helping them discover new features, understand how to integrate the product in new contexts, break down the barriers of first-time use, and make the product more accessible. The key word here is training. Whether through courses, comprehensive documentation, or other resources, the point is always the same: make it easier to approach and progressively discover the product’s potential.
The current user base and potential user base often overlap. Here, the keyword is solutions. The main goal is to communicate the product’s value. And what better way to do that than by solving a problem? Demos, tutorials, and Proof of Concepts (PoCs) become key tools to show how the product fits into a real-world context, allowing the audience to relate to the problem and understand the value of the proposed solution.
The industry and community hold strategic value for two reasons: the community is crucial for the brand and positioning, helping to build credibility with a broader audience; the industry is important for staying in tune with technological advances, influencing roadmaps and product messaging. The keywords here are sharing and relationships. Sharing experiences with the community, even beyond product evangelism, strengthens trust and reputation. At the same time, engaging in an industry (in my case, the Cloud Native development world, represented by the Cloud Native Computing Foundation) helps build relationships, understand how others tackle similar problems, and stay updated on technological trends.
In a few words: I aim to improve the lives of my product’s users. At the same time, I work to influence the potential user base by highlighting the product’s strengths and helping position it in the market. All of this, while never stopping to listen to the industry and contribute to communities.
The DevRel in the corporate context#
Alright, we understand what you do, but what value does someone in your role bring to the company structure? How do you interact with other teams? How do you fit into the broader company picture?
Based on what we discussed earlier, we can summarize the role of a DevRel as that of an orchestrator who facilitates the flow of information between the product and the outside world, and vice versa.
The first key responsibility of a DevRel is to generate value for the product. On one hand, there’s the task of training; on the other, user feedback plays an equally crucial role.
A DevRel often collects feedback directly, but a significant portion of these insights comes from other departments, such as Sales and Solutions Engineering, who gather them during customer or prospect management cycles. In this context, the added value of the DevRel is to act as a bridge, ensuring that this feedback is not only collected but also utilized. How? It depends. Recurring feedback can lead to the creation of supporting materials for Solutions Engineers, such as demos, documentation, or tutorials to better explain specific features. Reports of deficiencies, whether real or perceived, can be communicated to the development team, influencing the product roadmap or improving existing implementations.
At the same time, working with communities helps spread product-related messages and strengthen the corporate brand, contributing to the company’s thought leadership. Additionally, monitoring and interacting with the industry helps identify and understand market trends, bringing this information back to the company to refine product positioning and messaging.
In this context, the real advancement is making the entire operation scalable. After all, Rome wasn’t built in a day, and certainly not by one person. A good DevRel knows that to build something lasting, it’s essential to enable and involve the entire company community. Through the power of inner sourcing, the DevRel works to ensure that even those who don’t formally hold the role can contribute to Developer Relations activities, making the work more sustainable and, above all, scalable. Because, in the end, the voice of many is always more powerful than the voice of just one, right?
So, does the DevRel not need to generate leads?#
Falling into the trap of oversimplifying the DevRel role as just a lead generator is a mistake that, sooner or later, we all stumble upon. Yet, as we’ve seen, there’s much more to this role: the real challenges go far beyond just gathering contacts. Leads do come, of course, but they are the natural outcome of a broader and more complex job.
The true task of a good DevRel is to maintain the right balance between the product and the people: always keeping the focus on users, while never losing sight of the quality of what’s being built. Only by doing this can you truly unlock both your potential and that of the product, contributing, day by day, to making—if only a little—the lives of its users better.
Is it really worth embarking on this journey in the world of DevRel? The answer is up to you. As for me, after exploring various aspects of software development, I believe I’ve found my place here: a role that allows me to nurture both the human and technological sides of this work, with the freedom to constantly experiment.
But, as always, the final judgment will be left to future generations.