Introduction — DevRel Is the Change Interface

Two launch meetings

Composite. Built from recurring patterns; no identifying detail.

Two launch meetings happen the same quarter, in companies of similar size, about products of similar complexity.

In the first, developer relations shows up to receive a brief. There’s a launch date, a slide of pre-approved claims, and a request for a keynote, a tutorial, and a social push over the following two weeks. Someone asks whether anyone outside the team has run the quickstart. Documentation, it turns out, is tracking that separately. The meeting ends on schedule. The plan is complete, and nothing in it is capable of changing the product.

In the second, developer relations shows up carrying evidence: three screen recordings of people stalling at the same onboarding step, six weeks of support tickets asking the same authentication question, a sample app that only runs after a workaround nobody had documented, and a list of questions the community had already asked in public. What follows is not a content calendar but a sequence — publish the detection command first, hold office hours across three time zones, name an owner for the cases nobody can yet resolve. The meeting runs long, and two things in the product change before the week is out.

Both of these get called developer relations. Only one of them is doing the job. The difference isn’t budget or talent. It’s whether the function is wired to move information in both directions, and that wiring is what this book calls the change interface.

Activities describe means, not change

Ask ten teams to define developer relations and most answers come back as a list: content, events, community, social, sometimes docs or sample code. Every item on that list can be genuinely valuable — a talk can reach the one engineer who needed permission to try something, a sample repository can save a team a week. But the list describes what the function does, not what it’s for.

“We publish two posts a week and speak at six events a year” is a statement about throughput. It says nothing about whether anyone can now do something they couldn’t before, whether they can do it safely, or whether the product improved because they tried. Throughput is also comfortable to plan around: it fills a calendar, maps onto job titles, and produces numbers a leadership deck can hold. Programs settle into this pattern quietly, busy and well-documented and stalled, until someone asks what the function actually accomplished and the only honest answer on hand is volume.

A better default is to write the intended change before choosing the activity. State what’s different afterward, name the constraint making it hard, decide what proof a skeptical developer would need, and say where their pushback will go. Only then pick the talk, the guide, or the working group. It’s a small reordering, but it’s the one that keeps a keynote from being scheduled before anyone has asked what it’s supposed to change.

A relationship has to be able to change you back

Here’s a blunt test for whether a program is a relationship or a distribution channel with a friendly voice: can field evidence alter your roadmap, your defaults, your deadline, your documentation, or your policy — or only the developer’s opinion of you?

Developers work this out fast. They notice which questions get answered and which get restated back to them as talking points, which reports produce a fix and which produce a thank-you. Mary Thengvall’s The Business Value of Developer Relations is useful here because it refuses the atmosphere framing outright. It treats developer relations as connective infrastructure between the people who build a product and the technical communities depending on it — a function with defined stakeholders and reciprocal obligations, the same as sales or support. Once the work is described that way, “what did the organization learn this quarter” becomes as fair a question as “how many developers did we reach.”

That gives a plain three-way diagnostic. A program that changes only the outside is promotion: developers adopt, the organization learns nothing, and the same friction gets rediscovered next quarter. A program that changes only the inside is research: sharp insights the community never feels. A program that keeps both sides moving is developer relations, and the distinctive value sits in that connective work rather than in the content or the events, which any function can produce.

The seven moves

The book’s model is one loop, run continuously rather than completed once: Listen, Frame, Prove, Enable, Convene, Learn, Reinforce — and back to Listen. Each move answers a question the developer is already asking, whether they say it aloud or not.

Listen answers “Do you understand the problem I actually have?” You observe work, language, and prior failure. Progress looks like the problem stated in the developer’s own words and confirmed from more than one source.

Frame answers “Why should this matter to me?” You lay out the stakes and the tradeoffs without inventing urgency. Progress looks like people repeating the reason back to you, including the parts they don’t like.

Prove answers “Can I check this myself?” You make the value and the limits both observable. Progress looks like someone outside your team reproducing the result and finding its edge.

Enable answers “Can I succeed without knowledge only your team has?” You cut friction from first contact to a real outcome. Progress looks like falling time-to-success alongside failure points that are now visible enough to fix.

Convene answers “Can I help shape what happens next?” You build participation with actual influence attached. Progress looks like peer help, repeat contribution, and ownership spreading beyond your team.

Learn answers “Will anything change because I said something?” You route, decide, and publish the outcome. Progress looks like a growing share of feedback closing with a decision or a dated checkpoint.

Reinforce answers “Will this still be supported next year?” You sustain the capability and the memory of why it exists. Progress looks like retention and stewardship that don’t depend on one person staying in the role.

Take a concrete case: moving developers off a v1 API. Listen is interviewing the three teams still on v1 to find out why — usually a proxy, a code generator, or an approval process, rarely inertia. Frame is publishing the reason v1 can’t be patched in place before any deadline goes out. Prove is a repository that runs one workload against both versions and prints where the behavior actually diverges. Enable is a detection command, a tested rollback, and office hours at times your users can attend. Convene is a working group with real authority over the readiness checklist, not a comment box. Learn is a tracking issue that names the unresolved cases — the custom proxies — with an owner and a date. Reinforce is the deprecation policy you publish afterward, so the next removal is a known rule instead of a surprise.

The loop isn’t a schedule, and the moves don’t run in strict order. You’ll be back in Listen halfway through Enable, and Prove will occasionally reveal that your Frame was wrong. When a change stalls, ask which move is missing — not whether you’ve shipped enough content.

Where developers actually are

The loop exists to serve something that happens inside people, not inside your plan. Seven states cover most of it: skeptical (“this might be hype, or extra work I didn’t ask for”), oriented (“I understand the proposal and its tradeoffs”), trying (“I can test this without risking anything real”), successful (“I got a real result, and I can tell it’s correct”), repeating (“this works in my context, not just the tutorial’s”), contributing (“I can improve this or help the next person”), and stewarding (“I carry some responsibility for keeping this alive”).

People skip states, reverse them, and hold several at once. A staff engineer can be stewarding one part of a platform while entirely skeptical of the module you just shipped, and one unexplained breaking change can send a room from repeating back to skeptical by the end of the afternoon. Trust isn’t one of these states — it runs underneath all of them, which is why the first chapter takes it up before anything else.

Locate people honestly before picking a tactic. A tutorial aimed at someone still stuck on skeptical is wasted, because their real question is about the reason and the risk, not the syntax. Most disappointing DevRel work is a well-made artifact aimed at the wrong state.

Three questions before any tactic gets funded

State: what belief, capability, behavior, or system should be different afterward? “Awareness” isn’t an answer unless you can say what someone will do or decide differently because of it.

Reciprocity: what does the developer or the community keep? Learning, recognition, access, influence, and leadership all count; exposure doesn’t. If the honest answer is that the organization benefits and the participant gets a sticker, you’re designing extraction, not participation.

Evidence: what signal would tell you this moved something, and what would tell you it didn’t? A tactic you can’t be wrong about can’t teach you anything either.

A tactic that fails one of these isn’t forbidden, just unfunded — put it in a backlog with the missing answer next to it. That’s also the useful move in a meeting like the first one above: not refusing the keynote, but asking what state it changes, what the audience keeps, and how you’d know.

How to use this book

Read straight through and the arc runs from your own conduct — trust, explanation, proof, in Chapters 1 through 3 — to the developer’s capability — first success, participation, disruptive change, in 4 through 6 — to your organization’s capacity to learn — feedback, alignment, evidence, scale, in 7 through 10.

Or arrive with a problem and start there: low trust points to Chapter 1, confusion to Chapter 2, disbelief to Chapter 3, onboarding failure to Chapter 4, a passive audience to Chapter 5, migration conflict to Chapter 6, ignored feedback to Chapter 7, internal dysfunction to Chapter 8, weak evidence to Chapter 9, hero dependency to Chapter 10.

Every chapter studies a public artifact for its mechanics, not its author — a repository, a policy, a framework — and says plainly where copying it would fail. The point is a transferable method, not admiration.

Field tool: the one-page change definition

Fill this in before planning a launch, a migration, a documentation rebuild, or a community program. It should fit on one page, and a blank line is your first piece of work, not a formatting problem.

1. What’s changing — the old state and the new one, specifically.
2. For whom — named segments and versions, not “developers.”
3. What’s true today, and what evidence backs that.
4. What should be different, stated as capability or behavior, not awareness.
5. What the developer keeps — the reciprocity answer, from their side.
6. What they can inspect — the artifact, and the boundary it discloses.
7. How they can push back — the route, the owner, and what’s genuinely still open.
8. What has to change inside the organization, and who owns each part.
9. Two to four signals that would show movement, and one that would show gaming.
10. What could make this coercive — cost shifted onto users, unpaid labor requested, a deadline nobody tested.

Read lines 5, 7, and 10 aloud to someone outside your team; they expose extraction fastest. Then check line 8. A change definition with nothing written there is a broadcast plan with better formatting.

Measure it

Before any single tactic: the share of initiatives with both an external and an internal state change written down, the share of field evidence that reaches a named owner with a decision or a date attached, and the number of product or policy changes traceable to community evidence this quarter.

Countermetric: output volume. More posts and more talks tell you the function is busy. They don’t tell you it’s connected.

Next

The loop starts with listening, but developers decide something earlier than that: whether you and the system behind you deserve their attention at all. That judgment gets made from evidence, and it can be audited — which is where Chapter 1 begins.