At several companies I’ve worked for, we’ve had developer advocates dedicated to particular programming languages: Java, PHP, JavaScript, etc. That structure makes sense because knowing a language gives you more than its syntax. You understand the conventions of the community, the problems people regularly encounter, and where they go to learn from one another.
I’ve been wondering why we couldn’t organize the next generation of advocacy around domain expertise in the same way. Someone who has spent years in real estate or legal operations already understands a set of problems in considerable detail. If AI helps them build software without first becoming proficient in programming, they have a way to explore solutions that previously required finding a developer or persuading an internal team to prioritize the work. For Developer Relations, that opens up an audience much larger than the one we’ve traditionally served.
An audience beyond developers
I recently wrote on LinkedIn about doing DevRel through agents. An agent may read our documentation and attempt an integration, but we are still trying to reach the person using it. That person doesn’t necessarily consider themselves a developer or want to become one; they may simply have a problem in their working day that they can now explore solving themselves.
For me, Developer Relations still involves understanding people’s work, earning their trust, and listening when our tools don’t meet their needs. An agent changes how some of that interaction happens, but it doesn’t take the person’s place. Our guidance needs to reach them with its limitations and trade-offs intact, including the decisions that remain theirs to make. We should judge what the agent explains back to them, rather than only whether it completes the task.
A person with fifteen years of experience in operations might need help understanding an API, but they probably don’t need us to explain where their workflow is inefficient. They know which exceptions turn up every week and why the obvious solution hasn’t worked before. They’ll need support evaluating what they build, but their professional knowledge gives us a much better starting point than treating them as a complete beginner.
Meeting domain experts where they are
Meeting people where they are has always been part of DevRel, and these audiences give us new places to do that work. If we want to reach professionals in legal operations, we should consider the events and communities where they already discuss their work. A talk there could start with a workflow they recognize and show how our tools might help, rather than assume an interest in the technology itself.
That also asks us to specialize differently as advocates. If our company’s tool is particularly useful for go-to-market work, the advocate serving that audience should be an expert in GTM, just as we’d expect a PHP advocate to be an expert in PHP. They would need that domain expertise alongside a deep understanding of our company’s technology, so they can judge whether a technically correct solution makes sense in practice.
A GTM developer advocate could run a workshop on building an account research tool with AI, drawing on their own GTM experience to explain what useful research looks like and where the output falls short. They should be able to guide participants through both the technical choices and the practical considerations of using that research in their work. Participants would bring the specifics of their own workflows to a discussion grounded in shared domain expertise.
I’m less interested in competing with AI to explain syntax to complete beginners than I am in helping experienced professionals make use of developer tools in their own field. Technical education can start with something they already care about, and mentorship can continue as they work out what they can reasonably maintain or when to involve an engineer.
These activities still need a clear purpose and follow-through. A workshop should connect to guidance people can use afterward, and what we learn from participants should feed into our understanding of the audience.
Who gets to become an advocate?
Organizing advocacy around domains would give people with previous careers outside software another route into Developer Relations. They would still need technical competence, including the ability to explain our tools’ implementation and limits. But I see no reason why a background in go-to-market, legal operations, or real estate couldn’t be as relevant to a particular role as a background in Java development.
That domain experience would also be useful inside the company. An advocate could help identify worthwhile use cases, explain our tools in terms that make sense to their audience, and tell us why a technically successful integration is awkward to use in practice. Their understanding of the work, together with what they hear from the community, could inform both marketing and product decisions.
We’ll still need to make our documentation and examples work through agents. Alongside that, I’d like us to put more thought into reaching people who have spent twenty years becoming experts in something else and have no intention of changing careers. For me, that’s a reason to build DevRel programs around their expertise, with examples and relationships grounded in the work they already do.