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.

From three sources, in order of reliability. First, the questions arriving repeatedly in support, the forum, or your own inbox, because a question asked twenty times is evidence rather than a guess. Second, the drop-off data: whichever step in the journey loses the most developers is a candidate for content, provided the cause is not knowing rather than not being able. Third, and last, what the company wants to talk about — a launch, a new capability. The order matters because most content calendars are built entirely from the third source, which produces a body of work that is well aligned to internal announcements and poorly aligned to what developers were stuck on that week.

Content is not one category, and the common failure is a portfolio made entirely of one tier.

tier            example                        job                       decays
--------------  -----------------------------  ------------------------  ------------
quickstart      first call in under 10 min     get to a working call     fast, hard
                                                                          breaks builds

reference       endpoint and parameter docs    answer precise questions  fast, quietly

conceptual      how retries and idempotency    build a correct mental    slowly
                work in this API                model

tutorial        build one real thing           show a full path          fast, and
                end to end                                               ranks well

case or pattern how someone solved a specific  make adoption plausible   slowly
                problem                        to a lead

launch or news  a new capability shipped       awareness                 immediately

The right-hand column is the operational content of this answer. A quickstart that has gone stale breaks a developer's very first experience, so it needs to be treated as a build artefact and tested against the live API on a schedule, not proofread annually.

Tutorials are the dangerous tier. They rank well, they are what developers actually find, and they age badly because they pin a specific version of everything they touch. A three-year-old tutorial ranking above your current reference docs is a real and common failure, and it does more damage than the absence of a tutorial would.

Conceptual content is the tier that gets cut first and has the longest half-life, which is exactly backwards. An explanation of your consistency model or your webhook retry semantics stays true across many releases and prevents a whole class of misuse that no amount of reference documentation prevents, because reference material answers questions a developer already knew to ask.

Because they answer different questions. Reference material answers "what does this parameter do", which is only useful to someone who already knows the shape of what they are building. A tutorial answers "what do I do first", which is the question a new developer actually has and which reference material structurally cannot answer, since it is organised by the product's structure rather than by a task. The usual symptom of a docs set with only reference material is a support channel full of questions whose answers are all technically present in the documentation, which teams misread as a discovery problem and try to fix with search.

Attention, indefinitely. Every tutorial, sample and post is a claim about how the product behaves, and the product keeps changing, so each one carries an ongoing accuracy liability. The liability is worse than for docs because content is not usually inventoried: nobody has a list of every post that mentions the endpoint you are about to change. The practical mitigations are keeping an inventory of content that contains code, dating everything visibly so a reader can discount it, and deliberately retiring or redirecting pieces rather than leaving them ranking. A content programme without a retirement practice accumulates wrong answers under its own brand.

When the developer needs to copy something, scan for a specific detail, or come back to one step. Video is poor at all three: it cannot be searched inside, cannot be copied from, and forces a reader to consume at your pace. It is good at exactly the things text is bad at — showing a tool being used, conveying that something is achievable, and carrying tone. The frequent mistake is producing a video tutorial as the primary artefact for an integration, which developers then pause repeatedly to transcribe. If you make one, publish the written version alongside it and treat the video as the trailer rather than the manual.

Treat it as an urgent correctness problem rather than a ranking problem, because developers are currently following it. The immediate action is to contact the author with the specific corrections, since most will happily update and that fixes the actual harm fastest. In parallel, publish or refresh your own equivalent so there is a current, correct destination to rank, and link it from the places you control. What does not work is asking for the post to be taken down, which is both unlikely to succeed and reliably resented. If the author is unreachable, an explicit note in your docs naming the outdated pattern is the fallback.

It means publishing and answering in the places developers already spend attention rather than requiring them to come to a property you own. In practice that is your API's questions being answered where developers search, your samples living where developers look for code, and your team being present in the ecosystem's existing forums rather than only in your own. The cost is control: you cannot moderate, style or measure someone else's platform, and content there does not accrue to your domain. Most teams over-invest in owned properties because they are measurable, and then wonder why the forum is quiet while the same questions are being asked elsewhere.

Three things. Developers can inspect and often extend the product, so their feedback arrives as diagnoses rather than complaints, and treating it as complaint traffic wastes the most valuable input you receive. They talk to each other in public and permanently, so a bad answer is indexed and quoted years later. And they have unusually high tolerance for a product's limitations and unusually low tolerance for being misled about them, which inverts the normal marketing instinct: understating a capability costs you very little, overstating it costs you the room. Programmes designed from consumer community playbooks generally fail on the third point first.

With people already having the conversation somewhere, which you find rather than create. The failure pattern is launching a forum or chat server before there is any organic discussion, which produces a venue where the only participants are employees and the emptiness itself signals that nobody uses the product. The better sequence is to answer questions wherever developers are already asking them, notice when the same people keep appearing, and only then give them a place to talk to each other — at which point the venue has a reason to exist and a population on day one. Communities are moved, not started.

The number that matters is not volume, it is who answers.

Forum, one month, 400 questions posted

              answered by staff   answered by community   unanswered
month 1              340 (85%)             20 (5%)          40 (10%)
month 12              120 (30%)            250 (63%)        30 (7%)

Same volume, completely different health.

Derived: staff answers per week, month 1  = 340 / 4.3 ≈ 79
         staff answers per week, month 12 = 120 / 4.3 ≈ 28

Time to first response also matters more than completeness:
a question answered in 2 hours with a partial answer retains
the asker; a complete answer after 5 days does not.

The month-one column describes a support channel with a forum's user interface. It works, it does not scale, and its cost grows linearly with adoption, which is exactly the property a community is supposed to remove.

The month-twelve column is what people mean by a community: the majority of answers come from people who do not work for you. Reaching it is mostly a matter of not answering instantly, which is counter-intuitive and uncomfortable. If staff answer everything within minutes, no community member ever gets the opportunity to be the person who helped, and the incentive that produces answerers never forms.

The unanswered rate is the one to watch as a failure signal, because an unanswered question is a public record that asking here does not work. A stable low single-digit percentage is fine; a rising one predicts the channel going quiet a quarter or two later.

This is the hardest recurring situation in community work, because their volume is exactly what makes them influential and their behaviour is what makes them costly. Deal with it privately and early, naming specific behaviour rather than character, and be explicit about what needs to change and what happens if it does not. What fails is tolerating it because they are prolific: the cost lands on everyone else, particularly newcomers who read the tone as the community's tone and leave silently. If it comes to removing them, expect public fallout and accept it; a community that visibly tolerates one abusive high-volume member has already selected who else will stay.

Recognising and equipping the people who were already advocating for you, so their reach and effectiveness increase. It works when the benefits are things those people genuinely want — early access, direct engineering contact, a platform, travel to events — and when selection is based on demonstrated contribution rather than follower count. It fails when it is designed as cheap distribution, because the participants notice immediately that they are being asked to do marketing for a swag budget, and the resulting content is transparently obligatory. The programme also has a real ongoing cost in relationship management, which teams consistently underestimate at the point of launch.

Because chat is optimised for the present and developers arrive with questions whose answers should outlive the conversation. A question answered in a chat channel helps one person and is then effectively lost, so the same question recurs indefinitely and the people who answered it the first four times stop. Add the volume problem — a busy channel is unreadable, so lurkers disengage — and the result is a large member count with a handful of active participants. Chat works for synchronous discussion, events and a sense of presence; durable answers need a searchable venue, and communities that use chat for both eventually consist of employees answering repeats.

Time to first response rising, before any drop in volume. It precedes the decline because posting volume is driven by need and stays roughly flat while the experience of posting degrades; what changes first is how long a question sits. Watch the answer rate by author category alongside it, because a rising staff share means community answerers are disengaging even while the totals look stable. By the time the visible metrics — posts per week, active members — have fallen, the answerers left several months earlier, and re-engaging them is much harder than keeping them would have been.

It is the elapsed time from a developer starting — usually account creation — to their first successful, non-trivial API response. It matters because it is the point at which a developer switches from evaluating to building, and because it correlates with almost everything downstream while being unambiguously measurable, which is rare in this discipline. Its diagnostic power comes from decomposition: measured as a whole it is a number, measured per step it tells you whether the loss is in signup, key creation, authentication or the first request. The usual finding is that a single step dominates, and it is rarely the step the team assumed.

flowchart TD
    A[Lands on docs<br/>or a talk] --> B[Decides it can<br/>do the job]
    B --> C[Creates an account<br/>and a key]
    C --> D[First successful<br/>call]
    D --> E[Builds a real<br/>integration]
    E --> F[Ships to<br/>production]
    F --> G[Recommends it<br/>internally]

The steps are obvious; where the diagram earns its place is that each arrow has a different owner and a different failure mode, and most teams instrument only the first and the last. The gap between B and C is a trust and pricing decision, not a technical one — a developer who believes the API works may still not sign up because the pricing page is unclear or a credit card is demanded before evaluation.

The C-to-D arrow is where developer experience work lives and where the biggest single-step losses usually sit, because it is the only step that requires the developer to get something exactly right with no feedback except an error.

The E-to-F arrow is where you lose people for reasons advocacy cannot fix: rate limits that do not suit their shape of traffic, an SLA they cannot commit to, a missing compliance certification. Recognising which arrow a problem sits on is the difference between fixing it and writing content at it.

The final arrow is the one that compounds and the only one nobody can buy. It is also a genuine measurement: internal recommendation shows up as multiple accounts from one organisation, which is a signal worth instrumenting.

By delivering patterns with evidence rather than anecdotes with urgency. One frustrated developer is an anecdote and will be discounted, correctly; the same complaint from eleven developers, with the specific requests they made, the responses they got and the workaround each adopted, is a defect report. The other half is discipline about volume: a channel that forwards everything gets filtered out within a month, so you have to triage before you escalate and accept that most feedback does not travel. The credibility test is whether you also report back when the answer is no, because a channel that only ever pushes is a lobby, not a loop.

It is a timestamped record of you going through your own product as a new developer, writing down every point of confusion as it happens.

Friction log: create a webhook subscription. 2026-08-04. Fresh account.

00:00  Signup. Email verification arrives in 40s. Fine.
00:03  Dashboard. No obvious path to webhooks. Found under Settings >
       Integrations after guessing twice. Not where docs said.
00:07  Docs example uses a bearer token. Dashboard issued a key with a
       different prefix. Unclear whether they are the same thing. Tried
       both. First one 401s with "unauthorised" and no further detail.
00:15  Signature verification section assumes I already have the signing
       secret. Never told where to find it. It is on a different page.
00:26  First successful delivery received.

Total: 26 min. Three blockers, all in auth. Two are docs, one is the
401 body carrying no reason.

The value is entirely in the timestamps and the fresh account. Written from memory, this becomes a list of opinions; written live, it is evidence with a duration attached, and a duration is what makes an engineering team act.

The second discipline is recording confusion rather than conclusions. "The auth flow is confusing" is unactionable. "The dashboard issued a key with a different prefix from the one in the docs example, so I could not tell whether they were the same credential" names a specific fixable thing, and the fix is fifteen minutes of docs work.

Note what the log surfaced: three problems, all clustered in one area, two of them documentation and one a genuine product defect. That clustering is typical and it is the argument for doing this monthly rather than once. It also gives you the honest version of your own onboarding claim, which is frequently some distance from the marketing figure.

It tells the developer what to change. A bad error names the state — unauthorised, invalid request — and leaves the developer to guess between several possible causes, which is where hours disappear.

Before:  401  {"error": "unauthorised"}

After:   401  {"error": "invalid_key_prefix",
               "message": "This endpoint requires a live key starting
                           sk_live_. You sent a key starting sk_test_.",
               "docs": "https://example.com/docs/keys"}

The rewrite changes three things and each one matters separately. A stable machine-readable code lets the developer branch on the cause without parsing prose. The message names what was sent and what was expected, which converts a guess into an edit. The link goes to the specific concept, not to the documentation root.

The reason this belongs in a DevRel sheet rather than only an engineering one is that error quality is the highest-leverage documentation surface you have, and it is the one developers read. A developer who hits a self-explaining error never files the support ticket, never posts the question, and never appears in your funnel as a loss.

The counter-consideration worth naming, because an interviewer may raise it: error messages must not leak whether a resource exists or why authentication failed in ways that help an attacker. That constrains the wording on auth endpoints specifically, and it is a real trade rather than an excuse for a bare 401 everywhere else.

By asking whether a correct document would have prevented it. If a developer did the wrong thing because nothing told them the right thing, that is documentation. If they did the reasonable thing and the product punished them for it, that is product, and documenting it is a patch over a defect. The tell is a docs page that has to warn people: any sentence of the form "note that you must call X before Y or the request will silently succeed and do nothing" is a product problem wearing documentation's clothes. Advocacy teams accumulate these warnings, and a list of them is one of the more persuasive artefacts you can bring to a product review.

It is the one route through the product that is fully supported, tested and documented, chosen deliberately over the many routes that technically work. Advocacy uses it as the spine of everything it produces — the quickstart, the samples, the workshop — so that a developer following any two pieces of your content ends up in the same place. The cost is that you are explicitly under-serving valid alternative approaches, and someone will complain that their language, framework or architecture is not the blessed one. That complaint is the price of the guarantee, and the alternative is content that covers every path shallowly and none reliably.

Programme committees read a few hundred of these and reject most on the first two sentences.

BEFORE
Title: Building Modern Applications with Our Platform
We will explore the exciting capabilities of our platform and show how
it can transform the way you build applications. Attendees will learn
best practices and see a live demo of key features.

AFTER
Title: Idempotency Keys Are Harder Than They Look
Retrying a failed payment safely requires the client and server to
agree on what "the same request" means. We got that wrong twice: once
by hashing the request body, once by scoping keys per endpoint. This
talk walks through both failures, what broke in production, and the
scoping rule we settled on. You will leave able to review your own
retry logic for the same two mistakes.

The before version fails on three counts a committee reads for. It has no subject — "modern applications" is not a topic — it is about a vendor rather than a problem, and its takeaway is unfalsifiable, so nobody can tell whether the talk delivered it.

The after version commits to a specific technical claim, admits two failures, and states a takeaway the attendee can check afterwards. The admission is doing real work: a talk that includes what went wrong signals that the speaker has operated the thing rather than read about it, which is the main thing a committee is trying to infer.

The product still appears in the after version, in the sense that the war story is yours. That is the acceptable form of vendor content at a community conference — the problem is general, the experience is specific, and the audience can use the conclusion without adopting your product. A talk that only works if you buy something is a sponsor slot, and it belongs in the sponsor track where the audience knows what it is getting.

A talk transfers a model; a demo provides evidence that something works. They fail in opposite directions. A talk with no demonstration invites the suspicion that none of it has been run, particularly for anything performance or reliability related. A demo without a talk shows a sequence of screens that nobody can generalise from, and the audience leaves impressed and unable to reproduce anything. The usual correct shape is a short demo placed after the model has been established, so the audience knows what to watch for. Demos placed first are watched as television.

Say what you expected and what happened, then move on. The audience is far more forgiving than speakers assume, and a calm diagnosis is itself a credibility signal — you are visibly the person who knows what should have happened. What loses the room is silence while you retype, and repeated retries in hope. Practically: have a recording of the working path, know which single step is skippable, and never demo against a live production dependency over conference wifi if a local or pre-recorded path exists. If it cannot be recovered in about thirty seconds, cut to the recording and carry on talking.

Keep the spine and swap the evidence. The model you are teaching usually holds for both a room of platform engineers and a room of application developers; what changes is which consequences they care about and which examples land. For the more senior room, more failure modes and more of the reasoning behind the trade-off; for a newer room, more of the setup, fewer branches, and an explicit statement of the prerequisite you are assuming. What does not work is delivering the identical deck and adjusting only the pace, which produces a talk that is simultaneously too slow and missing what the room wanted.

At a sponsored session or your own event, yes, and the audience has consented to it. At a community conference, no, and the reason is mechanical rather than moral: the room's attention is a loan against the expectation that you are there to teach, and a pitch spends credibility that took years to build for a conversion rate that a sponsor slot would have delivered more cheaply. The workable middle is that your experience operating your own product is legitimate material, provided the conclusion is useful to someone who never adopts it. If the talk collapses without the product, it is a pitch.

Say you do not know, say what you would check, and take the question. Three sentences, then next question. The failure is speculating fluently, because at least one person in the room does know, and being publicly wrong about your own product is much more damaging than not knowing. Taking the question means actually taking it — a name, a way to reach them, and an answer afterwards — which converts a gap into a small demonstration of reliability. Advocates who do this consistently develop a reputation for accuracy that is worth more than an ability to answer everything on the spot.

Not attendance. A talk is worth the cost when it does something no cheaper channel does: reaching a specific audience that does not read your content, having the twenty hallway conversations that produce actual product feedback, or establishing a credibility that a written post cannot. Judge it on what happened afterwards — questions that turned into feedback, developers who arrived, a recording that keeps earning views for a year — against the fully loaded cost, which is travel plus roughly a week of preparation. Many talks do not clear that bar, and saying so about your own programme is a stronger interview answer than defending all of them.

A metric is vanity when it cannot go down for a reason you would act on.

metric                    tier         can it fall?          what it is good for
------------------------  -----------  --------------------  ----------------------
impressions               reach        only if you publish   sizing a channel
                                       less
followers                 reach        almost never          nothing operational
talk attendance           reach        room and slot decide  choosing events
newsletter subscribers    reach        slowly, on churn      list health
scroll depth to the end   engagement   yes, per piece        content quality
sample repo clones        engagement   yes                   which sample lands
questions asked after     engagement   yes                   whether it connected
first successful call     behaviour    yes                   activation
sandbox to production     behaviour    yes                   real adoption
support tickets per       behaviour    yes                   whether docs worked
  thousand developers

The middle column is the test. Follower count is cumulative and therefore monotonic, so it can never tell you that last quarter's work was worse than the quarter before, which makes it useless as a decision input regardless of how good it looks on a slide.

The reach tier is not worthless — you genuinely need to know your distribution — but it is an input you purchased, and reporting it as an outcome is what makes finance distrust the whole dashboard. The behaviour tier is the only one that answers "did developers do something differently".

The honest position on the behaviour tier is that attribution to your specific work is partial. That is survivable. What is not survivable is presenting reach as behaviour and being caught, because the credibility loss extends to the numbers that were real.

Stating it arithmetically is what turns a metrics discussion into a prioritisation one.

One month, self-serve API signups

signups                          4,000
created an API key                2,600   65% of signups
first successful call             1,400   54% of key creators
still calling after 14 days         520   37% of activated
production traffic                  180   35% of retained

Overall signup to production: 180 / 4000 = 4.5%

Biggest single loss: key creation to first call, 1,200 developers.
A 10-point improvement there = +260 activated developers/month,
which then carries through at 37% and 35%:
  260 x 0.37 x 0.35 ≈ 34 more production integrations per month.

The figures are illustrative; the method is the answer. Naming the largest absolute loss rather than the worst-looking percentage is the discipline, because a step with a poor rate and small volume is not where the developers are.

The second calculation is the one that wins arguments. Improving one middle step by ten points is abstract; thirty-four additional production integrations a month is a number a product owner can compare against their own roadmap items. Carrying the improvement through the downstream rates is also honest, because it shows you are not claiming that everyone rescued at step three reaches production.

What the shape tells you here is that the problem is not awareness. Four thousand signups against a 4.5 per cent completion rate means more marketing spend buys proportionally more failure, and the correct response is developer experience work on the auth-to-first-call gap, not a bigger campaign.

Not by attendance or applause. Usable signals are the number of substantive questions afterwards, how many of those turned into a logged piece of product feedback, measurable arrivals from a link you control and only published there, and recording views over the following year, which often exceed the room by an order of magnitude and are the reason recording matters. Set the expectation before you go: decide which of those you are trying to move, because a talk aimed at recruiting contributors and a talk aimed at activating developers are graded differently and cannot both be claimed afterwards from the same event.

It gives you a trend and an early warning. Sentiment usually degrades before adoption numbers do, because developers become frustrated for months before they migrate, so a falling sentiment score is a leading indicator that a lagging metric cannot provide. What it does not give you is a cause or a mandate: a score that fell four points tells nobody what to fix. It is therefore only useful paired with the free-text responses, which is the part teams skip because reading them is slow. The other limitation is sampling — the developers who answer surveys are not a random draw from the developers who use your product.

In three parts, labelled by evidence class. Behavioural outcomes with numbers and an honest note that attribution is partial. Costs that measurably did not occur: support tickets avoided after a guide shipped, integration hours a working sample replaced, both priced at rates finance already uses. And the counterfactual: what specifically stops if the programme stops, named as concrete things rather than as a warning about community. What loses the room is a revenue figure derived by assigning a share of new business to talks, because the assumption doing the work is visible and someone will pull on it, and the whole report goes with it.

Cohort comparison, stated as correlation. Compare developers who touched a specific piece of content against matched developers who did not, on a behavioural metric such as reaching a first call within a week, and report the gap across several cohorts rather than one. It is falsifiable, which is what makes it credible. Where the material is genuinely new, a deliberate holdout — delaying a guide for one segment — gets you closer to causal, at the ethical cost of withholding help. Neither produces a revenue number, and a candidate who claims one should expect to be asked how it was derived.

Time to first successful call, measured per step rather than as a total. It is the metric with the most downstream correlation, it is unambiguous, it cannot be inflated by publishing more, and it decomposes into a diagnosis rather than a score. Its weakness is that it says nothing about retention or about developers who never arrive, so it must not be the only thing you look at even if it is the one you would keep. The reason to prefer it over any community or content metric is that it is a property of the product, and it therefore forces the conversation towards fixes rather than towards output.

That you will inflate it, without deciding to. A team reviewed on published posts publishes more and thinner posts; one reviewed on event count attends more events with worse fit; one reviewed on community members buys a bigger, quieter server. None of that requires cynicism, only a review cycle. The defence is to negotiate at least one metric you cannot move by working harder — a behavioural or product metric — and to pair every output metric with a quality metric that would degrade if the output were padded. If a manager insists on output metrics alone, that is worth knowing about the role.

Reproduce it yourself first, because a report you have confirmed enters engineering as a defect and one you have relayed enters as a rumour. Then file it in the system engineering actually works from, with the minimal reproduction, the version, and what the developer expected — not in a message to someone you know. Attach whatever evidence of breadth you have, because frequency is what determines priority. Then tell the reporter what happened, including the ticket, and tell them again when it changes. The step almost always skipped is the last one, and it is the step that determines whether the next bug gets reported to you or posted publicly.

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

The branch at C is the part that makes the loop credible rather than noisy. A channel that escalates every individual complaint is filtered out by engineering within a month, so the "log it and wait" exit is doing as much work as the escalation path.

The G node has two outcomes and only one arrow out, which is deliberate. Reporting back when the answer is yes is easy and everybody does it; reporting back a decision not to fix, with the reasoning, is what establishes that the channel is real. It is also the harder internal conversation, because you have to extract an explanation honest enough to repeat in public.

What the diagram deliberately omits is any path from A straight to F. Advocates with good internal relationships take that shortcut constantly, and it works twice before their escalations start being discounted.

Complementary and explicit about the boundary. Docs own the reference and the systematic coverage; advocacy owns the narrative, the tutorial and the sample, and the two overlap enough that unstated ownership produces either duplication or a gap. The specific value advocacy brings is the evidence of what confuses people, gathered from the forum, the workshop and the friction log, which a docs team rarely has direct access to. The failure mode is advocacy publishing parallel unofficial documentation that then diverges from the real thing, which is worse for developers than the imperfect page it was working around.

Engineering, with advocacy as the loudest customer. An SDK is production software: it needs a release process, security patching, dependency updates and a support commitment, and none of those survive being owned by a team whose staffing is reviewed against content output. Where advocacy legitimately owns code is in samples and demonstrations, which are read more than they are depended upon. The distinction worth stating in an interview is that an abandoned official SDK is worse than no official SDK, because developers found it, trusted the badge, and are now on a silently lagging client.

With their metric, not yours. A product owner is generally willing to fund removing a friction point that provably costs them activated developers, because activation is their number too, and much less willing to fund an artefact because the advocacy team would like one. So arrive with the drop-off, the reproduction, and the estimated effect carried through the funnel, and be specific about the smallest fix that moves it. The second half is being willing to say what you will stop doing, since if everything you propose is additive you are asking for capacity rather than making a trade.

Correct it yourself, quickly, in the same place you said it. Developers accept that plans change; what they do not forgive is discovering the change independently and realising the earlier statement was left standing. Say what changed and, as far as you are permitted, why. Then do the internal work: find out how the public statement got ahead of the commitment, because the usual cause is an advocate repeating an internal aspiration as a plan, and the fix is a habit of only stating publicly what someone has committed to in writing. Repeated corrections destroy the credibility that made the role work.

The timeline is most of the answer, and shortening it is how goodwill is lost.

T-12 months  Announce. What is going away, what replaces it, why.
             Migration guide published the same day, not "coming soon".
T-9 months   Contact known heavy users directly. Offer help.
             Deprecation headers on responses from the old surface.
T-6 months   Migration progress by account. Chase the stragglers.
             New signups can no longer reach the old surface.
T-3 months   Scheduled brownouts, announced in advance, short.
             Remaining users now discover it in staging, not later.
T-0          Off. Old endpoint returns a documented error that names
             the replacement and links the guide.

Announcing without a migration guide on the same day is the single most common failure, and it converts a manageable announcement into a fortnight of hostility, because developers cannot evaluate the cost of the change and therefore assume the worst.

The brownouts are the part teams skip and the part that prevents the outage. Every deprecation has users who did not read anything and will only discover it when something breaks; a short scheduled brownout moves that discovery to a moment when someone is watching, rather than to the shutdown itself.

Direct contact with heavy users is not optional at any scale where you can enumerate them. It is also where you learn whether the replacement genuinely covers their case, which is a question the migration guide cannot answer and which occasionally moves the date.

flowchart TD
    A[Screen: why DevRel,<br/>and portfolio] --> B[Hiring manager:<br/>strategy and metrics]
    B --> C[Live talk or<br/>demo to a panel]
    C --> D[Technical depth<br/>with an engineer]
    D --> E[Cross-functional:<br/>product and support]
    E --> F[Written exercise<br/>or take-home]

The stage that surprises candidates is D. A DevRel loop almost always contains a genuine technical conversation, and it is graded on whether you can operate the class of product rather than on algorithms — read an API's docs and integrate it, debug a failing request, explain a system you built.

Stage C is the one people under-prepare in the wrong direction, by polishing delivery. Panels grade the choice of topic and the handling of interruption far more than the polish, which is covered below.

Stage F exists because most of the job is writing. A take-home is usually a short piece of technical content or a rewritten docs page, and it is read for accuracy and structure rather than flair.

dimension              strong                        weak
---------------------  ----------------------------  ------------------------
topic choice           a specific problem with a     a broad survey, or a
                       claim that can be wrong       product tour

technical accuracy     correct, and says the limits  fluent and slightly wrong

handling interruption  absorbs the question, adjusts stays on the script,
                       and continues                 defers everything to
                                                     the end

audience fit           pitched at the room it was    one register regardless
                       announced for                 of the room

recovery               names what broke, moves on    retries the demo, silent

The dimension candidates rehearse is delivery, and it is the one panels weight least, because polish is trainable and judgement is not. Interruption handling is weighted heavily and is rarely practised: panels frequently interrupt on purpose to see whether the talk survives it.

Technical accuracy is scored asymmetrically. A confident wrong claim is much worse than an acknowledged gap, because the panel is imagining you on a public stage saying it about their product.

Topic choice is the strongest single signal and is decided before you arrive. A talk about a specific problem you hit, including what you got wrong, is graded above a well-delivered survey of a technology every panellist already knows.

With questions first, then a diagnosis, then one thing you would do. An immediate plan signals that you would arrive with a template, and the answer that scores is the one that asks where developers currently talk about the product, what the answer rate and time to first response look like, and whether the product has any reason for developers to talk to each other at all. Then commit to a first action and say what evidence would make you abandon it. Naming what you would not do — launching a new chat server before there is organic discussion — demonstrates more than an enthusiastic list of tactics.

Three or four artefacts with outcomes attached, not a list of everything you have produced. A talk recording, a piece of writing that shows how you explain a hard idea, a sample or tool you built, and ideally one piece of evidence that your feedback changed a product. The outcome is the part usually missing: "this tutorial is the top result for the query and support tickets on that flow fell" is a different claim from "I wrote this tutorial". If you have a piece that failed and you know why, bring it — a candidate who can diagnose their own unsuccessful content is unusual and reads as someone who measures.

Two ways, symmetrically. The first is listing reach numbers as achievements, which tells the interviewer you have never had to defend a budget. The second, and the more common in experienced candidates, is the confident claim that DevRel cannot be measured and must be taken on trust, which sounds sophisticated and is how programmes get cut. The answer that works concedes that attribution of a specific developer's decision to a specific talk is not solvable, and then names what is measurable anyway: behavioural funnel steps, cohort gaps, support cost avoided. Specific and partial beats either extreme.

By going deep on something recent and real rather than broad on everything. Pick one integration you built or one problem you debugged in the last few months and be able to go three questions deeper than the summary — what the failure was, what you first assumed, why that was wrong. Interviewers are not testing whether you could pass an engineering loop; they are testing whether developers will take you seriously in a hallway, which requires operating knowledge rather than currency. The answer that fails is a broad tour of technologies with nothing underneath it, because the follow-up question finds the bottom immediately.

Assume both are true and find the gap, because that is nearly always where this resolves. Engineering measures availability at the edge, aggregated, usually excluding client-side timeouts, retries, and errors the developer caused but could not diagnose; developers experience p99 latency on their own traffic shape, ambiguous 5xx bodies, rate limits that trigger without a clear signal, and webhook deliveries they cannot confirm. A strong answer goes looking for a specific reproduction from a specific complainant, checks it against the metric engineering is using, and names the mismatch — per-account rather than aggregate, or the class of failure the dashboard does not count. It also handles the public side immediately: acknowledge that developers are hitting something, without conceding an outage that did not happen. A weak answer picks a side. It either becomes engineering's spokesperson explaining that the numbers are fine, which ends the community's willingness to report anything, or it amplifies the complaint internally as an outage and is discounted once the dashboards are checked. Both destroy the position the role exists to hold: being the one person who can see that the measurement and the experience are different things, and say so in both directions.