My last day at Dagster has wrapped up, and after two years of building and running developer marketing, I thought I’d take the time to answer some questions I often get about DevRel and developer marketing.
The timing feels right to share what I’ve learned.
It seems like DevRel has had a resurgence lately. I’ve seen more discussions on it on X, and many more job postings and recruiter calls trying to fill these roles. I sense that it’s related to the challenges of breaking through the noise within the latest AI/LLM craze that has been building over the past few years.
Google Search/SEO is dead; the cost of producing mediocre automated content is essentially zero, and so the question on many people’s minds is How do we reach developers?
The answer often defaults to “hire DevRel,” and often, I think people have not thought about it more deeply than that.
This post is a reflection on many things I’ve learned running DevRel, and hopefully can provide a framework and some guidance on answering questions I hear often.
DevRel at Dagster
When I first joined Dagster, it was to run the DevRel team, and one of the first things I quickly realized was that no one really knew what the goal of the DevRel team was. Everyone had an opinion on what DevRel should do at Dagster, but no one agreed on that definition.
The result was a lot of little tasks being completed, but without an overall story or narrative for it to fit under. This inevitably led to people wondering what the point of DevRel even was.
This is not unique to Dagster at all, and it’s something I’ve heard many people tell me, both founders and developer advocates have suffered some version of this story.
Over the next 2 years, I helped transform the team into one of the best teams I’ve ever had the pleasure of working with. You’d be hard-pressed to find a single person at Dagster who wouldn’t sing the praises of the devrel team, whether they were producing engaging content that brought new leads in, working directly with the community, bringing product feedback back to the R&D team, helping reduce friction points through excellent documentation and educational materials, or just being hilarious online.
One of the first things I did was have an open-ended discussion at the leadership level about what everyone believed the role of DevRel was at Dagster. The goal was to let the room do the talking and make it apparent to everyone that we don’t have alignment on the purpose of the team. I wrote a big list on a whiteboard of everything the team was doing and worked with the leadership team to identify the most impactful pieces of work on that list.
The items fit nicely in my framework for building DevRel teams, which I call the three pillars of DevRel: awareness, product/community, and education.
With alignment on what matters, I set out to build a team and put in place the processes and routines to help make sure we can execute at a high pace.
The transformation of the DevRel team was so visible that I was later asked to run the marketing team as well. This turned out to be a pivotal moment. The more I worked on marketing, the more I realized the fundamental truth of DevRel: that DevRel is just marketing.
Combining the DevRel and marketing teams was not something I was convinced would work, but after having done it, there was a real (dare I say?) synergy between the teams that, in hindsight, was the absolute right decision.
A strong DevRel team that understands the product and the consumer, paired with domain experts in marketing who can run campaigns, events, and other marketing functions, is the missing glue that can take a DevRel team from a nice-to-have to a core revenue-generating part of the business.
With that out of the way, let’s get into it.
What is Developer Relations?
DevRel, or developer relations, goes by many names: DevRel, developer advocates, developer marketing, evangelists, digital prophets, and so on.
I don’t think there’s universal agreement on what it all means, but here’s my general framework:
Developer Advocates: the people you hire who advocate on behalf of your product. Also sometimes called a DevRel Engineer.
Developer Relations: the overall practice of engaging with your developers along their developer journey. This could be a team, a department, or just an ephemeral idea within the organization. Developer Relations, to me, is a subset of developer marketing.
To understand what Developer Relations actually encompasses, it helps to visualize the full developer journey. I particularly like James Parton’s map from his book that describes this journey. To me, Developer Relations covers the full range of the journey from discovery to scaling.
Developer Marketing: a marketing function that is focused on marketing to developers. Some people believe this is just marketing. I do think developer marketing requires a unique set of skills that differentiates itself from ‘traditional marketing’. Some might argue this is just marketing. While Developer Relations is a large part of developer marketing, many associated functions within marketing don’t belong there: marketing ops, event logistics, partner programs, marketing campaigns, and so on.
The controversial part of this definition is that it presupposes that DevRel is, in essence, marketing. I believe the sooner you accept that, the easier it is for everyone.
In some ways, the name “DevRel” is marketing a marketing role to engineers who would never consider a marketing job.
The Three Pillars of DevRel
As I think of building DevRel teams, I think along three pillars and how to ensure that each is well-served. The pillars are awareness, product/ community, and education. There are other models as well: swyx, for example, has three.
The pillars are not individuals. You might find one hire does well in some but not others, and you might choose to ignore some to focus on another. I do think the pillars have a natural order of importance. If no one is aware of your product, then education isn’t going to be much of a concern. You need awareness before education can have meaningful impact.
Awareness
This is generally the first reason people hire developer advocates. They have a product for developers, and they want more people to know about it. Awareness, when done well, looks like engaging content created for developers about things they care about. Awareness, when done poorly, looks like astroturfed Reddit comments that get you banned from /r/somecategory.
I could write a whole book on awareness, but awareness for DevRel is not that different from general marketing awareness. The reason we hire DevRel for this is that you want people from the community who understand the product and the audience, who can find engaging ways to interact with them.
The goals of awareness are fairly straightforward: increase the number of people who know what your product is, and once they know of you, help them become aware of what your product does.
Don’t become preoccupied with a single channel. You need multi-channel content that reaches developers where they are. You must first understand your audience and who they actually are. What do they do for fun? What problems do they have at work? Where do they look up information? Marketing and Positioning 101 stuff.
At Dagster, our audience was on Reddit, X, and LinkedIn. They were also at conferences and meetups. So that’s where we showed up.
Don’t make the mistake of thinking you can create awareness by talking about how great you are. No one cares. Show up in ways that show how helpful you are. Create content no one else is creating. Everyone is creating the easy stuff. “What is a database?” Who cares. “I spent 10 hours testing the top three database vendors, here’s my deep dive”. Hell yes. More of that, please.
Create content that goes ahead of your product. What do people care about before they learn about what you do? At Dagster, data engineers decide to buy Dagster only after they’ve decided to build a data platform. So we created an ebook about building data platforms. It became one of our top-performing assets. Why was it successful? Because it wasn’t easy to do.
We printed it and brought it to conferences, and it flew off the shelves. Colton, who co-authored the book, even did a book signing at one of our conferences. You would not believe the lineup.
You should almost always start with an awareness-focused hire, and they should be spending half their time showing people how they can solve problems with your product, and the other half creating content about problems people face before using your product.
Product & Community
I group product and community because they are so intertwined. Product is all about contributing to the development of the product, whether through deep and thoughtful feedback, or through actual code or integrations. Community is all about staying close to your users, whether free or paid, to maintain a pulse on what the broader community vibes are, and feeding this information regularly back to both R&D and leadership.
This impactful type of work of giving frequent and in-depth feedback on the product, means your developer advocates need to be able to understand the product and be given enough time to use it in their day-to-day job.
A great exercise for a new hire is to have them run through onboarding and create a friction log of everywhere they got stuck. Chances are, your engineers have forgotten how difficult it is to use the product, given how intimately familiar they are with the code. Odds are they never need to pull up the docs to understand what feature X is or how to do Y.
This is why it’s so critical to hire DevRel from the community. I’ll talk more about finding DevRel later on in this post.
But product is not just about feedback; great DevRel hires go deeper. They contribute to the product itself. Especially with AI assistance now, the ability for developer advocates to work like an R&D team means added capacity to make the product better. One of the highest impact things our team had done at Dagster was create integrations that were requested by the community: you can see our impact on things like the dagster-sling library or Airlift.
Airlift is a particularly great example. I built a throwaway proof-of-concept of being able to peer into an Airflow instance from Dagster, and the POC was so compelling that an engineer took it and made it into the powerful integration it is today.
Beyond integrations, DevRel teams can also create additional tooling that helps solve common user pain points. This is often work that an engineering team can’t justify, but can be a great way for a developer advocate to stay current on their technical skills, while also contributing back to the product and community. A win-win.
Education
Education is the final pillar, and it requires a specific mindset and persona that is hard to find but life-changing when you do. Often, this person might be a technical writer, or maybe they create online educational courses. In our case, we have both.
I cannot over-emphasize the importance of good documentation. It is how developers learn about what your product actually does. We developers are trained to skip the marketing headlines and go straight to the docs to see what this product actually looks like, and what it can do. Anytime I go to a product’s website and view the docs and see mostly unfinished content, placeholders, and boilerplate, I just know they’re bleeding traffic.
Your engineers are not good at writing docs. They don’t want to do it, and they don’t know how. They will write docs if you tell them to, but they do not think about the overall information architecture that makes a complex product easier to understand.
Hire a good technical writer.
If your product is complex, documentation may not be enough. You may also need structured online courses, cookbooks, how-to guides, code examples and snippets, tutorials, example projects, and more. Keeping all of these up-to-date and deprecating where possible is a full-time job. Hire for it.
Should I hire a Developer Advocate?
I’m so glad you asked. Most don’t. You should start by asking why you want to hire one. It’s the same argument Claire Carroll makes in her post “How to build a community’ so just read that and replace community with DevRel and you’ll get the same experience.
You should really know why you are hiring for this role, what you want them to accomplish, and how you will enable them to be successful. That is your job.
I’ve seen way too many cases of someone hiring a junior person to ‘do devrel’; they get very little guidance on what that means, and before you know it, the person is let go, and devrel is deemed a failure.
Here are some great questions to ask yourself first:
Is my product ready for a DevRel hire? Do I already have some product market fit?
Will I hire a senior person or a junior person? If I hire a senior person, will I give them clear guidance on what I want them to accomplish? If I hire a junior person, I am prepared to meet with them regularly to help guide them on what they should be working on.
What part of the business needs the most help? Do we need more people to know about our product? Or do we have a lot of complaints about how complicated our product is to use?
Am I willing to invest in this for the long term? Or am I going to hire one person to do everything, burn them out, and wonder why they quit after six months?
Where do I hire DevRel?
Assuming you decided you want to hire one, how do you go about finding someone to hire?
The number one advice I give here is to avoid looking for career devrel people. It is so much better to hire people in your actual developer community who have been doing the actual work of developers, but that show the signs of a promising devrel talent. They may share their projects online, they might have created great blog posts, they may just be really funny on X. It’s so much better to pull from the community than to look for someone with 5 years of DevRel experience.
I say this as someone with several years of DevRel experience, too. Some red flags to look for:
They spend most of their public persona talking about themselves, and not the product or problem.
They can’t code their way out of a cardboard box.
They don’t come from the same domain as your product. Don’t hire someone who’s been doing front-end devrel for your security product.
Some green flags to look for:
A few blog posts that go deep on a topic
A history of talks, presentations, and other public speaking roles
GitHub profile with actual projects that pass the sniff test, not just random forks.
Named Pedram
Where do you find these magical devrel people? Don’t go looking in “DevRel” communities, or lists of Top 100 DevRel of 2025. Look in your community. Find users of your product or users of your competitor’s product. Find a blog post someone wrote that you really like.
How do you convince them to join? Reach out to them, personally. Tell them who you are, how you found them, and if they’d consider working for you. My best hires were from directly reaching out to candidates with promising potential.
What does success look like? Why does DevRel get a bad rap? Why is it so hard?
These are all related questions, and I think they boil down to a common theme. It is really hard to measure DevRel. In fact, before combining the DevRel and Marketing teams, the only good measurement I had was vibes.
There were all sorts of metrics on productivity, and I even maintained a Notion database of everything we did, from blog posts to webinars to YouTube videos. But I try not to focus too much on engagement metrics. 100 highly qualified readers of a post can be 10,000 low-quality engagement bait readers.
However, once we brought marketing and devrel together under one roof, it did become easier to measure the effectiveness of the team through marketing campaigns.
Not everything DevRel does falls under a marketing campaign, but many things do: webinars bring in leads that drive pipeline, social posts drive awareness and engagement that help us build lead lists, and new integrations bring new users who previously weren’t qualified.
It’s still not a perfect measure. I don’t think you can measure the impact on the pipeline of your docs, for instance.
I think the measurement questions are largely a red herring. The reason I think DevRel teams fall apart isn’t because they can’t measure their success through metrics, but because they haven’t defined the goals of the team up front.
If DevRel fits into the broader GTM strategy, and there’s clear alignment on how DevRel supports the overall company’s goals, then the only question is whether or not the team is executing well. You don’t measure engineers by lines of code written, but by how much the CEO loves the engineering org. I think the same can be said of DevRel. Does everyone at the company love working with them? Could they imagine not having them around?
A good DevRel team feels indispensable. A bad DevRel team fights over attribution of leads on a blog post. The problem is usually not the metrics, but something deeper.
Proving the Value of the Investment
Mehdi asks: What I realized is that devrel takes time to build. Even if you have the right people. It’s hard to get short-term/mid-term results. How do you convince higher-ups that it’s worth the investment?
I think of this the same way I think of joining a new company or running a marketing team. You have to start with quick wins to build trust, and only then will you earn the right to work on things that take time to build.
The good news is that it’s not that hard to get quick wins within DevRel. Something as simple as hosting a biweekly/monthly webinar, writing a newsletter, and getting a few hundred subscribers, creating a 3-part YouTube series on the product, are all short-term, achievable tasks that can demonstrate your ability to perform.
Once you’ve built that trust, it’s about selling the story of your big idea. I often talk about how, in the age of AI, anyone can produce something easily. Undifferentiated content might as well be no content.
Developers want deeply technical, well-produced, engaging content. If your goal is to bring in a new audience, you need big bets to hit that next step function of success. Incremental improvements alone won’t get you there.
My advice is to plan out a quarterly roadmap, reserve 35-65% of the time for a big-bet project, and the rest for smaller quick wins throughout the quarter. Get alignment up front, and try to address concerns ahead of time. Three weeks in, when the exec team forgets, remind them that you’re cooking something that’s going to be great. Find a way to funnel new requests so that they feel heard without thinking every request gets prioritized ahead of what’s in flight.
On the flip side, how does one land or find a DevRel job?