Developer Relations

What this area actually covers

Developer relations is the function that owns the relationship between a company and the developers who build on its product, or who could. In practice that resolves into three streams of work that sit awkwardly together and are the reason the discipline exists as its own thing. The first is helping developers succeed: documentation, samples, quickstarts, workshops, answering questions, being present when someone is stuck at eleven at night with an authentication error they cannot decode. The second is the return path — carrying what those developers actually experience back into product and engineering decisions, in a form specific enough that someone acts on it. The third is awareness: making the product known to developers who have never heard of it, through talks, writing, open source, and being in the places developers already are.

No neighbouring function does all three, which is the structural argument for the discipline. Marketing owns awareness and is measured on it, but has no mechanism for the return path and generally lacks the technical depth to reproduce a bug. Support owns individual developer problems and resolves them one at a time, but is organised around ticket closure rather than around noticing that the same ticket has arrived forty times because one error message is ambiguous. Engineering owns the product but is structurally unable to see its own first-hour experience, because everyone on the team has the mental model that the new developer lacks. Product owns the roadmap but hears from customers, who in a developer product are frequently not the same people as the developers.

The boundary that matters most, and the one most often blurred in job adverts, is between developer relations and developer marketing. Both produce content, both attend events, and both talk about developers as an audience. They are graded on entirely different things. A developer marketing campaign is successful when qualified developers arrive. A piece of advocacy is successful when the developers who arrive get somewhere — which means advocacy is judged on things happening after the click, and is therefore much more entangled with the quality of the product itself. A role sold as advocacy and reviewed against marketing-qualified leads is a marketing role with a friendlier title, and finding that out in the first performance review rather than the interview is one of the more common ways a DevRel career goes sideways.

The other frequently conflated neighbour is developer experience. Developer experience work changes the product surface a developer touches: the SDK, the error messages, the onboarding flow, the shape of the API itself. It is engineering work with a particular customer, and when it is staffed inside a DevRel team without engineering ownership, the predictable result is a team that produces excellent diagnoses of friction it has no authority to remove. Advocacy and developer experience are natural allies and are not the same job, and an organisation that merges them without moving the authority has merged the responsibility only.

Two more things get wrongly bundled in. Community management is genuinely part of DevRel in most organisations, but it is a distinct skill set — moderation, event operations, conflict handling, running a champions programme — and someone brilliant at conference talks is not automatically good at it. And technical writing is adjacent, overlapping, and frequently a separate team with a different craft: docs own systematic coverage and reference accuracy, advocacy owns narrative and the worked example, and where the boundary is unstated you get either duplication or a gap that developers fall into.