The Industry Is Hiring DevRel for Yesterday

Symptom 1. The dead tutorial, and the fear of storytelling#

Imagine ordering the most authentic, spiciest dish on the menu, then asking the chef to leave out every spice, just to be safe, so nobody gets alarmed.

That’s how the corporate system treats a distinctive authorial voice. The company wants the market’s attention but is afraid of the unconventional approach that actually earns it. And meanwhile it’s still hiring people to write “technical articles” and record the hour-long live-configuration screencast: a camera on someone’s terminal while they set something up in real time. That format is dead. Nobody finishes an hour of watching another person configure a tool; they open the docs, or they ask a model. And the traditional tutorial died with it: AI agents write code and documentation faster than any senior engineer, and they don’t get tired doing it. The live, bare-handed demonstration is just as dated. In the age of AI-assisted work, watching someone perform a task raw, under a stopwatch, measures a skill nobody uses raw anymore.

To cut through the banner-blindness of exhausted developers, you don’t need instructions. You need high-signal narrative, with real craft in how it’s told. Engineers stop for aesthetics, intrigue, a distinct voice, a bold visual choice, the things a machine still can’t generate. A strong DevRel today isn’t a programmer with a microphone. They’re the bridge between complex engineering and human attention.

Symptom 2. Title arbitrage: support in disguise#

You open a “Senior Developer Advocate” posting. Beautiful copy: evangelism, the voice of the developer. Then the interview reveals the actual job: you’ll be jumping on calls with customers whose setup is broken, showing them where to click.

That role has an honest title: Technical Support Engineer, Solutions Architect, or Customer Success Manager. The difference is fundamental. Support is reactive. It works with people who already bought and hit a wall, and it scales through hours worked. DevRel is proactive. It works with people who don’t yet know you exist, and it scales through narrative and trust. Sometimes the swap is subtler than a ticket queue: they want the charisma, someone warm and articulate enough that customers who already signed don’t drift away. But charm aimed at keeping existing accounts from churning is Customer Success, not Developer Relations. It’s the same inversion: the function built to win people who’ve never heard of you, pointed backward at the people you already have. Put “DevRel” on the label and fill the box with a ticket queue, and the function that was supposed to win you the market stays a gaping hole.

Symptom 3. Cross-ecosystem influence vs. the corporate silo#

Picture a symphony conductor hired by a committee of an accountant, a facilities manager, and a security guard. Everyone asks questions from their own domain. Every question is reasonable on its own terms. None of them have anything to do with music.

That’s what happens when DevRel candidates are screened by managers who think entirely inside their own product’s sales funnel. A marketer measures the world in MQLs. A sales leader looks for lead gen. Each asks the only question they know how to ask.

But the value of a strong DevRel professional is built at the intersection of ecosystems: open-source foundations, enterprise platforms, independent communities that don’t share a Slack or a cap table. The work is translation: turning engineering language into business value, and carrying trust from one community into another. That’s the asset. And it’s exactly the asset a funnel-shaped interview can’t see, because it doesn’t fit the funnel. So the conversation drifts to whether the candidate can optimize a sign-up button on a landing page, and the real capability goes unmeasured.

Symptom 4. Catechism instead of strategy#

A driver who just won the championship sits down across from you, and you pass on him, because he couldn’t sketch a carburetor diagram from memory. He has the results. He just didn’t pass your theory test.

The same scene plays out in DevRel hiring. A candidate with years of accumulated social capital sits down, and the first real question is: “Name five metrics of DevRel success for our CEO.” It’s 2026. Any language model will produce an academically flawless list in three seconds: time-to-first-hello-world, API sign-ups, activation rate, NPS. “Name five metrics” tests exactly one skill: the ability to quote a textbook. A skill that AI has commoditized completely and for free.

To be fair, companies don’t ask this out of malice. They’re tired of “star evangelists” who burn through travel budgets without moving the product a millimeter. But demanding that someone who carries real social capital recite the manual on how to measure it is screening out practitioners in favor of theorists.

Symptom 5. Spec work: the unpaid audition#

At some point comes the request that sounds reasonable and isn’t: “Put together a short video on our product, so we can see your approach.” For a candidate with no public work, a junior or a career-switcher, this is fair; there’s nothing to evaluate, so you ask for a sample. But the same request lands very differently when it’s aimed at someone whose entire craft is already public: a channel reaching tens of thousands of engineers, a body of published work, metrics anyone can open in a browser. Researching a product, scripting, shooting, and editing a single video is fifteen to thirty hours of specialized production. Asking for that unpaid, as a screening step, from someone whose portfolio is one click away, is spec work by another name: the practice design and writing communities named and rejected a decade ago. DevRel simply hasn’t caught up.

And it reveals the same disease as the metrics question: the company can’t read a portfolio, so it falls back on a task it knows how to score. Worse, the filter is inverted. The people who agree to produce free spec work are, by definition, the ones with the least leverage and the least proof, the opposite of who the role needs. The strongest candidates decline, and the process quietly screens out exactly the signal it was meant to find.

The synchronous version is bolder still: “Share your screen and show us how you’d present our product, right now.” Same unpaid work on their product, extracted live and dressed up as a conversation, with “show us how you’d sell it” quietly turning the interview into a request for free marketing.

Symptom 6. Startups: a full orchestra for the price of one violinist#

A thirty-person startup posts a single opening: write the technical articles, edit the video, speak at conferences, run the Discord, support sales with demos. That’s not a role. It’s a full orchestra hired for the price of one violinist.

It’s the headcount of a five-person department, offered to one person. And the startup, whose product no one has heard of yet, runs the interview from a posture of “prove you’re worthy of us.” A healthy business understands the math: at that stage, a strong DevRel who already holds the keys to established ecosystems brings more reputational capital to the company than the company brings to them. That conversation should happen between equals.

Symptom 7. The double bind: hired for reach, rejected for it#

First they tell you the reach is the whole point: “we need someone with a real audience.” Then, in the same process, that reach is turned against you: “But are you technically deep enough? You’re really a content person, aren’t you?” The exact asset they screened for becomes the reason to pass.

Underneath sits an engineering-purity test. To be clear: the technical depth is non-negotiable. A DevRel who can’t follow the architecture, judge whether a technical claim holds up, or feel where engineers are really hurting is finished before they start. The question is how you measure that depth. Screening on “years employed as a software engineer” is a proxy, and a poor one: it passes people who shipped production code a decade ago but can’t explain it, and it rejects people with current, demonstrable command of the technology who arrived by another road. The role is translation from end to end, taking complex systems and making engineers care, and translation demands real fluency on both sides. Someone who can make a distributed-systems concept land for tens of thousands of engineers is doing the other half of that work, not a lesser one. But the filter reads “not an SWE” and stops there.

Symptom 8. The invisible reporting line#

Two “Senior Developer Advocate” postings can describe opposite jobs, and the thing that decides which is a single line the posting never shows you: who you report to.

Report into marketing, and you’ll be measured on MQLs and lead gen you don’t control. Report into sales, and you’re pre-sales with a quota under a friendlier name. Report into product or engineering, and you might actually shape the thing you advocate for, the one line where the role can succeed. The org chart decides the outcome before your first day, and it stays invisible until you’re already inside.

The same blind spot shows up in the room. It’s common to move through an entire interview loop without meeting a single practicing DevRel, judged start to finish by people who have never done the job. That absence is upstream of everything else here: it’s why the metrics catechism and the funnel questions feel reasonable to the people asking them. They’re using the only rulers they have.

The disease beneath the symptoms#

None of this is simple stupidity. It’s fear.

Developer Relations spent 2023 through 2025 being cut first and cut deepest. When budgets tighten, the discipline whose contribution is hardest to tie directly to revenue is the easiest line to remove. Nearly every company hiring DevRel today remembers doing exactly that, or watching a competitor do it.

So they hire from fear. Fear is what turns a reasonable question into a catechism, a portfolio review into unpaid spec work, a senior conversation into “prove you’re worthy of us.” Fear demands guarantees a young discipline can’t yet give, then punishes it for not giving them. The symptoms above aren’t eight separate failures. They’re one anxiety wearing different masks: we had to cut this once, and we’re terrified of being wrong again.

And fear only ever looks in one direction: backward, at what it might lose. It’s the same reflex that turns a DevRel hire into a retention job: guard the customers you have instead of reaching the ones you don’t. A discipline whose entire purpose is forward motion, staffed by people told to stand still and protect the perimeter.

The irony is that hiring from fear guarantees the outcome it’s trying to avoid. Screen for safe answers and compliant hires, and you get advocates who produce safe, ignorable work, the exact thing that got the function cut in the first place.

What a sane hiring process looks like#

To hire the people who actually move product growth, rebuild the process:

• A distribution audit instead of memorized metrics. “Show us your work from the last year. How do you build a high-signal story? What worked, what didn’t, and why?” You can’t Google your way through that.
• A real launch, walked through live. “Take us through a launch you ran: how you built the communication, what worked, what didn’t, what you’d change.” That tests strategic thinking, on real decisions with real numbers, without asking for free work on their product.
• Community references. Standing among architects, maintainers, and ecosystem leaders is the one signal in this profession that can’t be forged.

In an era where any block of code, any paragraph, any list of metrics can be generated in seconds, human trust and attention have become the scarcest resources on the market. Neither can be measured by a question from an HR playbook. The companies that learn to recognize genuine social capital and real storytelling, the kind that lives outside the corporate script, will take the strategic advantage. The rest will keep hiring obedient straight-A students, and keep wondering why nobody notices their brilliant engineering.