The Compass I Wish I'd Had: Why I'm Building a Community for the Next Wave of DevRel

Over five years ago, I was designing onboarding flows, writing documentation, and designing community programs to help developers get started in open source and cloud native communities. If you had asked me what my job title was, I wouldn't have known what to tell you. I certainly didn't know that what I was doing had a name: Developer Relations (DevRel).

Yet I was already doing the work.

Like many people in Developer Relations today, I didn't follow a traditional path into the profession. My academic background was in microbiology. When I transitioned into technology as a frontend engineer, I quickly discovered something that many newcomers still experience today.

Most tutorials assumed too much context. Documentation often explained what something did but rarely why it mattered. Technical articles skipped the reasoning and jumped straight into implementation. There was plenty of information, but very little understanding.

To solve my own problem, I started writing. I wrote the guides I wished had existed for me, by breaking down complex cloud-native architectures and developer tools into digestible, high-signal articles. This natural pivot toward open-source and cloud-native communities has me asking one question:
Why do some developer tools become indispensable while others, despite being technically excellent, struggle to gain adoption?
The answer is not about the technology but in the ecosystem around the technology.
Developers don't adopt products because documentation exists. They adopt products because they understand them. They trust them. They can solve problems with them. They know where to ask questions. They see other developers succeeding with them. In other words, adoption is a system.
Documentation, education, community, advocacy, product feedback, conferences, tutorials, office hours, GitHub discussions, and open source contributions aren't independent activities. They're connected parts of the same developer journey.

Realising this made one thing clear for me I was in a careers path that sits at the intersection of engineering, product, marketing, and community. So I didn’t just want to build with these technologies; I wanted to simplify the developers experience around these tools.

Discovering that DevRel is a Systems Problem

The transition into DevRel is rarely a straight line. I had to piece together my career map from technical writing, to community management, to developer advocacy, documentation experts with no defined path. I pieced it all together from lessons volunteering to various open source communities, scattered blog posts, feedback from experts, a few mentors who answered when I asked, and a lot of trial and error I'd rather others not have to repeat.

That's the problem I keep seeing alot of aspiring developer advocate and DevRel enthusiast run into. The knowledge on what it takes to do the work well exists, but it's fragmented across books, big organisation with strong DevRel teams, videos or articles that skip the struggle.

Aspiring advocates are told to "build in public," "be technical," and "grow a community," with almost no honest, practical detail about how. So talented people bounce off the field, burn out, or spend their first two years learning things a single good conversation could have taught them.
I don't think it has to be that way. So I'm building the thing I wish I'd had: a growing library of practical resources for people who want to build a real, rewarding career in DevRel.

An extensive playbooks that is benefitial to thousands or millions of aspiring devrel enthusiasts and provides a roadmap into:

Developer Relations as a discipline: how the role really works, how it's measured, and how to grow from your first advocacy task to owning strategy.
Developer education: designing docs, tutorials, and programs that change what developers can do, not just what they've watched.
Technical writing: the underrated superpower of DevRel; the skill that simplified how developer understand and use a tool.
Community strategy: how to build spaces people return to, and understanding the systems and incentives underneath adoption.
Open source: where many of us started, and still one of the most honest ways to learn, contribute, and be seen.

The goal is to democratize access to the strategic playbooks of DevRel. This means writing honestly about the "messy middle" of this career path, detailing the backend work of setting up developer metrics, managing cross-functional stakeholder expectations, and preventing advocacy burnout.
To make this happen, we are building:
A Public Career Roadmap: A clear, step-by-step pathway from junior engineer or technical writer to Head of DevRel.
Practical Skills/Resume Assessments: Self-guided evaluations to help practitioners identify gaps in their technical, content, or community skill sets.
A Gatekeeper-Free Space: A community where senior leaders and aspiring advocates can share raw, real-world case studies and operational templates.
I think of what I am doing as building a compass rather than a checklist fo resources.
Because, a compass helps you navigate when the terrain changes. And if there's one thing we know about Developer Relations, it's that the terrain never stops changing, yesterday may be platform tools and IDPs today is AI and MCPs. The resources I'm building won't remove that uncertainty. But I hope they'll make the journey a little clearer and help Developer Advocates and aspiring DevRel professionals find their own direction and build rewarding careers. Because five years ago, I had to build my own map.
Whether you are transitioning from a non-traditional background, looking to sharpen your docs-as-code workflows, or trying to measure community gravity, you can navigate your path with https://www.devrelcompass.com/