What is a developer advocate? The role, the work, and how to get in

A developer advocate is a technical professional who sits between a company that builds developer tools and the developers who use them, creating content, building community, and carrying developer feedback back into the product team.

I have done this for three-plus years, across several companies, and everything here comes from the work itself rather than from research. My own path ran from early-stage startups to an agency where I now watch the role play out for many clients at once. That cross-company view is the thing I want to give you here, because the role changes shape depending on where you do it, and no job listing will tell you that.

Developer advocate, developer evangelist, DevRel. What is the difference?

The titles are used interchangeably, and because of this confusion, people in the field openly argue about it. I once spent an hour at a conference debating it with a group of other advocates, and we landed on a simple conclusion. The title matters far less than where the role reports and what it is measured on. The best way to tell the three apart is by direction, by who the role points toward.

DevRel, short for developer relations, is the umbrella term. It is not a single job. It is the function within a company responsible for the relationship with developers, and it usually holds a few roles at once. Advocates, community managers, and sometimes developer experience engineers, who spend most of their time writing sample code and SDKs.

A developer advocate works in two directions. You create content (right, technical content), answer questions that the devs or people who use your product ask, and help developers succeed with the product. You also carry what developers tell you back into the company, so product and engineering hear it. The advocate's loyalty leans toward the developer.

A developer evangelist points outward. The term dates back to Apple's Macintosh division in the early 1980s, and Guy Kawasaki, who joined as a software evangelist in 1983 and later returned as chief evangelist, is most often credited with popularizing it. Evangelism is about awareness and promotion, and in a lot of companies, it sits inside marketing. The word has faded because "evangelist" reads as one-directional, all push and no listening, so many teams moved to "advocate" to show that they take feedback seriously.

In practice, the line between advocate and evangelist is thinner than these definitions suggest. I have held the advocate title, done plenty of evangelism, and watched evangelists run the kinds of feedback loops that advocates are supposed to own. What determines your actual job is the company's goal and where the role reports to, not the title on your LinkedIn profile. A useful habit when you read a job posting: ignore the title and read the responsibilities, because that is what you will be measured against.

What does a developer advocate actually do day to day

A developer advocate's week usually splits across content, community, events, and internal work, and the balance shifts constantly depending on what is shipping.

At Hackmamba, the biggest block of my time goes to creating technical content across clients. That means hands-on work with frameworks like Playwright and DevOps tooling, and I go deep into it. After that comes managing the community, distributing the content so it reaches developers where they already are, and internal content work alongside the growth team. When it's the week of content delivery, or when a content piece is published, it tilts towards content creation and distribution. A quiet week tilts toward community and the internal work.

The work falls into six buckets.

1. Creating technical content is the widest bucket, and it is where your credibility is won or lost. It covers more formats than people expect. There are blog posts and tutorials, documentation, videos that walk through workflows when text alone is not enough, and code samples, demos, and SDKs that a developer can copy to get something running fast. This is also where credibility comes from. If your content does not work when a developer runs it, nothing else you do will land. The best pieces come from using the tool, hitting the rough edges yourself, and writing through them, which is why I spend time inside the products rather than skimming their docs. A sample app you built and debugged teaches more than a paragraph describing what the product can do.

2. Community engagement is the bucket that compounds slowly, and it runs deeper than answering questions in Discord, Slack, forums, and GitHub issues. It also means running the slower work of onboarding new contributors and keeping discussions alive. The members who stayed came from showing up every week, replying to the question nobody else answered, and remembering what someone was working on last time. A launch-day spike of attention brings numbers that leave by the weekend.

3. Speaking and events are the most visible bucket and the one most people picture first. It covers conferences, meetups, webinars, and the occasional livestream. I have spoken at developer conferences and run hands-on workshops and hackathons, and the format matters less than the preparation. A talk that demos something real and breaks in front of the audience teaches more than a slide deck that shows nothing running.

4. The feedback loop is what separates a developer advocate from a content writer who happens to code. You sit close enough to developers to hear what frustrates them, and your job is to carry that back to product and engineering in a form they can act on. A pile of complaints is not feedback. A clear pattern, with examples and a sense of how many people hit it, is. Doing this well is what separates an advocate from a content writer who happens to know how to code.

5. Cross-functional work is the least visible bucket and the one where most of your influence lives. Marketing, product, and engineering all have a stake in how the developer audience is approached, and the advocate often ends up aligning them. This is the least glamorous bucket and the one that fills the most calendar invites. It is also where much of your real influence lives, since the feedback loop only works when the people building the product trust your reading of the audience.

6. Measuring what you did is the bucket that keeps the other five funded. The job comes with a question you have to keep answering: Did any of it work? That means tracking engagement across content and the community, monitoring which tutorials are used, and reporting back so the team can see where the effort paid off. Advocacy is easy to dismiss as soft work until you can show what moved, so the advocates who last are the ones who can point to numbers when someone asks what a quarter of content and community returned.

Put those six together, and the shape of the job comes into focus. If you want to write code all day, this is not the right job. If you want to do nothing but speak at conferences, it is not that either. The work is a mix, and that mix decides which skills you need more.

Developer advocate job description and required skills

The role varies by company, but most job descriptions come back to the same three skills, which I think of as the three Cs. Code, content, and community. Every requirement you will read in a posting is a version of one of these, and the advocates who do the job well hold all three at once. A great writer who cannot code or understand technical concepts can't retain developers. An engineer who cannot explain the product idea would write content that no one would finish reading. Someone good at both who has no feel for the community talks past the people they are supposed to serve.

Code comes first because it is the foundation. You can get by without being the strongest engineer in the room, as long as you write code that runs and reason about a system well enough that developers trust you. I came into advocacy from the engineering side, having shipped open-source contributions and written docs that developers used, and that background does more for credibility than anything else. The moment a developer catches you faking technical depth, you are done.

Content is the skill that turns what you know into something other people can use. Great written and verbal communication carries equal weight with the technical bar, because the whole job is making something complex understandable the right way. Public speaking sits here too, and the bar is lower than people fear. You can start with a five-minute lightning talk and build up from there.

Community is the one that I would say is the hardest of the three to teach because it is more of a habit than a skill. It looks like showing up in the same Discord week after week, remembering what someone was building last time, and answering the question that has been unattended for three days. Engineers who move into advocacy sometimes underestimate this part. They assume good content pulls a community together on its own.

What holds one together is consistent presence, the sense that someone is around to debug their problems. Developers can tell, just by reading your text, whether you respect them or are selling to them, and the whole relationship depends on which they sense. We dug into this in more depth in our guide on creating engaging developer community content.

How much of each C you need depends on where you work, and postings don't always make it clear. At a startup, you do a bit of everything, often alone, with room to define the role yourself. At a large platform company, the role narrows. You might own a single SDK or a single audience segment, and the technical bar is usually higher. They are different jobs wearing the same title, and knowing which one you are signing up for saves you from a bad fit. That difference in company and stage also explains why the pay for this role varies so much.

What does a developer advocate earn

When we are talking about this role, I believe we should also discuss how much you can earn from it. Even if they are estimates.

The numbers vary depending on who you ask. Salary.com puts the United States average at around $69,000, ZipRecruiter at around $86,000, and Glassdoor at around $136,000 for total pay, with senior advocates on Glassdoor averaging closer to $166,000. At the top end, Levels.fyi reports Google's developer advocate compensation running from roughly $192,000 to $376,000 across levels, with a median package around $214,000.

Those figures are not measuring the same thing, which is most of why they look so far apart. Some report base pay; others include bonuses and equity; and each sample includes a different mix of companies, seniority levels, and locations. Read carefully, the spread still tells you something useful once you know what drives it.

Three factors do most of the work. The first is the company's stage and type, since a well-funded platform company pays on a different scale than an early-stage startup. The second is whether the role reports to engineering or marketing, which often sets the pay band before anything else. The third is location, because the same title pays very differently across regions. I have seen this gap.

Two advocates I know hold the same title and the same seniority, and their total compensation differs by a big margin, almost entirely because one role reports to engineering and the other to marketing.

So when you are weighing an offer, the most useful number is the range for your seniority at a company of a similar stage and reporting structure. A Series B devtools company with the advocate reporting into engineering is a different market than a startup with the role under marketing, and the two ranges barely overlap.

If those numbers make the role appealing, the next question is how to get into it, and that turns out to be more open than most people assume.

How to become a developer advocate

The most useful thing about developer advocacy is that you can start doing it before anyone hires you to do it. The path in is more open than for most technical roles, and the reason is simple. The work is public. You do not need someone to hand you access to a private codebase or an internal team. You need a tool you use, something you write about, and a community where the right people will read it. Here is how to put that to work.

Start by building in public and writing technical content regularly. A body of work that shows you can explain things clearly is the best proof you can send that you will be good at the job. Publish where developers and hiring managers already read. A personal blog or dev.to works for the long-form pieces. Short posts on LinkedIn and X are where that work gets noticed, since a thread breaking down something you just learned travels further than the same lesson buried in an article. Write the tutorial you wish had existed when you were stuck, then share it where people who were also stuck are likely to see it.

Connect with the people already doing this. Developer advocacy is an open field, and a lot of it runs through the same online circles. Follow advocates whose work you respect, reply with something useful rather than a filler, join the Discord and Slack communities around the tools you like, and show up in them consistently.

A few people are worth following if you want to see the job done well. Aditya Oberai is a developer advocate at Appwrite who was named CMX Community Professional of the Year in 2024 and is especially strong on the community side. Sohan Maheshwar is a developer advocate lead at AuthZed with more than a decade in DevRel, including years at AWS. Francesco Ciulla is a developer advocate at daily.dev who built a large following through consistent video and social content. Will Russell is a developer advocate at Kestra who came up through developer education and open source.

Most of the roles I have seen people land came through a relationship that started this way, not through a cold application form. Speaking helps for the same reason. Start with smaller meetups and local events where the stakes are low, get comfortable in front of a room, and let the people there get to know your work.

Contributing to open source also does wonders. It gives you the technical credibility the role demands and puts you in the exact situation the job is about: helping another developer get unstuck. Pick a project tied to a tool you use, fix the documentation that confused you, answer questions in its issues, and over time, you become a familiar name in that community.

None of this requires permission, and that is the ultimate shortcut. Pick a tool you like, do the work in the open, and let it accumulate. That portfolio, plus the relationships you build along the way, is what gets you hired. The full path deserves its own piece, and one is worth writing.

Looking for developer advocate roles

If you are searching right now, developer advocate and DevRel roles do show up on the general job boards, but they are scattered there and easy to lose among unrelated postings. Specialized boards make them far easier to find. devtooljobs.hackmamba.io tracks open developer advocate and DevRel roles across devtools companies, which spares you the work of filtering a general board for the handful that fit.

A note before you go

If you take one thing from all this, let it be that "developer advocate" is not a single job. It is a shape that changes with the company, the reporting line, and the stage, and the smartest move before chasing the title is working out which version of it you actually want.

I came into this from engineering and learned the rest by doing it across very different teams, and the learning never really stops. If you are weighing the role yourself, that is the part worth sitting with, and my inbox is open if you want to talk it through.

FAQs

1, What is a developer advocate?

A developer advocate is a technical professional who bridges a company that builds developer tools and the developers who use them. They create content, build community, and carry developer feedback back into the product team. The role sits at the intersection of engineering, product, and marketing, but its primary allegiance is to the developer, not the sales funnel.

2, What skills does a developer advocate need?

Code, content, and community. You need enough technical depth that developers trust you, the ability to explain complex things clearly in writing and in person, and the habit of consistent community presence. The third one is the hardest to teach. Engineers moving into advocacy tend to underestimate it and assume good content pulls a community together on its own. It does not.

3, How much does a developer advocate earn in 2026?

In the US, entry-level roles run $90k to $120k base. Mid-level $130k to $160k. Senior and head of DevRel $170k to $260k. The two biggest factors are company stage (platform companies pay on a completely different scale than early-stage startups) and whether the role reports to engineering or marketing. Two advocates with the same title and seniority can have a significant compensation gap almost entirely because of that reporting line.

4, Will AI replace developer advocates?

The honest answer depends on what kind of advocate you are. Developer advocates whose primary output is generic blog posts and social content are already competing with AI pipelines that produce the same work faster. The ones who are becoming more valuable are community connectors: the people who are the last authentic human touchpoint between a company and its developer base. Trust, friction removal, and developer success are things AI cannot replicate. Content production alone is no longer a safe value proposition.

5, How is AI changing developer advocacy in 2026?

In two ways. First, content now has two audiences: humans and AI systems. Documentation and tutorials are being ingested by ChatGPT, Perplexity, and Gemini and used to generate answers, which means the structural quality of technical content matters more than it used to. Second, over 75% of developers now use AI tools to solve problems before searching documentation or forums. Developer advocates need to understand how AI-assisted development workflows work because that is increasingly how their audience builds.

6, Is developer advocacy a good career in 2026?

It depends on what you want. The role is one of the few in tech that combines technical depth, writing, public speaking, and community work in a single job. If you like all of those things, it is hard to find a better fit. The risk in 2026 is that the role is under pressure to show measurable business outcomes, activation, retention, revenue contribution - rather than the softer signals it historically reported on. The advocates who will thrive are the ones who can connect their work to numbers someone in finance can read.