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.

What sits underneath this section

This section currently has one subsection, which is where the substantive interview questions in this discipline cluster most tightly.

API Advocacy covers the working core of the job for anyone whose product is an API or a platform: deciding what content to produce and in what order, getting onto a conference stage and being useful once there, handling public criticism of a product you do not control, and defending a programme's existence to someone who wants a return figure. It exists as a subsection rather than being folded into general advocacy because API products sharpen every one of those decisions. There is a concrete, instrumentable funnel — signup, key creation, first successful call, sustained use, production traffic — which means the arguments about measurement can be made with numbers instead of with conviction. There is a real build-versus-publish decision, because an SDK or a sample application is code that competes for the same engineering time as the roadmap and then demands maintenance forever. And there is a specific and recurring credibility test: a developer publicly and partly correctly saying your API is broken, where the fix belongs to a team you do not manage and you cannot honestly promise a date.

When you open it, expect scenario questions rather than definitions. The questions there are built around situations with no clean answer — a programme with strong reach metrics and no attribution path facing a budget review, a hostile question from an audience whose complaint is legitimate, a fixed pool of engineering time that both an SDK and a product feature have a genuine claim on. Each states what an interviewer is scoring, which for this discipline is usually judgement about what you control, honesty about what you can prove, and whether you would let evidence change what you do.

Where it sits in a real business

Follow a single developer rather than a single request, because DevRel's effect is spread across a sequence that no one team owns end to end. A backend engineer at a mid-sized company needs to add payments, or messaging, or identity, to something they are building. They search, or they remember a talk, or a colleague mentions a name. They land on documentation and spend perhaps four minutes deciding whether this product can do the job at all — a judgement made almost entirely on whether the first code sample looks like the thing they need. If it survives that, they sign up, create a key, and try to make one call work. If that succeeds, they build something real over the following days. If that works, they ship it, and eventually they recommend it to another team, which is the point at which the company acquired a customer it did not pay for.

flowchart TD
    A[Developer has<br/>a problem] --> B[Finds docs,<br/>a talk or a sample]
    B --> C[Four-minute<br/>evaluation]
    C --> D[Signs up and<br/>creates a key]
    D --> E[First successful<br/>call]
    E --> F[Builds a real<br/>integration]
    F --> G[Ships to production<br/>and recommends it]

The arrow to stare at is D to E, because it is the only step in the chain where the developer must get something exactly right with no feedback except an error message. It is consistently where the largest single-step loss sits, and it is also the step that content cannot fix if the cause is friction rather than ignorance — which is why the discipline keeps colliding with product work.

The commercial shape this sits inside is usually developer-led adoption: the developer evaluates and integrates, then someone else signs a contract later, often much later and sometimes without the developer being in the room. This is why DevRel's contribution is so hard to attribute and why the function is so easy to under-value. The developer who read the tutorial in March may be the reason a contract is signed in November by a procurement team who has never heard of your content programme. Nothing in a standard attribution model connects those two events, and the temptation to invent a connection is the single most damaging thing a DevRel leader can give in to, because an invented revenue figure is visibly derived from an assumption and takes the credible numbers down with it when someone pulls on it.

The return path is the other half of where DevRel sits, and it is the half that gets cut first and matters longest. A developer's frustration becomes useful to a company only if someone reproduces it, quantifies how many others hit it, writes it up in a form an engineer can act on, and then reports the decision back — including when the decision is no. Each of those steps is skippable and each omission degrades the loop. A DevRel team that relays complaints without reproducing them is filtered out by engineering within a month. A team that escalates successfully and never reports back becomes a suggestion box, and the community stops feeding it.

flowchart TD
    A[Signal from a forum,<br/>support or a talk] --> B[Reproduce and<br/>quantify]
    B --> C{Pattern across<br/>several developers}
    C -- No --> D[Log and wait for<br/>a second case]
    C -- Yes --> E[Write up with the<br/>requests and workarounds]
    E --> F[Product review<br/>with the owner]
    F --> G[Report the decision<br/>back either way]

The branch is what keeps the channel credible, and the "log and wait" exit does as much work as the escalation. The final node is where trust is actually built: anyone can relay a fix that shipped, and the community already knows that. Carrying back a decision not to fix, with reasoning honest enough to repeat in public, is the harder internal conversation and the one that establishes the channel is real.

Who does this work

The core title is developer advocate, sometimes developer relations engineer where the role leans technical, or developer evangelist where the company kept the older word. A day is genuinely fragmented in a way that surprises people arriving from engineering: a morning writing, an afternoon answering questions in a public forum, a call with a product manager about something ten developers have now complained about, an evening rehearsing a talk. The proportions vary enormously between organisations, and the ratio of writing to speaking is the single most useful thing to establish in an interview, because a role that is eighty per cent conference travel and one that is eighty per cent technical writing are advertised identically and suit different people.

Community managers own the venues and the people: moderation, the health of a forum or chat server, events, and the champions programme where one exists. This is skilled work whose difficulty is invisible until it goes wrong, and its hardest recurring problem — a highly prolific community member whose behaviour is driving newcomers away — is a genuine judgement call with real cost on both sides.

Developer experience engineers work on the product surface, and are best thought of as engineers with an unusually specific customer. Technical writers own systematic documentation, and in a mature organisation they are the reason the reference material is correct while advocacy is the reason there is a tutorial worth following. A head of developer relations spends most of their time on two things: deciding what the team is measured on, and defending the programme's existence with evidence that survives being questioned.

The distinction worth internalising, because it decides what a candidate should volunteer, is between people who measure their work by what they produced and people who measure it by what changed. An advocate who describes a year of talks and posts with no mention of activation, support volume, or a single product change traceable to their feedback has described half the job and the more replaceable half.

Demand, adoption and how that is changing

Demand is steady rather than booming, and it is honest to say plainly that this is a function often cut early in a downturn. The reason is structural rather than a judgement about its value: DevRel's contribution is real and hard to attribute, its costs are visible and easy to itemise — headcount, travel, events, swag — and a cost that is easy to measure sitting next to a benefit that is hard to measure is exactly the shape that loses a budget argument. When a company reduces spending, the teams that go first are usually those that cannot produce a defensible number, and DevRel frequently cannot, not because the work did nothing but because nobody instrumented the middle of the funnel while times were good.

The more useful thing to understand than the current level is what determines it, because that is what a candidate should read when assessing a specific company. DevRel headcount tracks developer-product strategy almost exactly. If a company's growth depends on individual developers discovering, evaluating and adopting the product themselves, DevRel is close to a growth function and is funded accordingly. If the same company's revenue actually arrives through enterprise sales cycles where a procurement committee decides and developers are told what they will be using, then DevRel is a nice-to-have that supports an existing sales motion, and it will be the first line examined when someone looks for savings. Both companies may sell a developer product. Only one has a structural reason to keep investing in this function.

That gives a candidate a concrete diligence question worth asking directly: how do developers currently arrive, and who signs. A company where the honest answer is "our sales team brings deals and then developers are onboarded" is not a bad place to work, but it is a place where advocacy is a support function with a support function's stability, and it is better to know that going in.

Two further pressures are worth naming without over-reading them. First, developer products have proliferated, which means an individual developer now has more credible options for almost any capability they need, and the differentiator in an evaluation is increasingly the first hour rather than the feature list. That pressure runs towards developer experience investment specifically, which is a reason the DX half of this discipline has been growing more reliably than the events-and-talks half. Second, the balance between in-person events and durable written content has shifted towards the latter over recent years, in part because a recording or an article keeps working for a year while a conference slot does not, and in part because the cost of travel is trivially easy for a finance team to itemise. The practical consequence is that writing has become the more defensible skill of the two, and a candidate whose portfolio is entirely talks is more exposed than one whose portfolio is entirely writing.

A third change is worth stating carefully because it is easy to overstate: as generative tools become part of how developers find and consume technical information, the direct traffic value of tutorial content is under more pressure than it was, while the value of accurate, well-structured primary documentation goes up, since it is what those tools are reading. This does not remove the need for the human parts of the job — reproducing a bug, standing in a hallway, arguing with a product owner, being trusted by a community — and it is those parts a candidate should be able to demonstrate rather than a volume of published articles.

What makes it hard

The genuine difficulty is that the role has substantial responsibility and almost no formal authority. You are accountable for whether developers succeed with a product whose roadmap you do not set, whose error messages you did not write, whose pricing you cannot change, and whose engineering team does not report to you. Every meaningful improvement therefore has to be achieved by persuasion, using evidence you gathered yourself, in competition with commitments that already have owners. This is the part that experience is not substitutable for, and it is why a technically excellent engineer can be an ineffective advocate: the skill being tested is building a case that a product owner acts on, not knowing what the fix should be.

The second difficulty is the dual mandate, which is a permanent tension rather than a problem you solve once. Outward, you are expected to be credibly enthusiastic. Inward, you are expected to be the person who says the onboarding is bad and the errors are useless. Doing only the first makes you a marketing channel and burns the community credibility that made you useful in the first place. Doing only the second makes you an internal critic with no distribution and no leverage. The way the tension is actually managed is by being scrupulous about factual accuracy in public — never overstating a capability, never inventing a roadmap date to end an awkward moment — because that accuracy is precisely what earns the standing to be critical internally without being read as disloyal.

Third is measurement, which is harder here than in almost any adjacent function. The causal chain from a talk to a signed contract is long, indirect, and passes through people who will never know the talk happened. That leaves two tempting failure modes and both are fatal at budget time. One is retreating to reach metrics — impressions, followers, attendance — which have the disqualifying property that they cannot go down for any reason you would act on, so they can never tell you that last quarter was worse than the one before. The other is the sophisticated-sounding claim that community cannot be measured and must be taken on trust, which is how programmes get cut by people who are not being unreasonable.

The row worth dwelling on is the last one, because it is the claim most often reached for and the one that does the most damage. It fails not because the underlying belief is wrong but because the derivation is visible, and once a finance partner discredits one number in the report they discount the ones that were real.

Fourth, and least discussed, is that the job is emotionally exposed in a way most engineering roles are not. Your work is public and your mistakes are indexed. You will be criticised in front of an audience about a decision you did not make and cannot defend, and you have to absorb that without either dismissing a legitimate complaint or promising something you do not control. That is a genuine skill, it is learnable, and it is why interview loops for this discipline almost always contain a live stage with deliberate interruption.

Why study it

The honest case is narrower than the enthusiasm around the discipline suggests, so it is worth being specific about who benefits.

If you are an engineer who already writes and explains well, and finds the explaining more satisfying than the building, this is one of very few career paths that pays for that combination and treats it as the primary skill rather than a bonus. The other thing it gives you is unusual breadth: an advocate sees the product, the users, the market, the sales motion and the roadmap in a way that a specialist engineer usually does not, which is why the role is a common route into product management and into developer-focused founding.

If you work in developer experience, platform engineering or technical writing, the material here is directly applicable even if you never take a DevRel title, because the hard parts overlap almost entirely. Diagnosing where developers drop out, telling a documentation problem from a product problem, arguing for engineering time you do not own, and running a feedback loop engineering respects are the same skills whether the audience is external developers or the three hundred engineers inside your own company.

If you are considering it primarily because it looks like a way to travel and speak, be careful. That component has shrunk relative to writing, it is the first line cut when budgets tighten, and the ratio in any given role may be nothing like the one visible from outside. And if your goal is to deepen technical skill, this is not the fastest route and it is fair to say so — the role's technical demand is breadth and operating knowledge, not depth, and advocates who do nothing hands-on for two years usually think they are fine and are being politely managed around by developers who no longer ask them hard questions.

If you want a function with clear attribution, unambiguous metrics and stable headcount through a downturn, this is not it, and no amount of good measurement practice fully fixes that. It is worth knowing that before you commit to it rather than discovering it in a reorganisation.

Your first hour

Do the thing the discipline is actually built on, which is not reading about it. Pick a public API you have never used — one with a free tier and no sales conversation required — and integrate it, from nothing to a working call, while keeping a friction log open in a second window.

The rules that make this exercise worth the hour are strict. Start from a genuinely fresh account. Write down the wall-clock time next to every moment of confusion, as it happens, not afterwards from memory. Record confusion rather than conclusions: "the dashboard issued a key with a different prefix from the docs example, so I could not tell if they were the same credential" is evidence, whereas "the auth flow is confusing" is an opinion nobody can act on. And do not let yourself fix a problem silently by guessing — note the guess and how long it took.

Friction log: <product>, <task>. <date>. Fresh account.

00:00  Signup. Verification email arrived in Ns.
00:0X  <first point where you had to guess something>
00:1X  <the error you could not decode, verbatim>
00:2X  First successful call.

Total: NN min.
Blockers: N. Of those, N are documentation and N are product.
The one I would fix first, and why:

At the end you have a real artefact, and it is the same artefact this job produces in its first week at any company. Read it back and answer two questions. First, which of your blockers would a correct document have prevented, and which happened because the product punished a reasonable action — that split is the docs-versus-product distinction that everything else in the discipline depends on. Second, what was your own time to first successful call, and how does it compare with whatever number that product's marketing claims.

If you want a second hour, take the single worst blocker and write the four-hundred-word explanation that would have prevented it, aimed at the developer you were an hour ago. That is a work sample. It is more persuasive in an interview than any list of things you have published, because it demonstrates the actual sequence — notice, reproduce, diagnose, explain — rather than asserting that you can do it.

What this is not

It is not marketing with a technical vocabulary. The confusion is understandable, since both talk to developers as an audience and both produce content, but a marketing campaign succeeds when qualified developers arrive and advocacy succeeds when the developers who arrive get somewhere. The second is much more tightly coupled to the product being good, which is why advocacy has a return path and a campaign does not.

It is not a speaking career. Conference talks are the most visible part of the job and are usually a minority of it, and the majority — writing, answering questions, reproducing bugs, building the internal case for a fix — is invisible from outside. Roles marketed on the visible part and staffed on the invisible part are a real phenomenon, and the ratio question is worth asking explicitly.

It is not a technical support team with a better title, though the boundary is genuinely close and many DevRel teams do absorb support work. The distinction is the unit of work: support resolves this developer's problem, advocacy notices that forty developers had the same problem and gets the cause removed. A DevRel team drowning in individual tickets has been redirected into support, which is a common and slow way for the function to lose its actual leverage.

It is not developer experience engineering, and merging the two names without moving the authority produces a team that can describe friction and not remove it. It is not documentation, though it overlaps heavily and an advocacy team publishing parallel unofficial docs that drift from the official ones has made developers' lives worse rather than better.

Finally, it is not a route to influence without technical credibility. The reason developers listen to an advocate is the belief that they have actually built the thing and would say if it were bad. That belief is the entire asset, it is slow to build, and it is spent instantly by one confidently wrong claim on a stage or one invented roadmap date offered to end an uncomfortable question.

Everything this function can achieve rests on being trusted by developers and believed internally, and both of those are held up by the same discipline: never say in public anything you cannot support, and always carry the answer back even when it is no.