Alright, we are diving into a really interesting one today. Daniel sent over a prompt about the evolution of Developer Relations—or DevRel, as the cool kids and the people with very busy LinkedIn notifications call it. It is this fascinating bridge between the ivory towers of corporate infrastructure and the people actually in the trenches writing code.
It really is a unique function, Corn. And just as a quick heads-up for everyone listening, today's episode of My Weird Prompts is actually being powered by Google Gemini 1.5 Flash, which is handling the script generation for us. I am Herman Poppleberry, by the way, and I have been looking forward to this topic because DevRel is one of those roles that people often misunderstand. They think it is just professional hanging out at conferences, but in reality, it is a high-stakes technical feedback loop.
Professional hanging out sounds like a dream job for a sloth, Herman. Sign me up for the free t-shirts and the stickers. But seriously, Daniel hit on something important. We have seen this massive shift where companies—especially the big infrastructure and AI providers—are falling over themselves to court developers. It is not just about having a good product anymore; it is about how you treat the community.
Well, not exactly in the sense of agreeing blindly, but you hit on the core "why." If you look at the landscape in twenty twenty-six, the friction for switching providers is lower than ever because of AI-assisted migration tools. Think about it: if you’re unhappy with your cloud provider, you can literally ask an LLM to rewrite your Terraform scripts and migration logic for a competitor in minutes. So, the "moat" for a company isn't just their proprietary API; it's the developer's trust and the ecosystem around it. If the developer feels supported, they stay. If they feel like a number in a database, they’re gone.
So let’s break down the "what" before we get to the "why." For someone who sees a DevRel job posting and thinks, "Is this marketing? Is it engineering? Is it therapy for frustrated Python devs?"—how do you actually define the role?
It is usually described through three pillars: Education, Advocacy, and Feedback. Education is the stuff you see on the surface—the tutorials, the documentation, the "how-to" videos that save your life at two in the morning when a deployment fails. Advocacy is about being the voice of the company to the developers, but also—and this is the part people miss—being the voice of the developers back to the product team.
That second part sounds like the dangerous one. You’re basically the person who has to go to the engineers who spent six months building a feature and tell them, "Hey, nobody likes this, and the syntax is actually making people cry on Reddit."
That is exactly what a high-performing DevRel person does. They are the internal heat shield. If the community is struggling with a specific endpoint or a rate limit, the DevRel team shouldn't just be "managing" that sentiment; they should be documenting the friction and bringing a data-backed case to the product managers to change the underlying tech. They have to tell the truth, even when it’s uncomfortable. If a product is buggy, a good Developer Advocate won't sugarcoat it; they'll help you find a workaround while simultaneously kicking the internal team to fix the root cause.
It’s a hybrid role. You have to be technical enough to understand why the latency is spiking in a specific edge case, but social enough to explain it without sounding like a robot. Or a very grumpy donkey.
Hey now! Donkeys have feelings too. But you’re right. The technical depth is non-negotiable. There was a trend a few years ago where companies hired "community managers" who weren't technical, and it almost always failed in the developer space. Developers have an incredibly high "nonsense detector." If you can't open a Pull Request to fix a typo in the documentation or explain the difference between a REST API and a Webhook, you lose credibility instantly.
But wait, if they are spending all their time on GitHub or in Discords, when do they actually write code? Is a DevRel person still a "real" engineer in the eyes of the engineering org?
That is the eternal struggle, Corn. It’s often called the "DevRel Identity Crisis." In some companies, they sit under Marketing, which can lead to them being viewed as "Engineers who can't code anymore." In better-structured orgs, they sit under Engineering or Product. To keep their "real engineer" status, many DevRel folks spend twenty to thirty percent of their time building actual demo apps or contributing to the core codebase. They have to use the tools they advocate for, otherwise, they become disconnected from the pain points.
Daniel mentioned those "startup perks" and "free stuff for developers" websites. That felt like the "Gold Rush" era of DevRel. Back in twenty twenty-one or twenty twenty-two, it felt like every SaaS company was giving away three thousand dollars in credits and a lifetime supply of stickers just for signing up. Is that still the vibe in twenty twenty-six?
Not quite. We’ve moved from the "Perks Era" to what I’d call the "Efficiency Era." The hype has cooled, and the venture capital money isn't just flowing into "community building" for the sake of it. Nowadays, companies like Accenture AI or the big cloud providers are looking for Developer Experience—or DX—metrics. They want to know the "Time to Hello World."
"Time to Hello World." I love that. It’s like the zero-to-sixty for software.
It really is. If I’m a developer and I sign up for your new AI orchestration platform, how many minutes—or seconds—does it take before I have a working script? DevRel teams in twenty twenty-six are obsessing over that metric. They are instrumenting the onboarding flow like a laboratory experiment. If there’s a drop-off at the "API Key Generation" step, that’s a DevRel failure that needs a technical fix. They’ll look at things like "Friction Logs"—literally a diary of every annoying thing a dev encounters when trying to use the product for the first time.
It seems like this has become even more critical with the rise of open source as a business model. Daniel mentioned the "commercial open source" path. If your core product is free and open, your only real value-add is the community and the ease of the paid "pro" version.
That’s the Vercel or Netlify model. They didn't just build hosting platforms; they built—and heavily supported—frameworks like Next.js. Their DevRel wasn't just telling people to use Vercel; it was teaching people how to build better web apps in general. They provided the education for free. Then, when it came time to host those apps at scale, Vercel was the natural, frictionless choice. It’s "bottom-up" adoption. You win the hearts and minds of the individual contributors, and eventually, the CTO has no choice but to sign the enterprise contract because all their engineers are already using the tool and love the workflow.
It’s like a Trojan Horse, but with better documentation and fewer Greeks.
Precisely. And in twenty twenty-six, we’re seeing this evolve with AI. Think about how many developers are using LLMs to write their code now. If your documentation isn't "LLM-friendly"—meaning it's structured in a way that an AI can ingest it and provide accurate snippets—you’re basically invisible to a huge segment of the market. If a dev asks an AI to "write a script using Provider X" and the AI says "I don't have enough data on Provider X," that provider is effectively dead to that dev.
Oh, that’s a fascinating angle. So the DevRel job now includes "AI Relations"? Making sure the bots like your code as much as the humans do?
In a way, yes. We’re seeing DevRel teams focus on "RAG-ready" docs—Retrieval-Augmented Generation. They are making sure their technical content is formatted so that when a developer asks a coding assistant "How do I implement a vector search using this specific provider," the AI gives a perfect answer. They are literally optimizing documentation for machine readability. If the AI hallucinations because your docs are a mess, that’s the new version of a "broken link." It’s a huge shift in how we think about technical communication.
It’s funny how the more things change, the more they stay the same. We went from "write good docs for people" to "write good docs for the bots that help the people." But the core is still clarity.
And trust. Daniel brought up the "Death of SaaS" narrative, which is a bit hyperbolic, but it points to a real trend: people are tired of being locked into expensive, opaque subscriptions. They want to see the code, or at least understand the architecture. This has re-energized the need for DevRel because if you're asking a developer to trust you with their infrastructure in an era of massive layoffs and company volatility, you need a human face. You need someone who will answer a GitHub Issue at ten p.m. or jump on a quick call to debug a production outage.
Let’s talk about the people who excel in this. Because it sounds like a nightmare for an introvert who just wants to code, but also a nightmare for a pure "marketing person" who doesn't know what a pointer is. Who is the "perfect" DevRel person?
They are usually "T-shaped" individuals. They have deep expertise in at least one technical area—maybe they’re a wizard at React, or they know the guts of PostgreSQL—but they have a very broad "top bar" of the T. They can write a blog post that doesn't sound like a white paper, they can speak on a stage without fainting, and they genuinely enjoy helping people solve puzzles. It’s a rare personality type. You have to be okay with being the "dumbest person in the room" sometimes so you can ask the questions the community is too afraid to ask.
I’ve noticed that a lot of them are basically "technical influencers" now. They have their own YouTube channels, their own newsletters. It’s almost like the company is hiring a pre-built community when they hire these people. Does that create a conflict of interest?
It can. That is a major trend. Companies aren't just looking for someone to manage their Twitter account; they’re looking for someone who already has the respect of the developer community. But there’s a trap there. If a DevRel person becomes more of a "personality" than a technical resource, they lose that "nonsense detector" protection we talked about. If they start posting "Top 10 AI Tools" every day without actually building anything, the community smells the grift. The best ones are still "Engineers" first. Their title is often "Developer Advocate Engineer" for a reason.
But what about the burnout factor? If you are an influencer, a coder, and a support agent all at once, how do you not just explode?
Many do. The average tenure for a DevRel role used to be quite short—around eighteen months. You’re traveling to conferences, you’re on different time zones, and you’re constantly the target of frustrated users. In twenty twenty-six, companies are getting better at this by building "DevRel Squads" rather than relying on one "Rockstar" advocate. They’re specializing roles: some focus on content, some on community management, and some on deep technical advocacy.
What happens when the "hype dies down" like Daniel mentioned? We saw a lot of DevRel layoffs in twenty twenty-four and twenty twenty-five. If the role is so critical, why were they the first to go when the budgets got tight?
It’s the "Attribution Problem." It is very hard to prove that a specific blog post or a conference talk directly led to a hundred-thousand-dollar enterprise deal. Sales is easy to measure: you closed the deal, here is the commission. DevRel is "top of the funnel" and "middle of the funnel." It’s about sentiment, adoption, and reducing churn. When the "Efficiency Era" hit, CFOs started asking, "Why are we spending fifty thousand dollars to send four people to a conference in Berlin when we can't track the ROI?"
"Because we get cool stickers, Greg! Leave us alone!"
But the companies that survived that cull are the ones where DevRel moved closer to the product. Instead of just "evangelism," they focused on "enablement." They started measuring things like "Active Developer Nodes" or "Library Downloads" and correlating them with long-term revenue. They became more data-driven. They stopped being the "party department" and started being the "product intelligence department."
It seems like there's also a shift in where the community actually lives. It used to be Stack Overflow and IRC. Then it was Slack and Discord. Now, with the "Death of the Public Web" and everyone moving to private repositories—which we’ve talked about before—where does a DevRel person even find their community?
It’s moving into smaller, high-signal enclaves. Private Discords, specialized Telegram groups, and ironically, back to "In-Real-Life" meetups. Because AI can generate a thousand "technical blog posts" in a second, the value of a human-curated space has skyrocketed. A DevRel person in twenty twenty-six is more of a curator than a broadcaster. They’re the ones saying, "I’ve tested these five AI agents for deployment, and here is the one that actually works." They provide the "proof of work" that an AI can't fake yet.
That makes sense. In a world of infinite noise, the person you trust to filter the noise is the most valuable person in the room. It’s almost like they’ve become technical librarians.
And that brings us back to Daniel’s point about "segmenting" the community. A lot of companies don't know who their community is. Is it the student learning to code? The senior architect at a Fortune 500? The AI agent itself? A good DevRel strategy identifies those segments and gives them what they need. The student needs "free stuff" and "easy wins." The architect needs "security audits," "SLA guarantees," and "high-availability benchmarks."
And the AI agent just needs a clean JSON schema and a well-defined REST endpoint.
Precisely! If you try to treat them all the same, you end up with that "foggy" vision Daniel mentioned. You end up with a "Community Manager" who is basically just a glorified social media intern, and the developers just ignore you. You have to speak the specific language of each segment. If you talk to a Senior DevOps Engineer the same way you talk to a Bootcamp student, you’re going to get laughed out of the server room.
So if you’re a developer listening to this and you’re thinking about making the jump into DevRel—maybe you’re a bit burnt out on pure feature-factory work and you like the "human" side of tech—what’s the reality? Is it all it’s cracked up to be?
It is rewarding but exhausting. You are constantly "on." You have to switch contexts between deep debugging and high-level strategy ten times a day. And you have to be okay with the fact that your work is often "invisible" until something goes wrong. If the docs are perfect, nobody says anything. If there’s one typo in a code snippet, you’ll hear about it from fifty people on Threads. It requires a thick skin and a genuine servant-leader mentality.
Sounds like being a parent, but with more YAML files and fewer diapers. Though, depending on the state of the codebase, maybe the diapers are still relevant.
Not far off! But for the right person—someone who loves the "Aha!" moment when a developer finally understands a complex concept—it’s the best job in the industry. You get to sit at the intersection of where the future is being built and where it’s being used. You’re the first person to see how people break your product in creative ways you never intended.
We’ve talked a lot about the technical side, but I want to go back to the "perks" thing. Daniel mentioned these "crassly named" websites. There was one called "Startup Perks" or something similar. Is that era of "bribery for adoption" officially dead?
It’s not dead, it’s just evolved into "Strategic Grants." Instead of just giving everyone fifty bucks, companies are looking for "High-Impact Builders." They’ll give you twenty thousand dollars in GPU credits, but only if you’re building something that showcases their specific infrastructure. It’s more of a partnership than a giveaway. They want to see "Proof of Concept" (POC) projects that they can then use as case studies.
It’s more targeted. "We’ll give you the tools, but you have to build something cool that we can then use in our marketing."
It’s a symbiotic relationship. And in twenty twenty-six, with the cost of compute being what it is—especially for specialized AI chips—those credits are more valuable than gold. For a small team, a DevRel person who can get them into a "Priority Access" program for the latest H-two-hundred clusters is a godsend. It’s less about stickers and more about access to scarce resources.
It really highlights how the "seller" has changed. It used to be that you sold to the "Business Decision Maker"—the guy in the suit. Now, you’re selling to the "User who happens to have a corporate credit card and a Terminal window open."
That’s the "Developer as the New Kingmaker" thesis. It’s been around for over a decade, but it’s never been truer than now. If the developers hate your tool, the suit isn't going to buy it, because they know their team will just "shadow-IT" their way into using the tool they actually like. We’ve seen entire enterprise software giants crumble because they ignored the developer experience and focused only on the C-suite.
"Shadow-IT" is such a great term. It sounds like a spy thriller where the weapon of choice is an unauthorized Docker container or a rogue Python script running on a laptop under someone's desk.
It basically is! And DevRel is the department tasked with making sure that "Shadow-IT" eventually becomes "Official-IT." They make the transition from a "side project" to a "production-ready deployment" as smooth as possible. They provide the security white papers and the compliance docs that the "suits" need, while keeping the "cool" factor for the devs.
So, looking forward—Daniel asked about trends. We’ve touched on AI and the "Efficiency Era." Where do we go from here? If we’re sitting here in twenty twenty-eight, what is Herman Poppleberry predicting for the state of DevRel?
I think we’ll see the rise of "Agentic DevRel." As more of our "coding" is done by agents—autonomous units that can plan, write, and deploy code—DevRel will have to figure out how to influence the decisions of those agents. If an agent is tasked with "Build me a scalable chat app," it’s going to evaluate providers based on latency, cost, and documentation quality. DevRel will be the ones optimizing for those "Agent Benchmarks." They might even be "training" specialized models on their company's own best practices to ensure the agents use their tools correctly.
That is wild. We’re going to have "Advocates" for "Agents." I can see it now: "Hey, GPT-seven, have you considered using our serverless database for your next autonomous project? We have a ninety-nine percent uptime and very low token overhead."
It sounds like sci-fi, but it’s the logical conclusion of where we are. But beneath all that, I think there will be a massive "Return to Human" movement. As the web gets flooded with AI-generated sludge, the developers who can actually teach and connect and build trust will be more valuable than ever. The "Human-in-the-loop" isn't just for AI training; it’s for community building. When everything else is automated, a real person who can say "I've been there, I had that same bug, and here is how I fixed it" becomes the ultimate premium service.
I like that. It’s a bit of a hopeful note. No matter how much automation we throw at it, you still want a person to talk to when the world—or your production environment—is on fire. There’s a certain comfort in knowing a human is watching the logs too.
And that is what a great DevRel person provides: a sense that there is someone on the other side of the API who actually cares if your project succeeds. They are the empathy layer of the software industry.
Alright, I think we’ve covered the "Three Pillars," the "T-shaped" people, the "AI-ready" docs, and the "Death of the Perk." What are our big takeaways for the folks listening?
If you’re a company: stop hiring "Community Managers" if what you actually need is a "Developer Advocate." You need someone who can code. If they can’t fix a bug in your SDK, they shouldn't be your lead DevRel. And focus on "Time to Hello World"—that is your most important marketing metric. If you make it hard for a dev to start, they won't even finish the tutorial.
And if you’re a developer: DevRel is a legitimate and often very lucrative career path if you have that rare mix of technical depth and communication skills. But don't do it just for the travel and the stickers. Do it because you love being the bridge and helping other people build cool stuff. It’s a service role at its heart.
And finally, for everyone: watch the "AI Attribution" space. How we measure the impact of technical content is changing fast. If you’re not thinking about how AI agents consume your technical brand, you’re going to be left behind by the companies that are already optimizing their documentation for the next generation of LLMs.
Well said, Herman. This was a deep dive I didn't know I needed. It turns out "Developer Relations" is a lot more than just being the person who hands out the high-quality hoodies at the booth, though I still really want one of those hoodies.
It’s the engine of the modern infrastructure economy, Corn. Without them, we’d all just be shouting at broken APIs in the dark, wondering why our JSON isn't parsing.
And nobody wants that. Especially not in twenty twenty-six.
Definitely not.
Alright, that’s our look at the evolving world of DevRel. Big thanks to Daniel for the prompt—it really opened up a lot of threads we haven't pulled on in a while. I think we managed to touch on everything from technical depth to the psychological toll of the role.
It really did. And a quick thank you as always to our producer, Hilbert Flumingtop, for keeping the gears turning behind the scenes and making sure our audio doesn't sound like it was recorded inside a tin can.
And of course, a huge thank you to Modal for providing the GPU credits that power this show and our various AI experiments. Without them, we’d be doing this on a couple of calculators and a dream.
This has been My Weird Prompts. If you are finding these deep dives helpful, we would love it if you could leave us a review on whatever podcast app you are using. It actually helps a lot with the "algorithm relations" side of things. We need the bots to like us as much as the humans do!
See what you did there. Very clever, Herman. You're practicing what you preach.
I try!
You can find us at myweirdprompts dot com for all the show notes and the full archive of over seventeen hundred episodes. We've got a lot of history there if you want to see how our predictions have aged over the years.
We’ll see you in the next one.
Stay curious, everyone. Goodbye.
Goodbye.
