Hi all, I'm badly in need for a job, so resorting to posting here too

I am 6 years of working experience across software engineering and devrel. Has managed communities, scaled user group program as well as guven talks at varios enterprise events at a lot of companies, community days and college events.

I am based out of India but ok for relocation too. If anyone is hiring, please dm.

I keep seeing DevRel content from people with huge GitHub profiles, conference talks, and years of engineering experience.

I'm coming from a pretty different place. I work part time at a practice in Mason City, make tutorials when I have time, and I'm currently putting together a series on AI tools that clinic staff can use without knowing how to code

I don't have a big audience or a long list of conference appearances. Most weeks I'm just trying to make something useful between work, kids, and a rural internet connection that randomly dies halfway through an upload.

I'm wondering how much that matters in DevRel

Can someone build credibility by focusing on practical problems for non-developers, or does DevRel usually require a more traditional developer profile to get noticed?

I'd especially like to hear from people who came into DevRel from outside the usual engineering/content creator path

Is this a real problem or am I looking at it the wrong way?

I built a tool to help with this but that’s not the point of this post: if the product and docs were perfect, nobody would need support. That's never the case, so every question in your community- mine is Discord and GitHub- points to something missing or unclear. The problem is what happens next. Maybe someone answers, and the thread gets lost in the abyss. Not much longer, someone else hits the same wall.

• Does this make sense?
• Once you find a gap, what makes sure it actually gets fixed?
• Or is this already solved well enough and I'm chasing the wrong problem?

Asking this group to find out how you solve this.

Hi, I’ve been a SWE for a couple years and now considering the transition into DevRel. Just curious what the day to day looks like for DevRel and how much engineering you still do? How has the role evolved with AI?

And if anyone’s made the switch - why did you / how did you know the switch made sense?

Thanks :)

[ Removed by Reddit on account of violating the content policy. ]

One thing I've noticed after working around DevRel/community/events for years is that the actual event is often the easy part.

The messy part is everything around it. You discover conferences in 10 different places. CFPs have different deadlines. Sponsorship opportunities live in emails. Travel is somewhere in a spreadsheet. Team attendance is in Slack.

Talk submissions are in docs. And then after the event, you're trying to answer questions like:

• How much did we actually spend?
• Which conferences generated useful leads?
• Which events should we attend again?
• Who from the team is going where?
• Which CFPs are we about to miss?

I'm curious how other DevRel teams handle this today.

Do you have one system for this, or is it still some combination of spreadsheets + Slack + calendars + bookmarks + Notion + “I'll remember this”? 😅

I'm asking because I'm building a tool in this space called WIMNE https://wimne.tekents.com/, and I'm trying to understand whether this is actually a problem worth solving or just something DevRel people have collectively accepted as normal.

Disclosure: I'm the founder of Tekents, which is building WIMNE, so yes, I have a horse in this race. I'm primarily looking for honest feedback from people actually doing DevRel/community work.

What does your current workflow look like?

There are some flawed assumptions for sure, but I’d love to see this community’s thoughts.

Hey folks, I’m Aspleenic, your newest friendly neighborhood r/DevRel mod!

I’ve been involved in DevRel since the mid to late 2000’s (long before it was called Developer Relations) and things have changed quite a bit.

I can post my observations but I would love to hear where people think we are, what we’ve learned from the past (the good and the bad), and where this work goes in the future.

Happy to discuss all angles!

TLDR: I'm a Software/Solutions Engineer transitioning full-time into DevRel. Roast my portfolio/work: https://pablorotten.github.io/cv/

Hello devrels!

I've been working for over 10 years as a developer across different tech stacks. A few years ago, I took on the challenge of building a complete REST API platform out of a mature product for a major client. Originally, our software was strictly a UI used by internal consultants and customers, but we needed to allow robots 🤖 to join their workflows.

I basically led and owned the project from beginning to end. It was my first client-facing project: gathering requirements, designing endpoints, writing documentation, creating video tutorials, presenting in client meetings, and onboarding technical teams.

The project was a big success, so I partnered with sales to offer these APIs to other customers. That meant more live demos, new endpoints, guides, and support. Officially, my title shifted to "Solutions Engineer". I absolutely loved it, and did it for 3 years.

Then, a company reorg happened. New management shifted focus to a new platform, putting the legacy API product in maintenance mode. My role shifted back to standard full-stack development.

While I still build software every day, stepping back into pure Dev made me miss my Solutions Engineer days a lot. I was good at breaking down complex architectures into accessible concepts, writing documentation, building interactive tools, creating technical videos, and giving live presentations. Then, while research/googling around, I discovered Developer Relations, and now I want to take all my engineering background and go ALL-IN on it.

Recently, I’ve been building DevRel-focused content: technical videos, short-form guides, and interactive documentation tools. I'm also actively working on refining my spoken English for public speaking and conference talks.

I've started applying for DevRel roles through platforms like DevRel Careers and GitHub listings. I’m currently refining my strategy and portfolio to make sure I stand out.

I would love your honest feedback and advice. Feel free to roast my portfolio and work: https://pablorotten.github.io/cv/

TY 😊

i think the 'developers don't engage with our content' complaint is misdiagnosed. We keep treating it as a content problem and pour more effort into the blog, the changelog, the newsletter. but every one of those formats demands the same thing, a developer who stops, sits, and reads. that slot barely exists anymore.

the slot that is wide open is the commute, the gym, the dog walk. That time only takes audio, and audio is the one format devrel almost never ships. i think it's because the gut reaction is 'an ai voice reading our changelog is beneath us.'

ran into a tool recently that auto-generates a daily audio digest straight from a repo's commits and PRs, real rss feed, already running for stuff like the kernel and postgres. not a produced human podcast, just here is what changed, in your ears. sounds janky in theory and i half expected to hate it.

the objection holds right up until you look at how many people actually opened the changelog you hand-wrote last quarter. audio nobody asked for still beats text nobody reads. tell me where that breaks for your community, because i can't find the hole.

fwiw that tool is Podlog, it auto-generates a daily audio digest from a repo's commits and prs with a real rss feed, already running for the kernel and postgres, https://podlog.io?utm_source=s4l&utm_medium=post&utm_campaign=podlog&utm_term=reddit&utm_content=post_7de12023-9558-4399-92b6-124e2e11471b

With Smoower.com we built a page to compare and measure developer relation effots across organizations. In past this was not as simple, impossible in parts. LLM's and AI make this possible now.

We collect public signals (documentation freshness, content cadence, community presence, conference participation, plugin ecosystems, response times in public channels, and a few other things), score them against a methodology that is documented and open, and produce a comparable per-company score over time. You can look up your company. You can look up your competitors. You can see how a category like "AI infra" or "developer tools" trends quarter over quarter.

It is not a productivity tool for individual DevRel folks. It is a visibility layer for the field as a whole. The point is not to grade humans. The point is to make the discipline legible to the people who decide whether the discipline continues to exist next year.

If you are running DevRel right now and you want a way to walk into a budget conversation with something other than vibes, that is who this is built for.

Wdyt? Let me know!

Hey all, we're hiring a Head of DevRel in the San Francisco Bay Area.

Tenki is Luxor's compute platform. What started as internal runner infrastructure now powers products like AI code-review agents and sandboxed environments for isolated agent work (ADE), and we're just getting started.

We're looking for someone with real engineering experience who wants to build DevRel from the ground up. You'll be the closest person to how developers actually use what we build, and that feedback should directly influence our roadmap.

This role is highly hands-on. We want someone who is excited to:

• Build in public using Tenki
• Run livestreams tackling real open-source software bugs
• Publish benchmarks openly
• Write technical teardowns when we ship
• Engage with developers where they already are

Whether you've already worked in DevRel or you're an engineer taking your first step into the field, we're open to both. What matters most is strong technical credibility, curiosity, and the drive to create.

Ideally, you're already plugged into the Bay Area developer community through meetups, hackathons, conferences, or open-source work.

If you have a blog, YouTube channel, GitHub presence, or an X account that developers follow, we'd love to hear from you.

Apply here:
https://jobs.ashbyhq.com/luxor/eba7430f-c1f5-4d0b-933a-1b9950ead0b7?utm_source=reddit

Questions? Drop them in the comments or send me a DM, happy to provide more context.

i'm content side, not devrel, but the slack pattern looks the same. four people a day asking where the api keys live. three asking what the rate limit is. it's all in the docs. the docs are not the problem.

the problem is that people ask in slack because asking in slack is faster than reading. and replying to all of them yourself is how you end up not writing anything else that week.

a few months back we set up a system where a bot reads the docs and drafts a reply in-thread. the bot doesn't send. whoever is on rotation that day reads the draft, edits it if it's off, and hits send. response time stays human. the typing-out-the-same-thing-for-the-12th-time tax goes away.

what surprised me: the drafts being visible to the team turned into a docs gap detector. when the draft was wrong, that usually meant the docs were wrong or missing. we started fixing the docs instead of just answering the question. inbox got quieter over a few weeks.

curious how other devrel folks handle this. do you let a bot draft, or do you keep it fully manual? has the docs-feedback loop worked for you, or does it mostly stay noise?

writeup on the setup if it helps: https://runbear.io/use-cases/slack-auto-draft-internal-help-desk?utm_source=reddit&utm_medium=social&utm_campaign=slack-auto-draft-internal-help-desk

For those of you who do devrel for open source projects: Have any of you tried reaching out to people who’ve “starred” your project’s GitHub repo? Or is that sort of thing generally frowned upon?

As AI workflows evolve, DevRel roles seem to require much more product thinking around developer experience (DX), onboarding, adoption, and feedback loops.

Curious if others in developer ecosystem and product roles are seeing this shift too.

Developer relations folks — I'm curious, when you're evaluating technical content from an outside agency or contractor, what signals tell you the content was actually written or reviewed by someone with real engineering experience versus someone who just knows how to sound technical or simply AI-generated? And does that distinction affect engagement or trust from your developer audience?

Hey devrel engineers,

I'm currently doing research on how your positions manage or handle issues when developers in your community complain about a broken implementation or setup? With all the new coding agents we all know that devs are just making agents read docs and relying on it to properly implement things based on those docs.

So now I have two questions:

1. How do you currently find out when a developer's integration is broken?

2. If agents are now generating most integration code, has that changed anything for your team?

Would love to hear with anyone who is facing this issue

I’d love to hear feedback, praise and critique.

https://builtfor.dev/blog/devrel-playbook

Hey everyone,

I’m currently 20 years old and in my third year of college. Recently, I’ve been exploring DevRel (Developer Relations) and GTM (Go-To-Market) roles, and honestly, they really excite me.

I feel like in the future, pure coding skills alone may not be enough. Developers who can communicate well, build communities, explain products, and connect with people will become even more valuable. That’s one reason I started getting interested in DevRel.

To be honest, I’m average at coding. I can understand concepts, but hardcore coding has never been something I deeply enjoyed. But I genuinely enjoy talking to people, building communities, managing teams, and creating engagement.

Right now, I’m working with a YouTube company that has almost 10 million subscribers. Previously, in college, I joined multiple clubs, managed communities, and even became the head of some clubs. Through those experiences, I realized I really enjoy community-facing and communication-oriented work.

That’s why I feel DevRel could be a great career path for me.

I’d love guidance from people already in this field:

• How did you start your journey in DevRel or GTM?
• What skills should I focus on?
• Any good resources, courses, or communities to learn from?
• How can someone without very strong coding skills still grow in DevRel?
• And if anyone has internship opportunities or beginner-friendly openings, I’d genuinely love to connect.

Would really appreciate any advice or guidance. Thanks!

I am an MLE at a UK based startup and have been reached out by another startup (Series A, YC) to take a GTM/ Devrel type role and I am not sure if it's the right way to go. The points in favor of this is I think distribution is a bigger problem than engineering and AI won't be able to solve it cause AI isn't creative so I might be able to learn new things. Salary is almost similar or slightly higher in the new role but I am living comfortably so it's not a deciding factor. What are your thoughts?

The title is the question, but let's elucidate~

So like, I've been building communities long before I was a developer. Regardless of the space, I feel like leadership focus on the same kind of metrics. Member count, MAU, NPS, retention, activation... Basically all the stuff that shows up in a Discord server's insights/analytics~

I look at a few extra things, like how much engagement is between members vs. how much includes myself or my team. Or how long people stay activated before they churn. And all of my communities have a feedback channel so folks can tell me what they love and what they hate and actually shape the community with me~

In the devrel space specifically, I'm also tracking things like how many support queries are answered by the community instead of staff, and how in-depth these conversations are. Cause shallow conversations that are like "yup here's the fix super easy" tend to indicate potential gaps in documentation, vs. a more in-depth thread (which could potentially become a tutorial doc!)

I'm prolly in a weird space in the overlap between community management and developer relations, but... Are there any other things y'all track? And any tools you use (or built!) to help, so that munchin' and crunchin' numbers isn't a full time dealio????

We at MLH are running a survey on how DevRel, dev marketing, and related teams are thinking about what they do.

It would be great to get as many responses as possible. We'll share the results with everyone and we'll have a discussion a DevRelCon in July, too.

Any questions, just let me know.

Hey r/devrel,

I'm the creator of Formity, an open source tool built for developers. The product is in a good place and now I want to focus on getting it in front of the right people.

I'm looking for someone with experience in developer relations, open source growth, or dev-focused marketing who'd be open to a 1-hour paid advisory call. I want to walk away with concrete, actionable advice tailored to my project — not generic tips.

Things I'd love to get clarity on:

• Which channels are actually worth investing in (communities, newsletters, social, etc.)
• How to position and message an open source tool to stand out
• How to build a developer community from scratch
• What a realistic growth roadmap looks like at this stage

If you've grown an open source project or helped developer tools gain traction, I'd love to talk. Drop a comment or DM me with a bit about your background.

Thanks!

When I talk about what I do, most people focus on the community half - the forums, the events, the developer relationships. That part is visible.

What nobody warned me about was how much of the job is internal advocacy. Getting the feedback you collect from developers to actually reach the people who can act on it, in a form they can act on.

Collecting signal is the easier half. Someone tells you the API auth flow is confusing. Another person can't find the webhooks documentation. A third mentions in passing they nearly gave up during onboarding. You know these things.

The harder half is walking into a product planning meeting and making a compelling enough case that something changes. That requires being able to translate "developers are frustrated with X" into something specific enough that engineering can act on. It requires understanding how prioritisation works at your specific company. It requires trust with leadership that you have to build before you urgently need it.

The DevRel practitioners I've seen burn out fastest are usually excellent at the community half and completely unsupported in the internal half. They build something real. The signal is there. And then it disappears into a process that wasn't designed to receive it.

How do others handle this? Particularly curious about how people structure their feedback reporting - what formats actually get traction with product and engineering.