A couple of weeks ago, I put out this tweet.
Initially, this blog post was going to expand on that. But before writing, I wanted to do some research into the history of DevRel, look at some of the trends, before writing an essay to prove my assertion. What I ended up doing was writing this blog post as an exploration of the field, some of the changes and challenges we face, and where I think we’re headed.
What is DevRel?
This is one of those questions that only some people agree on the definition. I suspect a lack of a clear definition of what DevRel is and what it does is part of the problem we’re seeing with DevRel today. If leadership can’t understand it, its value decreases. If leadership hears another successful DevRel team defined differently than how their organization defines it, scrutiny and distrust often follow.
Guy Kawasaki popularized the term Developer Evangelist at Apple in the 1980s. Developer Evangelists engaged directly with the developer community, especially around the Macintosh computer.
In the late 1990s and early 2000s, the rise in open-source software changed how developers interacted with technology and each other. This shifted the approach to community-led development, paving the path toward what we know as modern DevRel, focusing on community engagement, open collaboration, and shared development.
As tech companies noticed the importance of developer ecosystems, DevRel roles became more formalized, focusing on both fostering community and contributing to product development feedback loops. As part of this, we saw more teams sourcing content from their communities, emphasizing collaboration and community-generated content.
At its core, DevRel is a bridge between a company and its developer users. It focuses on mutual benefit: supporting developers in solving their problems and using feedback to improve products and services.
Within DevRel, we see specialties such as developer advocacy, technical writing, event management, and even product development.
The focus and approach will depend on the needs of the organization, but I’ve always appreciated Swyx’s post on Measuring DevRel for the examination of the focus on content, community, or product.
DevRel Data
Common Room’s DevRel report from their survey provides some additional insights into the DevRel field, including information on compensation, department alignment, and primary responsibilities:
- Compensation: The report indicates a median total gross compensation for DevRel professionals equivalent to $175,000 USD.
- Department Alignment: DevRel commonly report to marketing or Developer Relations/community departments.
- Primary Responsibilities: According to the report, 61.5% of respondents said that creating educational content and resources is their primary responsibility. Additionally, 58.6% is tasked with delivering on a primary business objective: product awareness.
Where is DevRel in the Organization?
According to The Role of Developer Relations Has Fundamentally Shifted in the Last Decade, DevRel was initially seen as an extension of marketing while also providing support for sales. More recently, we’ve seen more focus on community-driven efforts.
According to the 10th Annual State of DevRel Report, Developer Advocates make up 42.8% of DevRel roles. Still, we can also see the diverse roles within the field, including leadership and managerial roles, Dev Marketing, Dev Experience, Dev Education, and community-oriented roles, and DevRel engineers. Although C-Level DevRel roles weren’t typical, positions like Chief Developer Relations Officer exist.
DevRel’s responsibilities include digital marketing (e.g., SEO, PPC, online ads), outreach through developer newsletters, nurturing campaigns, attending events, providing product demos, generating content, technical writing, developer education, and support and success tasks. These roles require a combination of technical expertise, strong research and analytics skills, social and writing skills, and in-depth product knowledge. This may be one of the reasons we see so many career-changers gravitating towards DevRel.
The point is, because of the variety of skills required for DevRel, which often overlap with other departments like marketing, sales, and engineering, there’s more lack of clarity around what DevRel should be accomplishing, who they should be answering to, and who they should be supporting. There’s sometimes a tug of war over whose asks should be prioritized.
DevRel Trends and Changes
The pandemic had an incredible impact on DevRel, forcing those in the field to focus on virtual engagement. Although initially, it would’ve appeared that the pandemic could have decimated the DevRel industry, quick adaptations, a global audience, and isolation created opportunities to grow virtual communities and relationships. So we ended up seeing the adaptability and resilience of the DevRel community and a growth of tools and platforms targeting online developer engagement.
As the world recovered from the COVID-19 pandemic, we saw a gradual return to in-person developer events, including meetups and conferences. Now, developer relations teams face the challenge of balancing the benefits of online engagement with in-person interactions. This left a lot of teams required to re-engage with the community in person and provide quality content online. In many circles, this led to additional tasks but not necessarily additional support.
Anecdotally, I saw the stress of increased responsibilities and the lack of the organization’s goals and focus lead to frustration, tension, and, ultimately, burnout.
We’ve also noticed in recent years that the DevRel field has been moving away from general developer advocate roles towards more specialized roles. The good news is that more people have realized that each advocate has their strengths and doesn’t need to be an expert in every type of DevRel.
Of course, there will continue to be general roles, but allowing specialization allows organizations to hire someone in DevRel who more perfectly fits the organization's goals. However, this can get complicated because many organizations hire DevRel positions without fully understanding their goals.
When companies hire but don’t understand
Over the last couple of years, we’ve seen many more companies hiring their first DevRel person. Although this might seem like a positive trend, we’ve also seen a lack of understanding, which leads to tension, often micromanaging, and DevRel teams being some of the first layoffs.
Hiring a DevRel team before the product-market fit is established or without a clear strategy can result in wasted resources and potentially harm the company, mainly if the frustration of the lack of focus follows the DevRel hire to the developers they’re advocating for.
Developer advocates need to be able to connect with developers on a personal level and build trust. I’ve seen companies, especially startups, hire their first on a DevRel team or a whole team because advisors or a board has recommended it, but no one really knows why. They think that to succeed, there needs to be a DevRel team. If you want users or, feedback or fast growth, then they need a DevRel team. They hire someone who’s a great developer but has no experience in DevRel. They hire someone who has a lot of followers on X/Twitter or TikTok or wherever their target audience is. They hire a team and then set up meetings strategizing on “how to go viral” because they “just need to do that once.”
Developer Relations is about building trust. Building trust takes time. If a team has a deadline for building trust, then that needs to be clear from the very beginning.
Let’s think about this in terms of relationships. How long does it take you to trust another person? How easy is it for that trust to be broken? Say you decide to go on a date with a new person. You want to get to know them a little before you decide to commit. What if that person tells you that they LOVE pineapple on pizza? And, hey, so do you! You have something in common with that person.
And then, a couple of weeks later, they decide they don’t like pineapple on pizza, and they don’t like pizza at all. You don’t just wake up and decide you don’t like pizza one day. Something else must be going on behind the scenes. It’s not a huge deal (maybe), but it will take you longer to build trust and find out if that person is being honest with you. You might always wonder, “Did they just say it in the first place because they knew that’s what I wanted to hear?”
Similarly, I’ve seen teams formed with a strategy in mind only to have that strategy constantly change because “it’s not working,” but there’s no clear definition of what it means to work. If you’re changing your favorite food constantly, you start losing credibility and trusting relationships.
That’s not to say you can’t change your strategy or target audience. But if you want to retain that trust, you can’t change your favorite food every couple of months. A better approach might be to say, “I love pineapple pizza, and I really love pierogies now, too!”
Hire someone who is passionate about developers and understands their challenges.
Developer Relations success takes time; if you don’t have that, you’re setting your team up for failure.
Creating DevRel Goals
Another problem I’ve seen in the last year is that companies were throwing money at their DevRel team and saying, “Do your thing. We trust you.” And then suddenly, with the market shifting, they don’t trust DevRel anymore, and worse, they often blame them for the company's lack of success. The problem didn’t start with the market shift. The problem began with a lack of understanding of what DevRel teams do and the company's needs.
I’ve seen some DevRel teams succeed by being semi-siloed from the rest of the company, but I also think that leaves them as a target when things start to go back. “What do you all even do?” is never a good question. If those outside the team don’t understand what DevRel does, then it’s hard to tie success to your team, and that’s what needs to be done.
The times of companies just handing out money are over. You can’t just go to every conference because you’re on a DevRel team. You can’t sponsor every meetup or organization that asks you. You have to be able to justify being there. That justification means that you need to be able to show how you’re providing value to the company. That’s not an unreasonable ask. The justification can’t be, “I’m going to build relationships, but I can’t tell you how long that will take to pay off.”
Building relationships is great, but are you building relationships for your company and establishing their credibility, or are you making friends for yourself? There’s a difference.
If someone asked you for the elevator pitch for your company, could you give it? If someone asked you questions about the product, could you answer them or point them in the right direction?
I’ve spent more time than I would like identifying metrics and OKRs. But if you want to survive in DevRel, it’s something that you need to understand. Companies should not throw boatloads of money at someone without seeing a return on investment (ROI).
According to Trends in Developer Relations for 2023, the economic downturn has led to a reevaluation of DevRel’s role within organizations. Teams are being asked to focus on activities with the highest impact and justify their contributions in terms of measurable outcomes. This is not an unreasonable ask.
There has been a growing need for DevRel teams to understand how their companies make money and to align their goals with broader business objectives, which also often means closely communicating with product, sales, and marketing teams.
Identifying Metrics and Aligning Them with DevRel and Company Goals
The first step in measuring DevRel ROI is aligning DevRel goals with the company's larger objectives. With this, it's easier for other departments to see the value in DevRel activities. For example, suppose a company goal is to increase the fork rate of an open source project. In that case, DevRel strategies might include engaging with developers at relevant meetups, creating helpful content, or establishing community channels.
It’s going to look different for every team, but a general approach to aligning goals might look like this:
- Understand Company Objectives. This is the building block of the rest of this approach. DevRel teams should comprehensively understand the company's broader objectives, such as revenue targets, customer acquisition, product development, or market expansion.
- Identify DevRel's Role. How DevRel can contribute to these objectives? This could involve community building, developer advocacy, creating educational content, or fostering product adoption. Part of understanding the answer to this question is identifying the current painpoints of the organization. For example, maybe the product has tons of sign-ups but only a small percentage of those return to use the product. What’s happening between sign-ups and using the product? How can you re-engage those developers?
- Set Specific DevRel Goals. Create a bridge between the company objectives and the DevRel role. For example, if a company aims to retain more users, a DevRel goal might be to improve developer onboarding and user experience.
- Develop Aligned Strategies. How can DevRel support these goals? It's important to be selective about activities and events, choosing those that align best with the team's goals and capabilities. This could include creating content about how to use the product, improving documentation, creating technical tutorials, or gathering developer feedback.
- Track and Measure Impact. Find ways to measure the impact of DevRel activities on the goals. As part of that process, regular reviews and strategy adjustments help to ensure alignment with company objectives.
I think it’s worth noting that although this can be a tedious part of the process, it can help to understand the expectations of the DevRel team and of each teammate. It can also help team members grasp what success looks like for them. When we evaluate these goals regularly, we’re better able to pivot with changes in the company, adjust to market conditions, and prevent burnout.
One of the challenges of tracking is that DevRel activities often don’t necessarily directly correlate to revenue, but there’s a widely held belief that it can influence it positively.
So, for example, the goals won’t be directly related to X-increase in revenue but rather, to the creation of a strong community and product, which indirectly results in increased revenue.
The tricky part is finding the right balance.
It’s hard to quantify relationship and community building, but it’s necessary to build them. We also sometimes see a fine line between marketing and relationship building coming as a top-down directive. There are things that will be easy to track: new users, returning users, and feedback submissions. But for the things that are more challenging to track, you have to learn how to tell the story and justify their importance, even if you didn’t yesterday or last month, or at the beginning of your career.
DevRel Status: It’s Complicated
I’ve been fortunate enough to know some amazing people in Developer Relations. Over the last couple of years, I’ve learned so much through my conversations with them, reading and watching their content, and asking questions. Their authenticity and depth of knowledge allow them to be approachable, encouraging, and helpful.
I’ve also seen a lot of bitter people in DevRel. I’m not sure if this impacts all of tech equally, but I’ve definitely seen it more than I expected in DevRel. I think some of this stems from layoffs, lack of clarity of direction, organizations blocking their teams from making progress, and burnout.
And somewhere in this mix of DevRel, we start to see a little bit of an echo chamber. This is a hard one to talk about. I really love the DevRel community, but sometimes we talk to each other instead of talking to developers. We write for each other, instead of writing for users.
Everyone knows the company that they’re representing, and we all like each other’s posts and go to each other’s talks because we (maybe subconsciously) know that our fellow Developer Advocate will appear to be successful with high numbers.
Another part of the problem of the echo chamber is the lack of growth in the field that comes with it. If you’re trapped in the echo chamber, you’re less likely to hear diverse ideas and which can impede the ability to understand and address the needs and challenges of a broader developer community.
It’s the job of Developer Relations teams to understand the needs of their developer community. When you don’t spend time understanding your community, there’s a disconnect and a lack of trust. You’re missing opportunities for meaningful engagement and collaboration.
One of the biggest problems caused by the DevRel echo chamber is a skewed definition of success and impact. If you’re only receiving feedback and defining (or not defining) metrics based on your echo chamber, you’re not getting the full understanding to be able to do your job well and to create initiatives that align with your larger organizational goals.
Another problem of the echo chamber is your perspective can create a barrier to recognizing and responding to emerging trends, technologies, and market needs. If you’re stuck in the same conversations with the same people, there’s a higher potential for becoming outdated or irrelevant.
When we spend more time promoting each other’s work, and the primary growth we see is only in our DevRel audience, we’re not building authentic relationships with the audience we’ve been hired to engage with. I want to point out that this is different than forming collaborations with other DevRel teams. If you can both get value out of collaborating by expanding your audience because it makes sense for both of your audiences to use these products, then you’re doing your job.
Your goal should focus on advocating for developers who are using your product, understanding their needs, and supporting them through your content creation.
AI and DevRel
On top of everything else, the recent boom of AI has further impacted the DevRel field in various ways. DevRel teams have been exploring how AI can be helpful in key areas of their work, including using GitHub CoPilot to help generate demos and code, to write documentation, and to brainstorm talks and blog posts.
We’ve seen this both improve the speed of people in DevRel and cause controversy, with some using it to write entire articles, talks, and more. There’s no consensus on the appropriate use of AI for content creation. One of the most critical elements of success is authenticity, and there’s a negative connotation associated with using AI as part of the creation process.
Complicating things further, companies have seen the capabilities of AI and imagined them as substitutes for Developer Relations roles. Why should we hire someone when we can just use AI to complete their tasks? The problem with that logic is you’re not developing relationships, which is the primary goal of DevRel. This substitution further exemplifies that there’s a lack of understanding of what DevRel is.
Today’s DevRel
We’re in a space now where DevRel can’t be what it was before. We’ve crossed a line past the pandemic era of fully remote, but haven’t returned to the full power of in-person--although I don’t think we’ll ever see the return of in-person events like they were before, largely for the same reasons DevRel won’t be what it was before.
There’s been a shift to a more conservative approach to DevRel. Budgets are tighter, reporting is required. But it’s not all bad news. In fact, it’s good news for the people who are good at their job on DevRel teams.
The best people will continue to find jobs, and to avoid some of the common pitfalls or mistakes we’ve looked at in this post. And with that, you’re more likely to be on a stellar team of DevRel professionals. When we find ourselves in a place where we’re surrounded by the best, we’re more likely to grow and to push each other.
Engineers who DevRel
Another option I think that we’ll see increasingly more popular is engineers who do DevRel activities. What do I mean by that? Take for instance, my team at OpenSauced. I’m on the DevEx team. We have four engineers, all of whom have written blog posts for our community blog. Most of our engineers have given tech talks, or produced other forms of content, including livestreams, TikToks, and more. Their primary role is engineering, but they’re great at DevRel and community-building goals as well.
Engineers taking on DevRel responsibilities might bring deeper technical expertise to community engagement, and from that, we may see a shift in content that engages a broader audience of developer expertise level.
Blending engineering and DevRel roles could lead to more diverse career paths, allowing professionals to develop a unique combination of skills in both development and community engagement. It also helps to close the feedback loop when engineers engage with users and community members.
No matter what, as the role becomes more multifaceted, the best DevRel professionals will likely be those who can effectively balance technical expertise with community-building and communication skills.
The triple threat DevRel professional excels at technical excellence, strategic thinking, and content creation and community building.
What does this mean for the future of DevRel? It means that we make sure that strategy, feedback, and self-review are built into our progress. We should be looking at the strengths and weaknesses of the company, the team, and ourselves. Thinking about the future of DevRel and the instability of jobs, I see a tendency for those looking for a job to try to improve their weaknesses rather than improve their strengths. But studies have shown that it’s actually more efficient to improve on our strengths that our weaknesses. So maybe, when we think about what the future looks like for us, we should think about our strengths and how we can optimize them to achieve the goals that are in front of us.
Top comments (0)