Developer Relations (DevRel) in 2026: Skills, Salary, and Career Path Explained

Most people who say they want a “DevRel career” are trying to enter three different professions at once.

That is the first hard truth. One company’s DevRel opening is a public-facing developer advocate who lives on stage, in webinars, on YouTube, and in community channels. Another company’s DevRel role is basically a product-facing engineer who writes sample apps, fixes quickstarts, and escalates API friction back to product. A third company’s “Head of DevRel” job is not a creator role at all. It is a budget, headcount, metrics, and executive-alignment role whose output is whether the entire function survives the next planning cycle. If you apply to those roles as though they are interchangeable, you can waste six months, miss offers you were actually qualified for, and convince yourself the market is broken when the real problem is title confusion.

That confusion matters even more now because the post-layoff version of DevRel is less forgiving than the conference-heavy version many people still imagine. The 2024 State of Developer Relations report found that 14.6% of respondents had been laid off during the year, 18.1% of programs lost members due to layoffs, and 22.1% experienced reorganizations. At the same time, the same report and the DevRel Agency’s write-up of it showed a function moving closer to measurable business outcomes: 36% of respondents said product usage was their top active-community metric, 44% said active users were a primary success measure, and 18% explicitly linked revenue influence to DevRel metrics.

So if you are evaluating whether a developer relations career still makes sense in 2026, the right question is not “Is DevRel dead?” The right question is: which DevRel job are you actually pursuing, and can you prove the kind of value that job is hired to create? That is the lens I use when I hire, coach, and calibrate DevRel talent. It is also the lens that makes the current market much more legible. And if you are coming from engineering, it helps to anchor that decision against a broader software engineering roadmap for engineers considering a DevRel pivot, because the strongest DevRel candidates still have a technical home base they can return to.

Why two DevRel job postings can describe completely different jobs

The title problem is real. Bear Douglas put the issue plainly in a WorkOS conversation: DevRel can mean different things depending on the company’s product, how developers affect revenue, and where the function sits organizationally. In practice, teams housed under marketing get pushed toward awareness, events, and top-of-funnel metrics; teams housed under product or engineering are more likely to own documentation quality, beta feedback, retention through the developer funnel, developer sentiment, and drop-off points in onboarding.

Hiring managers are often solving different business problems, not filling the same role. Amplify Partners’ hiring guide makes this especially clear for startup teams: founders usually want either top-of-funnel growth or better success for an existing developer audience, and those are “completely different goals.” The same guide warns that content-focused and community-focused advocates are not interchangeable, which is exactly why so many DevRel hiring loops feel incoherent to candidates. One interviewer wants polished public speaking and content output. Another wants someone who can build demos and debug integrations. A third wants somebody who can stand up a program, report ROI, and negotiate budget.

Job descriptions already show the split if you read them closely. Google’s Developer Relations Engineer listings describe a role that is “part community manager and part developer advocate,” but the day-to-day is deeply technical: writing sample code and client libraries, handling support queues, troubleshooting code problems, reviewing API designs, and advocating internally for developers’ needs with product and engineering. Canonical’s Developer Relations Engineer posting says the role combines practical engineering skills with cross-functional diplomacy and includes product meetings, community conversations, and solving specific technical problems users identify. That is much closer to developer experience engineering than to classic brand evangelism.

On the advocate side, the center of gravity shifts outward. Backblaze’s Developer Advocate job emphasizes tutorials, sample applications, reference architectures, short-form video, docs improvements, conference presence, and relationships in developer communities. JetBrains’ Developer Advocate posting is even more explicit about the public side of the role: community conversations, answering technical questions, speaking at conferences, hosting meetups, and building relationships with open-source projects. Those are excellent jobs, but they are not the same job as a DevRel engineer who is judged on friction reduction inside docs, SDKs, and onboarding flows.

Leadership roles are different again. Moesif’s 2026 guide defines the Head of DevRel as owning strategy, headcount, budget, and reporting. That is a useful correction for anyone who thinks the top of the ladder is just “more speaking, but senior.” OpenFX’s Developer Experience Lead role goes further and makes the business accountability explicit: own API adoption as a measurable outcome, instrument the funnel from API-key activation to first API call to first transaction, set baselines and targets, and move the metric. That is not a vibes job. That is an operating role.

My rule of thumb is simple: when I see a DevRel posting, I do not ask “Can I do DevRel?” I ask which business problem is this company paying DevRel to solve? If the answer is “earn trust and attention,” you are likely looking at the Advocate vertex. If the answer is “reduce developer friction and improve adoption,” you are likely looking at the DevRel Engineer vertex. If the answer is “justify and scale the function itself,” you are looking at the Program Lead vertex. Once you see that clearly, most “confusing” job descriptions stop being confusing.

The DevRel Trifecta: Advocate, DevRel Engineer, and Program Lead

I use one framework to explain this title mess to candidates and hiring teams: the DevRel Trifecta.

The DevRel Trifecta is the idea that “DevRel” is not one job title with minor variations. It is a three-vertex model of three materially different jobs that often sit under one budget line. If you can identify the vertex, you can decode the posting, tailor your portfolio, negotiate compensation more intelligently, and avoid trying to become a generic all-purpose “DevRel person,” which is usually how people get stretched thin and cut first. The framework is a synthesis of how current roles are actually written and measured across Google, AWS, Canonical, Backblaze, JetBrains, and DevRel leadership guides.

Table notes. Google’s current Developer Relations Engineer postings emphasize sample code, client libraries, support queues, API review, and internal advocacy. Backblaze and JetBrains emphasize tutorials, demos, docs, events, and active community engagement. Moesif’s Head of DevRel definition centers strategy, headcount, budget, and reporting, while OpenFX’s DevEx Lead makes explicit ownership of the adoption funnel and the metric moved. That is the Trifecta in the wild.

Vertex One: The Advocate. A normal week for a strong Advocate is externally weighted. You might spend Monday turning a product update into a technical tutorial, Tuesday recording a walkthrough or livestream, Wednesday answering community questions and collecting pain points, Thursday speaking at a meetup or webinar, and Friday packaging what you heard into actionable product feedback. JetBrains’ and Backblaze’s current postings are clean examples: answer questions, help developers get started, speak publicly, host meetups, build demos, improve quickstarts, and stay close to developer communities.

What you need to get hired as an Advocate. You need proof that you can teach technical material in public without sounding like marketing collateral. AWS’s senior Developer Advocate role requires strong programming skills, technical content creation, and public speaking. GitLab’s Developer Advocate handbook also highlights a surprisingly modern requirement: analytical, data-driven community work, plus the ability to run a marketing pipeline and use automation. That is why the 2026 Advocate role is materially different from the old stereotype of the charismatic conference speaker who could charm a room but could not connect the work to a funnel, a community-health metric, or a product outcome.

The realistic on-ramp to the Advocate vertex. The cleanest pivots come from engineers who already write, educators who can code enough to be credible, and growth/content people who have real technical taste. If you are in the last group, the overlap is real, but not total. The fastest way to close the gap is to combine audience-growth instincts with shipped technical artifacts, which is why it helps to understand how growth-marketing skills translate into developer-facing content work without confusing growth marketing with DevRel. An Advocate who cannot build or demo anything is fragile. An Advocate who can teach, publish, and produce credible code examples is much harder to replace.

Vertex Two: The DevRel Engineer. This is the most technically durable part of the Trifecta. A normal week is less glamorous and more leveraged: reproduce a developer issue, tighten a quickstart, update a reference app, push an SDK fix, annotate where onboarding breaks, file a product escalation, and measure whether the improved path gets more developers to first value. Google’s DRE roles and Canonical’s DRE posting both map closely to that reality. AWS’s Developer Experience Engineer role is even more direct: build with agents across AWS services, find the friction, turn what you learn into content and guidance, and partner with service teams to advocate for product changes.

What you need to get hired as a DevRel Engineer. You need engineering credibility first, communication second, and developer empathy all the way through. Google’s current DRE roles ask for multi-year experience in technical roles, programming ability, and influence without authority. OpenFX wants evidence that you owned a developer-facing platform or API, built an integration funnel, and moved a measurable adoption outcome. That is why the most useful preparation is not abstract “learn communication.” It is building things developers actually use. The overlap is strongest with the API development skills that also make a strong DevRel engineer, and with why API documentation quality has become its own hiring signal. If you can ship quickstarts, sample apps, docs-as-code, and clean API ergonomics, you are already walking toward this vertex.

The realistic on-ramp to the DevRel Engineer vertex. The best path is usually from software engineering, solutions engineering, technical support engineering, or technical account management. I tell engineers not to start with “becoming a public speaker.” Start by shipping three things: a getting-started guide that removes friction, a working sample integration, and a short write-up explaining what was broken and how you fixed it. Those are DevRel engineer artifacts. At AI and LLM tooling companies, this now increasingly extends to building examples with SDKs, agents, evals, and developer workflows, which is why it can help to understand how prompt engineering fits into AI-focused developer tooling roles. AWS’s Kiro and DevEx roles are already framing the work in terms of agent-driven development, time to first value, self-serve activation, and friction logs.

Vertex Three: The Program Lead. This is the least admired vertex early in your career and the one that determines whether the other two exist. A normal week is not mostly content or code. It is headcount planning, quarterly reviews, budget arguments, KPI dashboard reviews, conference spend decisions, hiring loops, executive translation, and sometimes protecting the team from being turned into developer marketing, solutions engineering, or customer support by accident. Moesif defines the role as strategy, headcount, budget, and reporting. Amazon’s Head of Developer Enablement for Kiro reads like the modern version of the same job: own end-to-end developer experience, reduce time to value, measure activation and retention, run the KPI dashboard, and turn friction into product improvements.

What you need to get hired as a Program Lead. You need two forms of credibility. The first is practitioner credibility: you have actually done the work you are now prioritizing and reviewing. The second is executive credibility: you can connect developer experience to activation, retention, expansion, support cost, or some other business lever the CFO and the VP of Product already understand. This is where many excellent advocates stall. They can inspire a room but cannot yet defend a budget. The Kiro role’s wording is blunt for a reason: demonstrably improved developer outcomes at scale matters more than public presence.

The realistic on-ramp to the Program Lead vertex. Most people arrive here from senior Advocate or senior DevRel Engineer roles, with occasional pivots from product marketing, platform product management, or community leadership. The key transition is moving from “I shipped great work” to “I designed a system the team can repeat and I can defend.” If you cannot explain your team’s mechanism of value creation, Chris Reddington’s 2026 synthesis of 13 DevRel leadership interviews is a useful warning: public-facing DevRel work is visible, but the hard-to-see contribution to adoption, developer experience, and product feedback loops is where the real value often sits. Program Leads are the people who make that invisible value legible.

What DevRel actually looks like after the layoffs

If you want the sanitized version, plenty of people will tell you DevRel is “evolving.” The less polite version is that a lot of teams were forced to answer a question they had been postponing for years: what business result are we here to move?

The wider tech backdrop was brutal. Crunchbase News tallied at least 95,667 U.S.-based tech layoffs in 2024 and about 127,000 in 2025. Reuters reported in early 2024 that the “Year of Efficiency” logic had not ended and that companies were still making targeted cuts while shifting spend toward generative AI. That matters because budget pressure changes how “nice-to-have” functions are judged, and DevRel is frequently placed under exactly that microscope when a company’s measurement story is fuzzy.

The developer-tools and platform world felt this directly. Twilio announced a 17% cut in February 2023 and then another 5%, or about 295 employees, by the first quarter of 2024 in the name of profitable growth. Stripe, after returning to profitability in 2024, still laid off about 300 employees in January 2025, mostly in product, engineering, and operations. The point is not that DevRel alone was singled out. The point is that developer-first companies were not insulated from efficiency pressure, and every adjacent function had to justify itself with more rigor.

The 2024 State of Developer Relations report gives the most useful function-level reality check. It did not show DevRel disappearing. It showed DevRel being thinned, reorganized, and forced into sharper alignment with business goals. More programs hired than lost members, but layoffs and reorganizations were still significant. And the metrics mix shifted in ways I would expect from a function learning to survive: product usage, active users, and even revenue influence mattered more than vanity reach alone.

What got cut first. In my experience, the easiest DevRel work to cut is the work everyone can see but nobody can tie to a durable outcome. Travel-heavy conference calendars with thin follow-through. Content production that measures views but not developer activation. Community programs with lots of energy but no clarity on whether they reduce churn, improve adoption, uncover product issues, or create advocates who materially influence pipeline. WorkOS’s Bear Douglas described the organizational version of this clearly: if you do not know where developers affect your bottom line, there comes a point when you are “in trouble.” That is the sentence a lot of teams ran into.

What survived. The roles that survived tended to have a shorter distance between effort and result. Developer experience roles that improved docs, SDK ergonomics, and onboarding drop-off. Enablement roles that reduced time to value and kept developers out of support. Technical education roles that were explicitly tied to activation and retention. Amazon’s Kiro role reads like a post-layoff survival manual for DevRel: improve self-serve success rates, instrument activation, quantify friction through support ticket analysis, and own the KPI dashboard. AWS’s DevEx Engineer role says almost the same thing in a lighter-weight form: build with the product, find friction, turn learnings into better technical resources, and advocate for product changes.

Why “reach” alone no longer funds headcount. Reach still matters. Trust still matters. Community still matters. But reach is now expected to sit inside a chain of evidence. Developerrelations.com’s 2025 guide lists documentation engagement, developer activation, community engagement, and content impact as more useful reporting metrics than broad awareness alone. Postman argues that time to first call can be the most important API metric because the first successful API call is the first tangible payoff in a developer’s journey. Moesif’s Time to First Hello World framing makes the same point from another angle: if developers take too long to reach success, more of them abandon the product.

Why the DevRel Engineer vertex became more durable. This is why I keep telling candidates that the most durable DevRel careers now sit closer to product friction than to pure brand halo. When you can show that a rewritten quickstart cut drop-off, that a sample app improved activation, that a support queue pattern turned into a product fix, or that docs changes reduced tickets, you are no longer defending “community.” You are defending a business improvement. Amazon’s Kiro role literally spells that out: reduce time to first value, improve self-serve activation, use support ticket analysis and friction logs, and turn those findings into product improvements.

Why the Advocate vertex still matters. None of this means the Advocate is obsolete. It means the Advocate has to be sharper. The most resilient Advocates now do at least three things well: they create genuinely useful technical education, they produce product feedback with signal rather than anecdotes, and they help the company earn trust in places it cannot buy with ads. That is why current advocate postings from AWS, Backblaze, JetBrains, and GitLab still ask for hands-on technical content, demos, workshops, and public communication rather than generic “community enthusiasm.”

What the broader “lean teams” trend means for DevRel. Vercel became a useful symbol of the new operating mood even outside DevRel proper. Business Insider reported that the company used AI agents to automate much of the work of a 10-person inbound sales team, leaving one human to oversee the system and moving the rest into higher-value outbound roles. That is not a DevRel layoff story. It is a leverage story, and it tells you where executive attention is going: repetitive, documentable work gets automated or compressed; creative, ambiguous, customer- and product-facing work gets protected. DevRel that looks like repeatable paperwork is vulnerable. DevRel that transforms product understanding, developer success, and adoption is harder to replace.

How much DevRel professionals earn in 2026, by vertex and level

Compensation data is where title ambiguity stops being annoying and starts being expensive.

The first thing to understand is that DevRel salary data is messy because the market is messy. Different companies use “Developer Advocate,” “DevRel Engineer,” “Developer Experience Engineer,” “Developer Relations Manager,” and “Head of DevRel” to mean overlapping but not identical work. Salary aggregation sites pick up that mismatch differently. So when two reputable sources disagree, I do not smooth the numbers over. I treat the disagreement as data.

The Advocate numbers prove the standardization problem. As of July 2026, Glassdoor’s U.S. Developer Advocate page shows average pay around $136,294, while ZipRecruiter’s U.S. Developer Advocate page shows $86,320. That is a gap of almost $50,000 for the same title. I would not treat that as “one source is right and one is wrong.” I would treat it as evidence that companies are collapsing very different scopes into the same label and that salary tools are sampling different slices of the market. When a title is this noisy, you should negotiate from responsibilities, scope, and seniority signals, not title prestige.

The DRE market is more coherent. Developer Relations Engineer data is still not perfect, but it is cleaner. Glassdoor’s July 2026 U.S. page puts the role at about $142,969 average with a typical range of $114,759 to $180,191 and a 90th percentile around $220,619. Senior DRE pay climbs to roughly $170,211 average with a 90th percentile above $257,000. That aligns with what I see in the market: the more your DevRel work is tied to technical depth, onboarding quality, and measurable product outcomes, the easier it is for companies to level it against engineering-adjacent compensation bands.

Company-specific numbers matter when you negotiate. Glassdoor’s Google DRE page in July 2026 lands almost exactly on the U.S. all-company DRE average at about $142,969, with a reported typical range of $114,759 to $180,191 and a 90th percentile around $220,619. Meanwhile, current Google DevRel job listings show active employer-provided ranges for some senior roles, including a Senior Developer Relations Engineer, Google Photos listing at $163,000 to $237,000. Those employer-provided ranges are especially useful because they anchor compensation to current hiring practice rather than just self-reported historical submissions.

Leadership pay is wide because leadership scope is wide. Head of Developer Relations averages about $160,064 on Glassdoor, but that is a title where actual market value varies wildly based on whether you own one or two ICs, a global program, a partner ecosystem, a developer education function, or a pipeline-adjacent growth budget. Amazon’s current Kiro Head of Developer Enablement role shows posted base ranges from $164,200 in Seattle/Bellevue to $330,500 in Santa Clara. That is not a DevRel-specific salary page, but it is exactly the kind of neighboring role that tells you where the market is paying for high-leverage developer enablement and activation ownership.

The best salary question is not “what does DevRel pay?” It is “which vertex, what level, and what metric am I expected to move?” If the role is outward-facing and growth-weighted, you should ask how success is tied to pipeline, reach, activation, partner influence, or community sentiment. If it is a DevRel Engineer role, ask what onboarding or adoption metric you own and whether the role is leveled against engineering or marketing. If it is a Program Lead role, ask what budget you own, what dashboards you report, and whether the team is measured on activation, retention, expansion, support deflection, or brand. The more precise the answer, the more negotiable the offer usually is.

One more salary signal worth noticing. Glassdoor’s Developer Advocate page says the top-paying industry for the role in the U.S. is Information Technology, with median total pay of $190,302, and names Meta, Amazon, and Google among top-paying companies. If you are comparing a DevRel job at a developer-tools startup with one at a larger platform company, that matters. Early-stage companies may offer more scope and faster title growth. Larger platform companies often offer cleaner leveling, better comp bands, and more internal mobility. Neither is automatically “better,” but they are different risk/reward profiles.

How to break into DevRel from an adjacent role

The most common mistake I see is people trying to “switch into DevRel” before they decide which vertex they are targeting. That usually produces a weak, generic portfolio: a few blog posts, some social activity, maybe a podcast appearance, and no clear proof of product understanding, teaching ability, or business impact. The better approach is to pick your entry vertex first and then build evidence for that specific job.

If you are coming from software engineering. Aim first at the DevRel Engineer vertex unless you already have an unusually strong public content record. You already have the hardest part: technical credibility. What most engineers are missing is evidence that they can translate complexity into developer success. The fastest proof is not a personal brand campaign. It is a mini portfolio made of one excellent quickstart, one working sample app, and one write-up that explains the frictions you removed and why they mattered. That kind of work maps directly to current DRE postings from Google, Canonical, AWS, and OpenFX. It also pairs naturally with the API development skills that also make a strong DevRel engineer and why API documentation quality has become its own hiring signal.

If you are coming from content, growth, or developer marketing. You are probably best positioned for the Advocate vertex, but only if you can close the technical credibility gap fast. The stronger candidates in this lane can do two things at once: they understand distribution, audience segmentation, and narrative, and they can still build a working demo or at least modify one confidently. That is why I recommend studying how growth-marketing skills translate into developer-facing content work while deliberately shipping technical artifacts: a tutorial with a real repo, a teardown of a docs flow, a video walkthrough of an integration, or a workshop deck with sample code. Backblaze, AWS, and JetBrains all signal that modern advocacy is technical education, not just content promotion.

If you are coming from community management. This is a legitimate path, but it is the one most likely to get underestimated. Community managers often already have the empathy, moderation judgment, event sense, and trust-building instincts that mediocre DevRel candidates lack. What they usually need is deeper product fluency and enough technical literacy to diagnose, route, and prioritize developer pain without breaking trust. The easiest upgrade path is to become the person who not only runs community spaces but also writes the “getting unstuck” guides, creates canonical answers, and turns recurring community issues into structured feedback for product. That starts to move you from community support into Advocate or eventually Program Lead territory.

If you are coming from product marketing or product management. You may have a stronger shot at the Program Lead vertex than you think, especially if you have worked on API or platform products. OpenFX’s DevEx Lead role and Amazon’s Kiro leadership role read like adjacent-product roles with more developer empathy and more public-facing context. What transfers well is funnel thinking, cross-functional drive, prioritization, and comfort with dashboards. What does not transfer automatically is developer trust. If your resume says “strategy” but your public evidence says nothing, I would still want to see a few real artifacts: a tutorial, a docs audit, a product walkthrough, a community Q&A session, or an example integration critique.

What transfers and what does not. Writing transfers. Product judgment transfers. Technical debugging transfers. Community pattern recognition transfers. Executive communication transfers. What does not transfer automatically is credibility with developers. Developers are unusually good at detecting when someone knows the workflow versus when they merely know the pitch. So whatever your background, build a portfolio that demonstrates one of three things clearly: you can teach developers, you can remove developer friction, or you can design a system that proves DevRel value. If your portfolio cannot do one of those three, it is not ready yet.

The portfolio I actually want to see. I would rather interview a candidate with three sharp artifacts than thirty vague ones. Artifact one: a technical tutorial with a working repo and reproducible steps. Artifact two: a sample integration, SDK wrapper, or demo app that makes a product easier to understand. Artifact three: a short memo or post explaining a real piece of developer friction, the metric it affects, and the change you would make. That third artifact is especially powerful because it signals Program Lead potential even at the IC level. It tells me you do not just make things; you connect them to outcomes.

How AI changes the entry path. AI has not eliminated the need for DevRel. It has changed what good looks like. On one hand, AI makes low-effort content much cheaper, which means mediocre technical content is worth less. On the other hand, AI-native developer tools need even more education, examples, workflows, onboarding design, and docs quality because the product surface is often more probabilistic and ambiguous. AWS’s current DevEx and developer-advocate roles are explicitly about agent-driven development, and Google’s active senior DRE postings include generative AI and LLM experience. If you want to break into DevRel through AI tooling, it helps to understand how prompt engineering fits into AI-focused developer tooling roles, but the winning move is still shipping practical artifacts developers can use.

The durability test I use. Before you pivot, ask yourself one question: if a hiring manager cut travel and froze event budgets tomorrow, would your portfolio still make sense? If the answer is no, you are probably over-indexed on the old DevRel model. In 2026, durable DevRel candidates still look useful when budgets tighten because they can improve docs, demos, onboarding, feedback loops, education, or measurement. That is what survives.

FAQ

Is DevRel a good career in 2026? Yes, but only if you understand which DevRel career you are choosing. The broad function did not disappear after the 2024–2025 contraction; it got more selective and more metrics-driven. The 2024 State of Developer Relations report still showed more programs hiring than losing members, but it also showed layoffs, reorganizations, and stronger alignment to product usage, active users, and revenue influence. I would call DevRel a good career for people who can tie their work to developer success and business value, not for people who are chasing a vague “conference evangelist” identity.

Do you need to code to work in DevRel? For many roles, yes. For all roles, at least some technical fluency helps. Google’s DRE roles require technical-role experience and programming ability. AWS’s senior Developer Advocate role asks for strong programming skills and full-stack experience. Program-lead roles can be less code-heavy day to day, but even Amazon’s Head of Developer Enablement role still asks for deep technical fluency and a track record improving developer outcomes. I would not tell every candidate they need to be a senior engineer, but I would say the more technical the company and the more product-adjacent the role, the more coding fluency becomes non-negotiable.

What is the difference between a developer advocate and a DevRel engineer? In the DevRel Trifecta, the Advocate’s primary output is outward-facing trust and education, while the DevRel Engineer’s primary output is inward-facing product improvement and developer experience. Backblaze and JetBrains show what advocacy looks like: tutorials, demos, docs, events, community presence, helping developers get started. Google, Canonical, AWS, and OpenFX show what the engineering-centered version looks like: sample code, client libraries, quickstarts, friction analysis, onboarding flow improvements, API reviews, and measurable adoption outcomes. Both roles communicate. Both may create content. But they are judged by different operating systems.

Is DevRel dying after the layoffs? No. The looser, less measurable version of DevRel took the hit. The function itself is still active, but it is being rebuilt around activation, retention, documentation quality, friction reduction, and clearer ROI stories. That is consistent with the 2024 State of Developer Relations data, with current AWS enablement roles, and with practitioner analysis on how DevRel creates value. If anything is “dying,” it is the assumption that DevRel can survive indefinitely on brand halo and anecdotal sentiment alone.

How do I get my first DevRel job with no direct DevRel experience? Build evidence for one vertex, not vague enthusiasm for the category. If you want Advocate roles, publish a strong tutorial, record a demo, answer community questions, and show that you can teach. If you want DevRel Engineer roles, ship a sample app, improve a quickstart, or write a docs audit that ties friction to adoption. If you want eventual Program Lead roles, learn to explain what metric your work moves. Entry-level or associate roles do exist, including AWS’s Associate Developer Advocate opening, but many well-paid DevRel roles still ask for several years of experience, so a portfolio is often what proves you can compress that gap.

What companies still invest heavily in DevRel? The clearest answer is: look at who is hiring now. As of July 2026, Google has active Developer Relations Engineer roles including AI-focused and Google Cloud variants; AWS has active Developer Advocate, Developer Experience Engineer, and developer-enablement roles; Canonical is hiring Developer Relations Engineers; JetBrains has advertised a Developer Advocate role; and Backblaze has an active Developer Advocate posting centered on AI/ML and cloud-storage education. Those are not all equivalent roles, but together they show that major platforms and developer-tools companies are still investing in DevRel and DevEx, but with more explicit ties to developer activation, technical education, and product feedback than the market expected a few years ago.

Is DevRel salary still competitive with software engineering? Sometimes yes, sometimes not, and the answer depends heavily on vertex and level. The current salary data shows DRE roles clustering in engineering-adjacent compensation territory, with Glassdoor’s U.S. average around $142,969 and senior DREs around $170,211. Senior Advocates also earn well, with Glassdoor showing about $171,255 average. But advocate salary data is messy: Glassdoor and ZipRecruiter differ by almost $50,000 on the base Developer Advocate title. So rather than comparing “DevRel” to engineering in the abstract, compare specific roles, levels, and comp structures.

Can AI replace DevRel? AI will absolutely replace some DevRel tasks. It will not replace the whole job. It can draft content, summarize feedback, scaffold docs, and generate sample code faster than most humans. But the parts that matter most in durable DevRel roles are still hard to automate fully: identifying real developer friction, earning trust with a skeptical technical audience, deciding which product problems are worth elevating, designing a coherent adoption path, and translating developer behavior into decisions executives will fund. Even Vercel’s aggressive AI-assisted operating model still moved humans toward higher-value, less repetitive work rather than eliminating the need for judgment.

What is the safest DevRel career path right now? The safest path is usually to build toward the DevRel Engineer or quantitatively minded Program Lead vertices while keeping enough public teaching skill to operate credibly with developers. In practical terms, that means technical strength, docs and onboarding instincts, and comfort with metrics. If you start in advocacy, learn the adoption funnel. If you start in engineering, learn to teach. If you want leadership, learn to defend budget with real outcomes. The people I see last longest in this function are the ones who can code, communicate, and quantify.