Why I Joined the Developer Relations Foundation

For as long as I’ve been in Developer Relations—nearly 15 years now—one thing has been obvious: no two DevRel teams are structured the same way. And while that flexibility can be a strength, it also creates challenges. There’s no shared playbook, no widely accepted best practices, just a lot of trial and error across the industry.

When I was leading community at Orbit, which was like a CRM built for DevRel teams, I saw this up close. DevRel orgs were all over the place—sometimes reporting to marketing, other times to product or engineering, and in a few cases, even rolling up to a COO. That kind of variance makes it tough for DevRel professionals to learn from one another, advocate for their roles, or build teams that last.

So when I heard the Linux Foundation was launching the Developer Relations Foundation to tackle these questions, I knew I wanted to be involved. Now, as a co-manager of the working group focused on team structures and organization, I’m excited to contribute to this conversation—not as someone with all the answers, but as someone eager to listen, learn, and help facilitate the discussion.

Bringing Clarity to DevRel’s Organizational Chaos

Right now, DevRel is still the Wild West when it comes to team structures. The same job title can mean vastly different things depending on the company, and that inconsistency makes it harder for teams to scale, advocate for resources, or even measure success. Our working group isn’t here to dictate a single “correct” model—we all know that won’t work. Instead, we’re here to gather stories, identify patterns, and share what’s actually working (and what isn’t) for teams across the industry.

Open-Sourced Knowledge for the DevRel Community

One of the best parts of this initiative is that everything we produce—best practices, case studies, and other resources—will be open source. The Developer Relations Foundation isn’t just for people with “DevRel” in their title; it’s for anyone who engages with developers, from community managers to product marketers to technical writers.

And while I’m thrilled to be co-managing this working group, I know that most of the real work will be done by the participants. My job isn’t to set the direction—it’s to help create a space where the collective knowledge of the DevRel community can be captured and shared.

Learning, Listening, and Elevating the Conversation

Most of the DevRel teams I’ve built and led have been heavily focused on go-to-market and marketing functions, so that’s the perspective I bring. But I also know that’s just one piece of the puzzle. Every company, product, and community is different, and there’s no one-size-fits-all approach to DevRel. That’s exactly why I’m here—to learn from others, challenge my own assumptions, and help document what makes DevRel teams successful in different environments.

After years of seeing DevRel teams navigate ambiguity, I’m excited to be part of this group that’s bringing more clarity and shared knowledge to our field. If you’re passionate about DevRel, I’d love for you to get involved. Whether you want to contribute your experiences, challenge assumptions, or just follow along, come hang!