On August 25th, at the Open Source Summit Europe in Amsterdam, the Linux Foundation announced the formation of the Developer Relations Foundation (DRF) . DRF is a community-driven project under the Linux Foundation, with a mission to advance professional practices in developer relations and raise awareness of its role as a driver of business value.
As an early member of the CNCF Ambassador program and a long-time contributor to open source communities, I deeply understand the importance of Developer Relations (DevRel). This article systematically analyzes the roles, organizational positioning, value, and measurement of DevRel, drawing on personal experience and industry observations to help enterprises and individuals understand and effectively leverage DevRel.
What Is DevRel and Why Do Companies Need It?
Developer Relations (DevRel) – also known as Developer Advocacy or Developer Evangelism – is fundamentally about serving and empowering developers. A DevRel professional acts as the connective tissue between those who build software and those who use it. This means gathering developer feedback, surfacing pain points, and advocating internally for improvements, while also educating and supporting external developers in using a product or platform. In simplest terms, DevRel represents the voice of developers inside the organization and the voice of the product in the developer community.
This dual role requires building a very specific kind of trust. Internally, the company trusts DevRel because of their credibility with developers – they understand the ecosystem and can spot what truly matters to developers. Externally, developers trust DevRel when advocates show up with authenticity – being honest about what works and what doesn’t, instead of parroting marketing copy. This double trust is the backbone of effective DevRel, and if it breaks on either side, the whole system fails.
For companies whose products target developers – such as API platforms, cloud services, SDKs, open-source projects, etc. – DevRel is often mission-critical. It drives awareness and adoption through authentic technical content, demos, and community engagement, in ways traditional marketing cannot. Developers are a skeptical audience; they value truth and usefulness over sales pitches. A strong DevRel function helps a company earn developer love by improving documentation, smoothing onboarding, providing support, and fostering a community around the product. In fact, the Linux Foundation explicitly notes that DevRel should be recognized as a driver of business value in tech companies. When done right, DevRel can create a virtuous cycle where satisfied developers become product advocates, leading to organic growth. (Some industry leaders even observe that companies with mature DevRel programs achieve significantly higher developer adoption rates and lower customer acquisition costs over time.)
Not every business needs a dedicated DevRel team – but any company building tools or platforms for developers ignores DevRel at its peril. As early as the 2010s, developer-focused startups like Twilio, SendGrid, and New Relic proved the impact of community-first outreach, with engineers giving talks at meetups instead of relying solely on glossy marketing. Their success in building passionate user communities set a model that others rushed to copy. Today, virtually all major tech firms (from AWS and Microsoft to open-source foundations like CNCF) invest in DevRel to some extent. DevRel has become the competitive differentiator that turns a good developer product into a thriving ecosystem.
How the DevRel Role Has Evolved (2018–2025)
In the past few years, Developer Relations has grown from a niche or misunderstood role into a more structured, essential function. Back in 2018, many organizations were still figuring out how to define and justify DevRel. Often a lone “developer evangelist” would be hired to do a bit of everything: write blogs, speak at events, answer forum questions, and so on. That lone-hero model is now fading, replaced by cross-functional DevRel teams with specialized roles. Today’s DevRel org might include developer advocates, community managers, technical writers, content creators, developer experience engineers, and program managers all working together to create a better developer experience. This broad scope reflects DevRel’s nature – it touches product development, documentation, marketing, support, and community building all at once.
The terminology has matured as well. Many have shifted from the term “Developer Evangelist” to “Developer Advocate” to avoid the religious connotation of evangelism and emphasize advocacy for developers’ needs. The core mission remains the same – helping developers succeed with your technology – but there is greater awareness now of how to do that systematically.
One major change is the recognition of DevRel as a profession with career progression. In 2018, it was common for developer advocates to feel their role was ill-defined or lacked a growth path (leading to an “identity crisis” in some cases). By 2025, this is starting to change. Companies are creating staff engineer or principal advocate positions and even VP-level roles for DevRel leaders. It’s not unusual now to see a Developer Relations organization led by a Head/Director of DevRel who sits at the executive table. The emergence of the Developer Relations Foundation in 2025 under the Linux Foundation is a landmark in this evolution. This new DevRel Foundation’s mission is to elevate the professional practice of DevRel and increase awareness of its business value. In the past year it has worked on standardizing career paths, skill frameworks, and metrics to validate DevRel’s impact. In short, DevRel has “grown up” – there’s now a community-driven effort to formalize what good DevRel looks like, which simply didn’t exist a few years ago.
The role itself has expanded in response to industry changes. For example, the COVID-19 pandemic forced DevRel to reinvent developer outreach beyond in-person conferences (leading to more online communities and content). More recently, the rapid rise of AI and generative coding tools has added new dimensions to what DevRel must cover. A developer advocate in 2025 might be fielding questions about LLM integration or demonstrating AI-assisted workflows – topics that barely existed in 2018. As one DevRel leader notes, “In 2025, being a Developer Advocate doesn’t just mean staying up-to-date on frameworks or cloud tooling. It means learning how to prompt effectively… and knowing how to teach new mental models to teams” in the era of AI. The constant need to learn and adapt has only accelerated. Successful DevRel professionals today embrace being lifelong learners and often learn in public (sharing what they learn with the community in real time). This transparency about the learning process helps build credibility, especially when technology is moving faster than any documentation can keep up.
Another trend is the emphasis on data and accountability. As DevRel matures, there’s more pressure to demonstrate its value in concrete terms. Gone are the days when vague metrics like Twitter follower counts were enough. Modern DevRel teams track a mix of leading indicators (content views, community engagement, event participation, developer sentiment) and lagging indicators (growth in active developers, product adoption rates, contributions, even revenue influenced). There’s an industry-wide push to establish standard DevRel metrics frameworks. In fact, 61% of DevRel professionals say they struggle to prove their impact in business terms – a challenge the DevRel Foundation aims to solve by creating shared “proof points” and KPIs for DevRel’s business impact. All of this signals that DevRel is becoming more data-driven and aligned with business outcomes than it was a few years ago.
Key Responsibilities and Skills of DevRel
Despite the expanding scope, at its heart a DevRel professional’s job is to make developers successful with your product. To do this effectively, certain skills and responsibilities are paramount:
- Technical acumen and empathy: A great developer advocate is usually a developer themselves (or has been one). Writing production code or building projects gives them the firsthand empathy to understand other developers’ challenges. Technical credibility is foundational – you don’t have to be the deepest engineer on the team, but you must be able to speak developers’ language, build sample apps, debug issues, and evaluate APIs critically. More importantly, you need technical empathy: the ability to see the product from the developer’s perspective, identify what’s confusing or broken, and help fix it. This might involve creating clearer documentation, suggesting improvements to the SDK, or providing feedback to product teams. A DevRel who can’t code at all or lacks curiosity about the technology will struggle to earn developers’ respect.
- Communication and content creation: DevRel is a highly public-facing role. Advocates spend a lot of time writing blog posts, tutorials, and documentation; giving talks or live demos; creating videos or podcasts; engaging on forums and social media; and generally teaching developers. The ability to explain complex technical topics in an accessible way is essential. This includes tailoring the message to different audiences – from beginner developers just getting started, to experienced engineers looking to dive into advanced use cases. Being an effective communicator also means listening: DevRel folks often act as community managers, moderating discussions, answering questions, and relaying feedback. They must handle these interactions with patience and clarity, even when faced with tough questions or criticisms.
- Community building and advocacy: The “relations” in Developer Relations is all about community. DevRel teams nurture communities of users around their technologies – whether through organizing meetups, running ambassador programs, or simply being present where developers gather (Slack/Discord channels, Stack Overflow, GitHub, etc.). For example, the Cloud Native Computing Foundation’s Ambassador Program empowers volunteer community leaders to promote CNCF projects through mentorship, content, and events. These ambassadors act as extensions of the official DevRel team, helping make cloud native tech ubiquitous. A DevRel professional often coordinates such programs or at least engages with these community champions. They recognize and amplify community contributions, turning enthusiastic users into advocates in their own right. The skillset here includes event planning, relationship management, public relations, and a knack for making everyone feel welcome and heard.
- Cross-functional collaboration: Uniquely, DevRel roles sit at the intersection of multiple departments. On any given day, an advocate might be debugging with engineering, contributing to product roadmap discussions, creating a marketing campaign, and assisting a sales engineer with a customer’s technical proof-of-concept. Bridging silos is a core part of the job. In fact, one of DevRel’s greatest values is connecting product, engineering, marketing, support, and even sales teams so that the developer’s experience is coherent. Internally, this means DevRel must translate developer needs to business stakeholders – sometimes literally translating “developer speak” into language executives understand. Externally, it means coordinating messaging and support so that developers get a consistent, positive experience. Collaboration skills and diplomacy are key, since DevRel often has to negotiate between what the community wants and what the business priorities are. A strong DevRel professional can work with all these teams and speak each of their “languages” to keep everyone aligned on making developers successful.
- Advocacy and authenticity: As emphasized earlier, authenticity is non-negotiable in DevRel. Advocates must genuinely care about helping developers, even if it sometimes means giving them bad news or acknowledging shortcomings. This can put DevRel in a delicate position – they are advocates for the product, but also advocates for the developers. The best DevRel practitioners manage this balance by always focusing on long-term trust over short-term gains. For instance, if a product feature is not ready or an API has bugs, it’s better to be honest with the community and perhaps even assist in finding workarounds, rather than spinning a marketing message. Internally, advocacy might mean pushing the company to fix or prioritize something because “this is hurting developer adoption.” It takes conviction and integrity to be this “voice of the developer” in meetings, especially when it conflicts with other objectives. But when DevRel succeeds in steering the company to truly solve developers’ problems, the payoff is huge: a reputation for trustworthiness and a loyal developer base.
In summary, an effective DevRel professional wears many hats – educator, translator, evangelist, engineer, community organizer, and customer advocate all at once. It’s a demanding role that requires both technical and people skills in equal measure. This is why not everyone is cut out for it, and why those who excel at DevRel have become highly sought-after in the tech industry.
Where Does DevRel Fit in a Company?
One question that often arises is which department should DevRel belong to? The truth is, there’s no one-size-fits-all answer – DevRel’s cross-functional nature means it can fit under Marketing, Product, Engineering, or stand as its own function, depending on the company’s goals and culture. Each approach has pros and cons:
- DevRel under Marketing: This is common in companies that see DevRel primarily as a top-of-funnel growth driver. In a marketing-led model, DevRel focuses on awareness – producing blog posts, webinars, conference talks, etc. – and works closely with product marketing on messaging. The strength is access to marketing budgets and amplification channels, which can rapidly increase reach. However, the weakness is the risk of being seen as just another marketing channel. If not careful, the DevRel team might be pressured to prioritize lead generation and polished campaigns over authentic engagement, which can erode credibility with developers. This model works best when the company needs to grow its developer user base quickly, and when marketing leadership truly understands how developer trust is earned (e.g. giving DevRel the freedom to be candid and technical).
- DevRel under Product/Engineering: Here, DevRel is embedded with the product development org. The mandate shifts to improving the product by injecting developer feedback and ensuring the developer experience is superb. The strength is strong technical alignment – DevRel can influence product roadmaps, work on SDKs or APIs directly, and maintain high technical credibility. The community sees them as part of the engineering team, which can increase trust. The weakness can be limited bandwidth for broad outreach; if engineering leadership prioritizes feature development, community programs or marketing activities may get less attention. This model shines for deeply technical products (databases, cloud infrastructure, developer frameworks) where getting the product right is paramount and the developer audience expects depth over breadth. It may be less ideal if a company’s challenge is more about awareness than product fit.
- DevRel under Sales/Customer Success: Less common, but some later-stage companies align DevRel with revenue teams. In this case, DevRel acts almost like super-charged solutions engineers – creating demos, helping strategic prospects overcome technical hurdles, and accelerating adoption in key accounts. The obvious strength is easy ROI attribution: DevRel can point to deals closed or expanded with their help. But the weakness is a potential loss of community trust if every interaction feels tied to a sale. Developers can sniff out when advocacy isn’t genuine. This structure can work in enterprise-focused companies where developer adoption directly shortens sales cycles, but it requires careful boundaries (DevRel should still primarily focus on education and enablement, not selling).
- DevRel as a Standalone (or Hybrid): In some organizations, DevRel is its own department reporting to a senior executive (CTO, CPO, or even CEO). This can indicate that developers are considered a first-class customer segment. A standalone DevRel team often has a broad charter – part community, part product feedback, part marketing – and must balance those priorities. The strength is independence and flexibility: DevRel leadership can set a strategy that isn’t narrowly confined to one function’s metrics. The team can serve as a hub connecting various departments (a bit of marketing, a bit of product, etc.). The weakness is that without strong executive support, a standalone DevRel team might struggle to secure resources or clarity of purpose. It can become an “island” if not integrated well. When it works, though, this model allows DevRel to truly focus on developer success as the north star, and align all other efforts (awareness, product, support) around that.
Ultimately, organizational placement matters less than cross-functional alignment. One insightful analogy describes DevRel as the “gold filling in Kintsugi” – the Japanese art of mending broken pottery with gold – meaning DevRel fills the cracks between teams and holds the whole effort together. Regardless of where the team reports, DevRel should collaborate across marketing, product, engineering, and support. As DevRel expert Jim Bennett notes, “Done well, it’s such a strong collaboration across all the orgs… it should have access to marketing budget as well as product teams”, even if it sits in one department. The only consensus on what doesn’t work is tying DevRel too directly to Sales quotas – that tends to undermine the trust and educational nature of the role.
Which companies should invest in DevRel? The short answer: any company for whom developers are a key audience or user base. This obviously includes API companies, developer tooling firms, cloud and infrastructure platforms, and open-source project maintainers. If your business model depends on developers adopting your technology (and ideally advocating it to others), you need DevRel. Even at earlier stages, startups have seen the benefit of hiring an advocate or community manager to build up grassroots awareness and feedback loops. For instance, EngineYard and Twilio were relatively small when they pioneered DevRel programs to engage developers at hackathons and meetups. Their success showed that community-driven growth can outpace traditional marketing in reaching developers. On the flip side, if you produce a consumer app or B2B product with no extensibility and no developer users, a DevRel team would likely be misplaced.
It’s also worth noting that industry foundations and open-source ecosystems leverage DevRel concepts through community programs. The CNCF’s Ambassador Program we mentioned is a great example: it harnesses volunteer DevRel energy to support a broad open-source community. Similarly, Microsoft and Google long fostered MVP or Google Developer Expert programs to recognize community contributors. These initiatives create a halo effect around technologies by enabling independent voices to educate and inspire others. Companies considering DevRel should think not just in terms of their own employees, but how to empower and partner with community members in a mutually beneficial way.
The Value DevRel Brings (and Common Pitfalls)
When executed well, Developer Relations can yield tremendous benefits:
- Faster Adoption and Higher Retention: Developers have a “show me, don’t tell me” mentality. DevRel helps by showing developers exactly how to succeed with a product – through sample code, tutorials, and direct Q&A. This hand-holding accelerates time-to-value. Moreover, a supportive community and good docs (often driven by DevRel) make developers more likely to stick with the platform. Some DevRel leaders have noted that companies with strong, authentic DevRel programs enjoy 3-5× higher adoption rates and see developers onboard more quickly than competitors. While exact figures vary, the impact on growth is clear.
- Product Improvement and Innovation: Because they constantly gather feedback and sit at the intersection of user needs and the product team, DevRel can heavily influence the product roadmap for the better. Many DevRel teams maintain a tight feedback loop with engineering – reporting usability issues, missing features, and integration challenges that developers encounter. This often leads to rapid fixes or new features that directly remove friction. In some cases, DevRel members even contribute code or tools (e.g. CLI utilities, client libraries) that significantly enhance the developer experience. The outcome is a product that aligns more closely with what developers in the field actually need, giving the company a competitive edge. A classic example is how Kubernetes gained huge adoption in part due to advocates (like Kelsey Hightower) who not only educated the community but also fed back improvements and created supporting tools. Kelsey Hightower himself, a renowned staff Developer Advocate at Google, became “known for his work with Kubernetes, open-source software, and cloud computing” – effectively shaping and evangelizing the Kubernetes ecosystem.
- Community Trust and Brand Loyalty: A vibrant developer community can become a moat for a technology company. When developers feel truly supported and heard by a company (thanks to DevRel efforts), they reciprocate with loyalty and even advocacy on the company’s behalf. They answer each other’s questions, write blog posts, create third-party libraries, and speak positively about the product. This kind of organic evangelism is priceless – it’s more credible than any ad or official campaign. DevRel helps nurture this by recognizing community contributors (shout-outs, ambassador programs, swag, etc.), and by maintaining a two-way dialogue. Importantly, DevRel also manages expectations and defends the community’s interests. If there’s a trust breakdown – say the company makes a decision that alienates developers – DevRel often acts as a mediator to explain the company’s reasoning to the community, or to push back on the company internally if the backlash is severe. Keeping that trust is key to preventing churn and maintaining a positive brand reputation in developer circles.
However, DevRel is not a silver bullet, and there are pitfalls and challenges to be mindful of:
- Proving ROI and Fighting for Resources: As mentioned, one of DevRel’s perennial struggles is quantifying its business impact. Skeptical executives might ask, “How many sales is our DevRel team bringing in?” or “Developers love us, but is that translating to revenue?” These are fair questions, and DevRel teams must prepare to answer them in the language of business outcomes. The lack of understanding from upper management can lead to underfunding or even sudden cuts to DevRel (there have been unfortunate instances of entire DevRel teams laid off when companies hit a rough patch, because leadership saw them as non-essential). To avoid this, DevRel leaders need to align their objectives with company goals – whether that’s user acquisition, product adoption metrics, or customer retention – and report on those. The emerging metrics frameworks and the DevRel Foundation’s work on “shared language and proof points” aim to help here. Still, it remains a challenge to get especially non-technical executives to appreciate DevRel’s long-term value versus short-term ROI. Persistence and education are required on the DevRel side to justify continued investment.
- Lack of Clarity and Scope Creep: If a company doesn’t define DevRel’s mission clearly, the team can be pulled in every direction – writing endless content with no strategy, fielding support tickets, doing sales engineering tasks, etc. This leads to burnout and diluted effectiveness. One common failure mode is when DevRel is treated as a dumping ground for miscellaneous tasks: documentation, support, QA, marketing, all rolled into one without focus. To combat this, organizations should articulate what they expect from DevRel (e.g. “Drive developer adoption and satisfaction for our API platform”) and what they do not (e.g. “DevRel is not a substitute for having a support team or a UX research team, though they collaborate with those functions”). A clear charter helps DevRel prioritize and also set boundaries so they can excel at their core responsibilities.
- Superficial Engagement or Inauthenticity: Developers can tell when an outreach effort is just for show. If a company launches a developer community but doesn’t genuinely engage, or if an advocate only posts polished demos that hide all flaws, developers may disengage. Authenticity is fragile – once lost, it’s hard to regain. A common pitfall is focusing on vanity metrics (like number of events attended or signups from a hackathon) rather than actual value delivered to developers. DevRel must resist internal pressure to become a pure marketing mouthpiece. As DevRel veteran Ashley Willis puts it, “We don’t just parrot marketing copy… We tell the truth… That honesty is what earns long-term trust.”. Companies that force their DevRel team to oversell or spin things will quickly find that credibility in the developer community evaporates. This is why many caution that DevRel “should never be tied directly to revenue” quotas – the minute an advocate is seen as just a sales rep in disguise, their influence with the community wanes. Maintaining an authentic, helpful tone even when promoting your product is an art DevRel teams must master.
- Lack of Company-Wide Understanding: Even in 2025, DevRel faces an awareness and identity challenge. The DevRel Foundation found that about half of DevRel professionals say their organizations struggle to understand DevRel’s impact or even its purpose. Internally, developers in DevRel roles sometimes feel they have to constantly explain “what we do” to colleagues or justify their existence to skeptical managers. This can be demoralizing and is part of the “identity crisis” the field has faced. It stems from the fact that DevRel is a hybrid role – not purely engineering, not purely marketing – so some traditional org structures don’t know where to slot it. Educating your company about what DevRel is (and isn’t) is an ongoing task. Having quick answers to “What is DevRel and why are we paying for it?” is critical. The best DevRel teams proactively share their wins and developer insights throughout the company to demonstrate value. Over time, a track record of tangible improvements (say, increased adoption after a new doc series, or a key product fix that came from community feedback) will turn colleagues into allies. But patience is required to get there. As DevRel pioneer Stacey Kruczek noted, the new Foundation is helping by creating standardized frameworks and language so that we “no more [have to] explain our role to confused hiring managers” in each company.
- Scaling and Consistency: What works in DevRel at a small scale (e.g. one advocate informally chatting with users) can break as your community grows. Ensuring consistent quality of engagement – every question answered accurately, every local meetup getting support, documentation kept up-to-date – becomes harder with tens of thousands or millions of developers. DevRel teams need to scale through programs (like training external ambassadors, creating self-service resources, leveraging content platforms) so that they don’t become a bottleneck. This requires strategic thinking: prioritizing which developer segments or integrations to focus on, empowering community members to help each other, and sometimes saying no to things that don’t scale. Mature DevRel organizations often develop frameworks and templates for common activities (e.g. event playbooks, content style guides, community moderation policies). These help maintain consistency and quality as the team and community expand.
In short, DevRel can fail when it’s done half-heartedly or for the wrong reasons. A poignant analysis by DevRel expert Dewan Ahmed identifies issues like companies treating DevRel as a checkbox, not investing in docs or support, misunderstanding developer needs, lacking trust or authenticity, and under-resourcing the team as top reasons DevRel programs falter. Avoiding these pitfalls comes down to genuine commitment – a company must truly prioritize developer success and equip its DevRel team with the mandate and resources to make a difference. Without that, even a talented DevRel team will be fighting an uphill battle.
DevRel Career Path and Opportunities
For individuals, Developer Relations offers a uniquely rewarding career at the intersection of technology and people. Many DevRel professionals come from engineering backgrounds but choose a path focused on education and community rather than pure coding. Historically, this could feel like a dead-end or a detour from the “standard” engineering ladder, but that is changing. As the industry matures, clear career progression paths for DevRel are emerging:
- Individual Contributor (IC) routes: One can start as a Developer Advocate (or Developer Evangelist) and, with experience, grow into more senior advocate roles (e.g. Senior, Staff, Principal Developer Advocate). These higher-level IC roles involve greater influence and leadership without direct management – for example, a Principal Developer Advocate might set DevRel strategy, own key community relationships, and be the public face of the company at major events (an example is Google’s Kelsey Hightower, who became a distinguished engineer through his advocacy work). Similarly, a technical community manager could become a Community Architect or Principal Community Strategist guiding how the company engages its open-source ecosystem. Some ICs also specialize: one might become a Lead Technical Writer or Content Architect heading up developer content strategy, or a DX (Developer Experience) Engineer focusing on tooling improvements. These roles recognize that deep expertise in developer engagement is as valuable as deep expertise in coding or marketing.
- Leadership routes: Another path is moving into management and strategy. A DevRel practitioner might become a DevRel Manager, leading a small team of advocates and coordinators, and then advance to Director of Developer Relations or Head of DevRel owning the whole program. At the highest levels, we now even see VP of Developer Relations or VP of Developer Experience roles, especially at developer-focused companies. These executives not only manage larger DevRel teams but also advocate for developers’ interests in product planning and company strategy. They often have to justify budgets and define how DevRel supports business goals at the C-suite level. The skills here extend beyond DevRel itself into general leadership, budgeting, cross-departmental coordination, and evangelizing the DevRel vision internally.
- Adjacent moves: Because DevRel is multidisciplinary, professionals sometimes transition into related fields. It’s not uncommon to see a developer advocate move into Product Management (leveraging their deep customer understanding to define product features), or into Product Marketing, or even into Engineering Management if they want to return to a core tech role. Conversely, people from technical writing or engineering or community management sometimes transition into DevRel because it offers a broader scope or a more external focus. This fluidity means DevRel folks have many options – their blend of technical and communication skills is highly transferable. It also means as the field grows, companies are more open to hiring DevRel from diverse backgrounds (not just coders, but possibly teachers, journalists, or community organizers who learned some coding).
One encouraging sign for the field is that companies are explicitly delineating DevRel ladders. For example, you might see job postings or internal levels like Developer Advocate II, III, IV with criteria, or a Principal Developer Evangelist position that is treated on par with a Principal Engineer. This formal recognition within HR frameworks legitimizes DevRel as a long-term career, not just a stepping stone. Additionally, organizations like the DevRel Foundation are compiling persona libraries and role definitions – listing out the skills and expectations for roles ranging from Community Manager to DevOps Advocate – to help standardize this across the industry. This helps answer “what does it take to be a Senior vs. Junior DevRel?” and what skill development to focus on.
For newcomers interested in DevRel, now is a great time to get involved. The field is more welcoming and understood than ever. If you’re a software developer who loves sharing knowledge, or a technical content creator who loves coding, you might find DevRel to be a perfect fit. You can start by contributing to communities (writing blog posts, speaking at meetups, helping in open-source forums) to build a track record. Many DevRel professionals got their first role by being active in a product’s community and catching the attention of that company. Networking with existing DevRel folks (for example, joining the DevRel Foundation’s Discord or attending DevRelCon events) can provide mentorship and insight into the profession.
Famous examples of DevRel careers can be inspiring. We’ve mentioned Kelsey Hightower, who rose to prominence by combining deep technical insight with an incredible knack for live demos and education in the cloud native world. Another example is Arun Gupta, who has led DevRel teams at Sun, Red Hat, AWS, and most recently Intel, and has been instrumental in articulating DevRel strategies (he is actively involved in community initiatives and often shares frameworks for DevRel team structures, metrics, and growth strategies). People like Sarah Drasner transitioned from engineering to head up developer experience at Netlify and Microsoft, demonstrating that a strong engineering foundation plus community skills can lead to executive roles. And there are many others carving out different niches – from docs and education specialists like Daniele Procida (author of “Diátaxis” documentation framework) to community organizers like PJ Hagerty or Mary Thengvall (who wrote The Developer Relations Handbook). The career paths are diverse, but they all show that DevRel is a viable and even booming career field.
It’s important to note that the DevRel career isn’t without challenges. Burnout can be common – all the travel, public engagement, and being the “face” of the product can take a toll if not managed. Some advocates decide to step back into pure engineering roles after a few years, either for a change of pace or to regain a sense of building tangible products. As one candid blog post by a former advocate put it, after several years of constant advocacy work he felt a need to “go back to software engineering” to recharge and work on concrete technical problems. This highlights that DevRel isn’t for everyone long-term; it requires passion for the unique mix of duties it entails. But for those who thrive at it, there’s never been more opportunity or community support than now.
Should Your Company Establish DevRel?
Developer Relations has transformed over the last decade from a quirky role often questioned (“What do those developer evangelists even do?”) into a strategic pillar for companies building technology platforms. In 2025, DevRel is about building relationships, trust, and ecosystems. It’s a role where you succeed only when your users (developers) succeed. That mindset – prioritizing the long-term happiness of developers – turns out to be incredibly powerful for business too, because happy developers drive adoption and innovation in ways money can’t simply buy.
If you’re an enterprise evaluating whether to invest in DevRel, consider this: the strongest developer ecosystems (think Kubernetes, React, Stripe, AWS) all have robust DevRel efforts behind them, cultivating communities and lowering barriers for new users. Developer Relations, when done right, can be the difference between having a good product and building a movement around your product. It creates a human connection to your technology. As one DevRel Foundation leader put it, “no more explaining our role to confused managers or reinventing community strategies from scratch” – the industry now recognizes that DevRel’s impact is real and needed. The formation of the DevRel Foundation itself underscores this, providing shared frameworks and a professional home for this discipline.
For companies, the takeaway is: invest in Developer Relations, but do so thoughtfully. Hire people who genuinely care about developers, empower them to be honest and helpful, and align the team’s goals with your business objectives without compromising authenticity. When developers see that your company values them – not just as users, but as partners – it builds goodwill that can propel your platform forward for years to come.
For developers or tech professionals, DevRel offers a chance to leverage your technical skills in a highly social, creative way. It’s incredibly rewarding to help someone solve a problem or to spark their excitement about a technology. Few things compare to seeing a developer go from frustration to “aha!” moment thanks to a tutorial you wrote or a tip you shared. In DevRel, you get to be an educator, an enabler, and sometimes even a hero in the community. And as the field matures, you’ll be joining a growing, global network of practitioners who share knowledge and support each other (again, consider hopping into the DevRel Foundation community or local DevRel meetups).
Conclusion
In closing, Developer Relations has come a long way since the early “evangelist” days. Its core ethos, however, remains unchanged: help developers succeed and they will help you succeed. In a software-driven world where developers are kingmakers, DevRel is how you earn their crown. Whether you’re looking to build a DevRel team or become a DevRel practitioner, remember that authenticity, empathy, and patience are your best tools – the rest can be learned. The companies that truly embrace this will cultivate not just users, but passionate advocates. And those are the kind of relationships that turn products into platforms, and technologies into communities.