Vocabulary for Developer Relations Professionals

Developer relations — often abbreviated as DevRel — is the practice of building and nurturing relationships between a company and its developer community. DevRel professionals work at the intersection of engineering, product, marketing, and community. This guide covers the core vocabulary you need to communicate effectively in a DevRel role.

Developer Experience (DX)

Developer experience (DX) refers to how developers feel when using a product, API, SDK, or platform — the ease of getting started, the quality of documentation, the clarity of error messages, and the overall productivity the tool enables.

“Our developer experience survey showed that the main pain point was unclear error messages. Developers couldn’t tell whether they had misconfigured the SDK or hit a known bug.” “Good developer experience is like good UX, but the user is a developer. Every unnecessary step in onboarding is a conversion we lose.”

Adoption

Adoption in DevRel refers to the uptake of a product, API, or SDK by developers. It is typically measured through registrations, API calls, active integrations, and community growth metrics.

“Adoption of the v2 API has been strong — over 3,000 active integrations within three months of launch.” “We identified that adoption dropped off after the initial sign-up. Developers were registering but not completing the ‘Hello World’ tutorial. That is where we focused our improvement effort.”

Champion

A champion (or developer champion) is a developer within a company or community who actively advocates for your platform, speaks about it at events, writes about it, and influences colleagues to adopt it.

“We have six external champions who have each built public projects using our API. They amplify our reach far beyond what our internal team can achieve.” “Champion programmes typically include early access to new features, direct channels to the product team, and support with conference talks and blog posts.”

Evangelism

Evangelism (sometimes called developer advocacy) is the practice of promoting a technology — through talks, demos, tutorials, social media, and community engagement — with the goal of increasing awareness and adoption.

“Developer evangelism is about creating genuine enthusiasm, not running sales campaigns. Developers can tell the difference.” “Our evangelism strategy focuses on showing, not telling — live demos, open-source sample projects, and step-by-step tutorials that solve real problems.”

Feedback Loop

A feedback loop in DevRel is the process by which developer input — pain points, feature requests, confusion, and praise — is captured, prioritised, and fed back to the product and engineering teams.

“The feedback loop between our community and the product team is what drives our roadmap. We hold a monthly sync where I present the top ten developer complaints and requests.” “A fast feedback loop is a competitive advantage. If developers know that their feedback leads to action, they engage more openly and honestly.”

Friction

Friction refers to anything that makes it harder for a developer to get started with or use a product — complex authentication, poor documentation, confusing error messages, excessive required fields, or slow API responses.

“We reduced onboarding friction by replacing our three-step API key setup with a one-click sandbox environment. Time to first successful API call dropped from 45 minutes to 8.” “Every point of friction in the developer journey is a potential drop-off. We map the full journey and prioritise removing the highest-friction steps.”

Onboarding

Onboarding in DevRel refers to the process of getting a new developer from zero to their first successful use of your product — ideally as quickly and smoothly as possible. The “time to first hello world” (TTFHW) is a common metric.

“Our onboarding flow has three steps: create an account, generate an API key, run the sample code. Each step has a short video and a copy-paste code snippet.” “We redesigned onboarding based on session recordings. Most drop-offs happened at step two — the API key page was confusing about which key to use for the sandbox.”

SDK (Software Development Kit)

An SDK is a collection of libraries, tools, documentation, and sample code that developers use to build against a platform’s API. A well-designed SDK abstracts API complexity and handles authentication, error handling, retries, and serialisation.

“We publish SDKs for Python, JavaScript, Java, Go, and Ruby. The Python SDK has over 40,000 weekly downloads on PyPI.” “A great SDK is invisible — developers use it without thinking about how it works. A poor SDK forces developers to read the source code just to make a basic call.”

Developer Advocacy

Developer advocacy is the practice of representing the interests of the developer community within a company — ensuring that developer needs, pain points, and feedback influence product decisions.

“My role as a developer advocate has two directions: outward-facing (helping developers succeed with our platform) and inward-facing (bringing developer feedback to the product team).”

Practical Phrases for DevRel Professionals

• “Adoption is lagging because there’s too much friction in the onboarding flow. We need to get time-to-first-API-call under ten minutes.”
• “Our champion programme has been the highest-ROI initiative this quarter. Champions produced twelve blog posts and four conference talks.”
• “The feedback loop tells us that error messages are the top pain point. That is where engineering should focus next.”
• “Developer experience is not a soft metric — it directly correlates with adoption, retention, and word-of-mouth.”
• “Evangelism works when you are genuinely solving problems for developers, not just promoting your product.”

DevRel vocabulary reflects the unique blend of technical depth and community-building that defines the role. Mastering these terms will help you communicate the value of DevRel to business stakeholders, collaborate effectively with product and engineering teams, and build genuine relationships with the developer community your company depends on.

Bridging the Gap: Language Support for Non-Native Developers

The world of Developer Relations is increasingly global, and that means our audience reflects a huge range of linguistic backgrounds. While fluency in English is often assumed, many developers coming from other countries are rapidly developing their professional communication skills – and this extends far beyond just writing code. Understanding the nuances of technical vocabulary, especially when crafting clear and persuasive messages, can be a significant hurdle. It’s not simply about translating words; it’s about conveying intent, tone, and context in a way that resonates with an international audience, particularly those still building their English proficiency. For non-native speakers, mastering phrases related to collaboration, feedback, and strategic communication is crucial for effectively contributing to developer communities. Focusing on active voice, avoiding overly complex sentence structures, and understanding the subtle differences in how concepts like “optimization” or “scalability” are perceived across cultures can dramatically improve clarity and acceptance. Furthermore, recognizing that direct translations often fall short – a technical term might have multiple interpretations depending on regional usage – is essential for building genuine connections.

Let’s consider a common scenario: a code review comment. Imagine a developer from Japan responding to feedback on a pull request. A direct translation of “This function could be more efficient” might not land well. Instead, phrasing it as “Could we explore optimizing this function’s performance?” or even better, “I noticed some potential bottlenecks here; let’s discuss how we can improve the efficiency of this section” demonstrates awareness and invites a collaborative discussion rather than sounding like a criticism. Similarly, in Slack conversations discussing adoption rates, saying something like “We need to address the friction points users are experiencing during onboarding” is more effective than simply stating “Onboarding needs improvement.” The latter lacks context and doesn’t invite solutions. Building a vocabulary around proactive problem-solving – identifying challenges (“pain points”), proposing solutions (“mitigation strategies”), and soliciting feedback (“gathering user insights”) – is key to successful Developer Relations.

Another frequent situation involves writing PR descriptions for new SDK releases. A developer from Germany might struggle with the phrase “driving adoption” - it sounds almost marketing-centric. Instead, a more neutral and informative approach would be: “This release expands the SDK’s functionality, offering developers enhanced capabilities to integrate [product name] into their applications.” Focusing on what the release does, rather than how it will be used by others, can reduce ambiguity for those less familiar with the English-language promotional rhetoric. It’s about shifting from advocating a concept to describing a feature and its benefits in a clear, factual manner.

# Example: Using `git diff` to highlight changes in a pull request description
git diff --cached --summary

This simple command demonstrates the core of effective communication – clearly outlining the modifications made within the code. Focusing on precise technical descriptions like this can build confidence and reduce misunderstandings, especially when collaborating across language barriers.