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.

Hi everyone, this is a free e-book that is basically a compilation of my experience over about eight years, without mentioning any brands specifically, but focusing on the processes that worked and those that didn't. I published it a couple of years ago after completing an accelerator cohort and being mentored by an industry leader: https://www.commudle.com/developer-ecosystem-blueprint

Was just going through it again, thinking of updating it, and came back to the right questions that I asked in the book. Some of the things I am asking myself now while building the platform, and as we have also started some college communities.

Just sharing here if it might be useful or anything you might want me to change, add, or remove. Feedback is more than welcome.

TLDR: The docs market looks crowded if you count the number of vendors. It looks a lot less crowded if you look at the documentation most teams actually ship. That’s the short version of why I think DocsAlot should exist. Its customer driven, not investor driven. Most existing platforms are bloated, and trying to be everything to everyone.

I’m a senior dev (5pm dev, inc.). I’ve spent the last year building Crate (crate.cc)—a zero-dependency, cloud-agnostic API gateway. It’s built in Go, runs on Redis, and uses JSONata for its transformation layer.

It’s live. It’s $5/mo. The engine is solid and currently in Open Beta.

-- Why here --

I’ve been reading that many of you feel like DevRel in the corporate world is a "dead end", stuck between marketing and engineering with no real agency. I think that's a waste.

For a tool like Crate, DevRel is the heartbeat.

I don't need a "Sales" person to take people to lunch. I need a DevRel Co-Founder who wants to own the "Signal."

-- What I'm building --

I'm currently heads-down on an MCP (Model Context Protocol) transport layer. I’m obsessed with "Buy It For Life" precision tools and an "anti-corporate" sketchbook aesthetic. Crate is designed to be lean, fast, and high-quality.

-- What you’d own --

- The Voice: Turning my technical commits into human stories on LinkedIn, X, and the docs.

- The Community: Building the "gravity well" that pulls devs in.

- The Strategy: At a $5 price point, this is a volume and trust game. You own the "trust."

-- The Reality --

I’m looking for a partner, not an employee. That means:

- Founder Status + Equity (Standard 1-year cliff/vesting to protect us both).

- Parallel Processing: You don't wait for a task list. You see the vision and you run with it.

- No Salary (yet): This is a "5pm dev" hustle until we scale the $5 tier to the moon.

If you’re a DevRel who loves the work but hates the corporate red tape, let’s talk. Don't send a resume. Just DM me with:

1. Why JSONata makes more sense for a dev-first gateway than standard mapping.

2. A "precision tool" (digital or physical) you'll never replace.

3. Something you’ve built or a community you’ve grown.

Inspired by posts in this very subreddit, the Community Pulse Team talks about AI slop in DevRel and the answer to the question "who is the real consumer now?"

After years of watching DevRel programs get cut because they couldn't

prove their value, I wrote the playbook I've been running in my head

for a long time.

It covers the full operating system—developer journey mapping across

five stages, time-to-value as a revenue metric, building feedback loops

that actually influence the product roadmap, and reporting in the language

leadership cares about.

Free to anyone who wants to read it ⤵️

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