Developer relations fundamentals

It is the function that owns the relationship between a company and the developers who build on, or could build on, its product. Concretely that means three streams of work: helping developers succeed with the product, carrying what those developers experience back into product and engineering decisions, and making the product known to developers who have never heard of it. The reason it exists as a separate function is that none of the neighbouring teams does all three — marketing owns awareness but not the feedback loop, support owns individual problems but not the pattern across them, and engineering owns the product but is structurally too close to it to see the first-hour experience. The cost of the arrangement is that DevRel owns no system of record, so all of its leverage is borrowed.

The three are routinely used interchangeably in job adverts and mean genuinely different work, which matters because a role sold as one and measured as another is the most common way a DevRel hire goes wrong.

function              primary output            measured on              reports to, usually
--------------------  -----------------------   ----------------------  -------------------
developer advocacy    talks, posts, samples,    activated developers,   DevRel, marketing
                      workshops, feedback       sentiment, feedback
                                                landed in product

developer marketing   campaigns, launches,      leads, signups,         marketing
                      positioning, events       campaign attribution

developer experience  the product surface:      time to first call,     product, engineering
                      SDKs, docs, errors,       support ticket volume,
                      onboarding                integration completion

community             forum, events, champions  retention, contribution DevRel, support
                                                answer rate

Read the third column rather than the first, because that is where the roles diverge. Advocacy and marketing produce similar-looking artefacts and are graded on completely different things: a campaign is successful if qualified developers arrive, and a piece of advocacy is successful if the developers who arrive get somewhere.

Developer experience is the one most often misfiled. It is product work — it changes the thing developers touch — and when it is staffed inside DevRel without engineering ownership, the team ends up documenting friction it has no authority to remove. That arrangement produces excellent friction logs and no fixes.

The practical consequence for a candidate is to ask, in the interview, which of these four the job actually is and which metric it will be reviewed against. A role titled advocacy but reviewed on marketing-qualified leads is a marketing role, and it is better to know that before accepting it than in the first quarterly review.

Most commonly into marketing, sometimes into product or engineering, occasionally standing alone under a founder. The line matters because it decides which metric the function is defended with when budgets are cut. Under marketing, DevRel is asked for pipeline contribution and drifts towards top-of-funnel content. Under product, it is asked for feedback quality and drifts towards research. Under engineering, it is asked for artefacts — SDKs, samples — and drifts towards building. None of these is wrong, but each quietly reshapes the job, so a candidate should read the reporting line as a description of what the role will become within a year rather than as an org-chart detail.

A developer advocate represents the company to developers and represents developers to the company, and those two directions pull against each other. Outward, you are expected to be enthusiastic about the product; inward, you are expected to be the person who says the onboarding is bad. An advocate who only does the outward half becomes a marketing channel and loses community credibility, which is the only asset that made them useful. One who only does the inward half becomes an internal critic with no distribution. The tension is managed by being scrupulous about factual accuracy in public — never overstating a capability — because that is what buys the room to be critical internally without being treated as disloyal.

Evangelism is the older term and describes a narrower, more one-directional activity: persuading developers to adopt a technology. Advocacy as the term is now used includes that but centres the return path, advocating for the developer inside the company. The shift in vocabulary tracked a real change in what the job was asked to do, as companies discovered that persuasion without a feedback loop produces developers who adopt, hit the same wall repeatedly, and leave. If an interviewer uses "evangelist", it is worth clarifying which they mean, because some organisations use the older word for the newer job and some mean exactly the older job.

audience             what they need from you        what they decide       fails if you
-------------------  -----------------------------  ---------------------  -------------------
hands-on developer   working sample, honest limits  whether it works       market at them
                                                    at all

tech lead            architecture, failure modes,   whether to standardise oversimplify
                     migration path                 on it

engineering manager  team ramp-up cost, support     whether to fund the    ignore cost
                     model, hiring implications     integration

procurement or CTO   contracts, compliance,         whether to sign        speak only
                     roadmap credibility                                   to developers

The table is a reminder that a single piece of content usually addresses exactly one of these rows well. A tutorial written for the first row and then padded with compliance reassurance for the fourth serves neither, and the padding is precisely the thing that makes developers distrust vendor content.

The sequencing matters more than the segmentation. In a developer-led sale, the first row creates the demand and the fourth row signs, and the second row is the gate that most often kills it — a lead who has decided your API is not something they want to be on call for. Advocacy that only ever addresses row one produces enthusiasm that stalls at the standardisation decision.

The practical move is to know which row a given event, post or conversation is for, and to be willing to say "that is a question for a different conversation" rather than answering a procurement question badly in front of a developer audience. Mixing the registers is what produces the talk that everybody in the room recognises as a pitch.

It is the strategy of growing adoption primarily through developers helping other developers — answering questions, publishing integrations, recommending the product internally — rather than through paid acquisition. It assumes two things that are frequently untrue: that the product is good enough that a recommendation does not damage the recommender's credibility, and that the product has a natural reason for developers to talk to each other about it. An API that a developer integrates once and never thinks about again will not sustain a community regardless of programme quality, and pouring community investment into that shape produces an empty forum. Check the assumption before adopting the strategy.