A couple of years ago, developer advocacy (also called DevRel) became the most hyped role in tech. The pitch was strong: build in public, travel to conferences, rack up Twitter followers, get properly paid — all without the obligation to ship anything measurable. I call it Zero-Interest-Rate developer advocacy. It was fueled by cheap capital and hype-driven decision-making. Luckily, it's been gone for at least a year or two. But what happened to developer advocacy since then? To answer this question, I have to whip out my credentials. In 2022 (back in the Zero-Interest-Rate era), I joined [Saleor](https://saleor.io/) as a Developer Advocate. That stint ended after less than a year, when I was moved to the product team to work on the newly emerging Saleor app ecosystem. The reason was simple: the ROI from my time spent as a developer advocate was unclear, whereas as a software developer, I could actually deliver something of value. That was totally fair. I actually learned how the product works (you can't imagine how hard developer advocacy is when you don't know what you're talking about) and then, when I moved into a Solution Architect position, I learned who our customers are and what their problems are. With this knowledge, I am back doing developer advocacy. This article is about what's different this time, both for me and for developer advocacy in general. Here are some rules I follow as a developer advocate in the post-hype era (and this is how, I believe, the good developer advocates survived the apocalypse): ## Help first What should a good developer advocate focus on? The hint is in the position name: "you *advocate* for *developers*". "To advocate" means to represent, to support. How are edgy Twitter hot takes and clickbait-y YouTube thumbnails supposed to be contained in that? They are not. It's tempting to forget that doing developer advocacy is not really about you. It's about helping people who try to use your product and get on with their day. To represent their interest best, a good developer advocate should focus on helping first. That can result in producing the type of content you would expect from a developer advocate: examples, blog posts, or videos. What matters is the framing: when it's actually helping people rather than focusing on flashy stuff, it's developer advocacy done right. Why do people choose to do otherwise is clear: because it's not always easy to help people. Sometimes, your users will tell you what they need (by asking you a question on Discord, for example), but other times, they won't (by not being able to find something in your docs and quitting). Arriving at those insights can be tedious, hard work. ## Elevate the product, not yourself Maybe I am cynical, but I suspect some of the companies that hired really popular developer influencers back in the Zero-Interest-Rate Era hoped that it would be a sufficient growth engine for their product. "Just pour *his* Twitter followers into our account list, please". When you are hired based on your following, you are incentivized to continue doing everything you can to grow it. That creates a misalignment right at the start: is this job about elevating yourself or the product and developers using it? If your mind is not in the right place, why would you fix a broken link in the docs or answer a question on Discord when you get much more clout posting hot takes on social media? Post-hype DevRel flips this. Your job is to make the product and developers the heroes. That means doing work that helps developers succeed with the product, not content that showcases your cleverness. The best advocacy is often invisible—it's the work that prevents confusion before it happens. ## Developers don't believe in bad marketing You've probably heard numerous times in your life that "developers don't believe in marketing". My thesis is it was made up by lazy developer advocates who didn't want to do real marketing work. This way, they could get away with shooting their ideas in the dark and not being accountable for them. I only know it because I was one of them. Here's the uncomfortable truth: developers are not special. We have our own quirks, sure, but you can say that about any large audience. The real issue isn't that developers don't respond to marketing—it's that they don't respond to _bad_ marketing (if you want to learn about good marketing, I can't recommend [MKT1 Newsletter enough](https://newsletter.mkt1.co/)). When you don't measure outcomes, you don't learn what works. When you don't know your Ideal Customer Profile (ICP), you can't create content that speaks to real problems. When you don't track Customer Acquisition Cost (CAC) or conversion metrics, you have no idea if your work is generating value or just generating noise. These are basic marketing concepts that many ZIRP-era developer advocates never had to learn, because they optimized for their own Twitter following. If you are wondering what good content fueling good marketing could be, the rules I follow are not complicated. I like these suggestions from PostHog's "*40 things we’ve learned about marketing for developers*": > If you wouldn't be proud to share your marketing with a friend, you shouldn't do it. > > (...) > > If your content doesn't rank well, it's probably because it just [isn't very good](https://posthog.com/newsletter/seo-for-startups?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=marketing-for-devs#7-your-great-content-probably-sucks). Would you share it with a friend you like and respect? Would someone who knows a lot about the topic share it? Is it opinionated? If not, try to improve this first. The standard is simple: would you send this to a developer you respect? If not, why are you publishing it? Developers can smell bullshit from a mile away, and the fastest way to lose credibility is to produce content that doesn't solve a real problem or doesn't respect their time. --- When I was moved off DevRel in 2022, I thought I'd failed at the best job in the world. Now I realize the timing saved me. If I'd stayed in that role any longer, I never would have learned what actually matters: how the product works, who the customers are, what problems they're trying to solve. Developer advocacy is harder than the hype made it look, but it's also more valuable when done right. The standard is simple: would you send this to a developer you respect? Does it help anybody? If not, don't ship it. That's what the job should have been all along.