There's a lot of debate about the proper terminology for what we currently refer to as "DevRel." Many folks are happy with this terminology, but I and others don't think DevRel (developer relations) is a broad enough term to represent what our field has become over the last half-decade.

You might not think this is an important thing to focus on. However, I would argue that the recent confusion around what DevRel is and the job descriptions that have the swiss army knife of responsibilities on them are clear indicators that we're not defining things well enough.

Imagine if the content we created to describe an API or product used one term to define many things. Yet, that's what we do for our field. Our field of practice is new, and new things need precise terminology and definitions.

A Modern Definition for Developer Experience

To start the conversation, I'd like to reference one of the definitions of the word experience found in the dictionary.

An event or occurrence that leaves an impression on someone.

That's an interesting statement. An experience is an impression, positive or negative, left on a person after some event or occurrence. 🤔

We're talking about the developer experience, so let's adjust the definition to account for that.

An event or occurrence that leaves an impression on a developer.

Okay, so now we're dealing with developer experience, but there is still a missing piece.

Whenever we think about developer experience, we're generally not concerned with all of their experiences. Instead, we're worried about their experiences within a given ecosystem, regardless of whether or not that ecosystem focuses on a community (an open-source project) or a company (using their platform). So, with this context in mind, let's make one final adjustment to the definition.

An event or occurrence within an ecosystem that leaves an impression on a developer.

Said another way, no matter what a developer is doing within your ecosystem, it's all part of the developer experience. Yet, that's not what most definitions of DX would lead you to believe. Often DX is scoped down to either: the happy path of onboarding for a tool or service or engineering work related to integrations and abstractions to make development with a given platform easier.

Narrowly scoping developer experience to top-of-funnel and integrations doesn't match with this definition. Add up enough positive or negative impressions, and people will start talking about what has left such an impression on them, regardless of where they had those experiences.

Only addressing negative impressions isn't enough. Actively work to make all events or occurrences a developer has within your ecosystem as delightful as possible. A bad impression is worse than no impression, but you need a positive impression to get people talking.

We [user experience] Were Here First

In the 90s, Don Norman and a few others created the first UX team at Apple. While everyone focused on the experience with Apple products, they were focused on the experience around Apple products.

Hearing him speak about UX, you can draw a connection to this new definition of DX.

Developer Experience and Developer Relations

So now that we've defined developer experience, it's time to examine what that means for developer relations (DevRel). Currently, DevRel is the umbrella term most people use to define what I've described as developer experience. For example, anything related to positive impressions on developers gets bucketed under DevRel. However, because developer relations focus on relationships between company and community, that term is too narrow to encompass all events or occurrences that a developer may have in an ecosystem.

Suppose a developer finds their way to your ecosystem and has a poor experience trying to accomplish something. In that case, it's still a poor experience even though there is no relationship between the developer and the company.

Developer Relations is about building internal and external relationships to remove friction from developers' workflows (or create positive experiences). Which also ties in perfectly with our new definition of developer experience.

For a clear definition of developer relations, check out "What is Developer Relations" by Mary Thengvall.

DevRel is working in service to DX and does not have the proper definition to match the responsibilities we see in our field today, which is why I believe the term is no longer sufficient to be the larger umbrella.

Why Does It Matter?

Words have power. If we use the wrong vocabulary to define our field, it will continue to confuse others. Aside from confusing others interested in learning about the field, it is also confusing companies. Most companies use the responsibilities of one or two roles within the DevRel umbrella to decide where that function should live within an organization.

For example, suppose all of the responsibilities of a marketing org were defined by only the product marketing responsibilities. In that case, a company might think the best place for that function to live would be within the product org. This makes sense when you narrowly scope marketing responsibilities down to product marketing, but in reality, a marketing org does a lot more.

So when we use the term DevRel to define what Developer Experience is, we're telling everyone that our responsibilities are more narrowly scoped than they are. That will always create confusion and misalignment on what value DX brings.

Conclusion

Developer experience is a more accurate umbrella term than developer relations because it encompasses more responsibilities generally bucketed under DevRel. Aside from that, by its very definition, DevRel is working in service to developer experience.

Our field of practice is new, and new things need precise terminology and definitions. Using the wrong language creates confusion for people trying to enter the field and companies trying to build out successful developer experience functions.