What dev heck?

February 09, 2022 | 17 Minute Read

There are a lot of publications explaining how crucial DevRel (Developer Relations) and DX (Developer eXperience) are for software vendors. It seems more, and more of them establish such teams. The goals they hope to achieve probably vary a lot. Yet, according to the 2021 edition of State of Developer Relations report, most often, such teams report to marketing. Is DevRel a fancy name for developer-focused marketing then?

There are also plenty of posts about what the Developer Evangelist and Developer Advocate roles are about. One can sense the struggle to convince others that those are actual professions and need to be appreciated as such. There is always (at least indirect) relation to revenue generation. It’s like those folks feel guilty that what they do, does not directly translate to dollars or euros. I can’t help but wonder why that is. I mean, do you know an HR professional or an accountant worried that their work does not generate revenue?

So this post is my take on the whole DevRel, DX, Evangelism, Advocacy, … thing. I’ve spent over 10 years on the field and have a “strong” opinion that I want to share with you. That does not make me right about any of it. My experience shaped my opinion. I understand yours may be completely different, so you are more than welcome to disagree with me.

TL;DR

No worries. Feel free to jump to the summary section at the end!

Developer Evangelism

That was the first term that I encountered. It was back in circa 2002. I attended an event organized by Microsoft, and I met a few friendly and knowledgeable folks representing the company. Later on, I discovered they were “Developer Evangelists”. A red light went on in my mind. The friendly and knowledgeable adjectives were quickly replaced by seductive and sneaky.

Developer evangelism in an extrapolation from the original term related to Christianity. It is about preaching, announcing, or otherwise communicating the value of a specific software product. Putting it this way, I can fully understand why it is considered important from the vendor’s perspective. But as with the original term, there is a thin line between praising something and proselytizing the audience. And the difference is in the eye of the beholder.

A title can completely change the perception of a message or the intention of a conversation. A title always puts those in context. It is irrelevant whether the context is adequate. The interlocutor will most likely subconsciously adjust its boundaries, filters, and alert sensors accordingly. That is why I really don’t like the term, and I’ve always rejected to use that title myself.

Developer Advocacy

Masquerading the above under a not-so-obvious title? Yep, I hear that a lot. In fact, I used to think that myself years ago. Perhaps that was the intention when it was introduced. I have no idea how it came to be, but I can picture a brainstorming session aiming to replace “evangelism” with something embracing praising but free from proselytizing accusations.

Once freed from the negative connotation, though, the term has evolved somewhat surprisingly. It has a double meaning which ironically makes it more accurate. To describe those, I like to use two of the definitions of the word “advocate” from the Merriam-Webster dictionary:

one who defends or maintains a cause or proposal

That is the outbound direction. The modern successor of evangelism. Advocates build a case of the product and defend it. They don’t expect developers to change their preferences and habits. They demonstrate how to achieve better results. They provide appealing evidence that supports the case. They understand well the strengths and weaknesses of the thing they defend and its applicability in different scenarios. Building trust and maintaining credibility are crucial for this role.

That is the part of the role that management, marketing, and sales appreciate as it can be indirectly connected to revenue generation.

one who pleads the cause of another

That is the inbound direction. The acknowledgment that the community gathered around the product has a say. Advocates plead the cause of the community to the respective product management and engineering teams. They discuss various issues, ideas, and suggestions community members have. They try to understand their experience, expectations, and reasoning. They may pre-evaluate or even prototype some of them. Having strong technical expertise is crucial for this role.

That is the part of the role that product management, engineering, and advocates themselves appreciate most as it contributes to better products.

Community

‘When I use a word,’ Humpty Dumpty said in rather a scornful tone, ‘it means just what I choose it to mean — neither more nor less.’

Community is an awfully overloaded word. You can pick and choose a meaning that suits you. I like to think about it as the outcome of a social categorization and grouping process. It’s well described by the social identity theory developed by Henri Tajfel and John Turner back in the 1970s and the 1980s. It represents the “us” part of the “us != them” equation. Note that the “them” part is equally important - there is no “us” (in-group) without “them” (out-group). There must be something shared by all members but not shared by others.

Belonging to a community is a matter of free will and acceptance. One must first self-identify as a member and then be accepted (in the sense of not being rejected) by other members. Abandoning a community is a matter of free will alone. No one owns the community. No person or organization can singlehandedly build a community. Some members provide more incentives or amenities than others, but that does not make them owners or managers.

“Managing” a community

While developer communities are a natural phenomenon, many software vendors started to see huge potential benefits in claiming and owning one. Yes, one. They realized they could use our community like some sort of a loyalty program! So they started to invest in an infrastructure that provides all the crucial things a community needs to function. And then, they appointed a dedicated community manager. Usually someone from the marketing team.

To be honest, I don’t know what native English speaker pictures when they hear the word “manager”. Perhaps just a person who manages various things. But in the other two languages I speak, the word clearly appoints a role in the organization’s reporting chart. My experience shows that sooner or later, executives expect community managers to treat the community in one of the following ways:

as part of the organization

A low-cost work force. Or a department of volunteers, if you will. It’s that mindset behind every “Let’s ask the community to do this for us!” request.

as a waiting room for future customers

A group of potential customers who are not yet ready to buy. It’s that mindset behind every “We need to highlight the value of our paid products/services!” discussion.

An interesting observation regarding the above perspectives is how the line between the in-group and out-group shifts from “the things we have in common” to “the benefits we can have”. But the benefits are not the same for everyone. So when such an attitude becomes apparent (trust me, it always does), the natural social categorization and grouping are tampered, and the community starts to self-dissolve. Ironically, the only way to “manage” a community is to resist the temptation to do so. I personally like the term “fostering a community”. But since I’ve never heard of a “Community Fosterer” role or job title, I’ll keep using the widely accepted term throughout this post.

Developer Relations

Years ago, the Community Manager left the company I worked for at the time. Being unable to find a new one, the executives called a “how to manage our community” meeting. As one of the informal Developer Advocates, I was invited to attend. We came up with what we called CAT (Community Action Team). The idea was to have a formal body responsible for managing and growing the community. To ensure everyone’s interest is equally represented, the body would consist of people from the company and the community. I was asked to bring the idea to life, and I started working on it. Shortly after that, I went on vacation, and when I came back, I was surprised to learn that CAT is no longer a thing, we have a newly formed DevRel team, and I’m part of it.

Now, if you think defining community is hard, try finding a proper definition for DevRel. I’ve been searching for a description that fits my experience, and I couldn’t find one. After thinking about it a lot, I decided it’s probably best, to put it bluntly. It’s that box in the organization’s chart where Developer Advocates and Community Managers belong. Often, it is as simple as that - formalize a department within the organization. From the executives’ perspective, that makes a lot of sense. Now that there is a formal unit, it is possible to assign tasks, set targets, and apply metrics.

DevRel is an idea based on the same combine-two-skillsets principle that DevOps was born from. In theory, experienced developers with good social skills and a basic understanding of marketing should be good Developer Advocates. While marketing/PR folks with solid technical backgrounds should check up as Community Managers. In practice, things vary a lot. I’ve seen a DevRel being a re-branded marketing department. I’ve seen a DevRel label stuck to a group of software engineers who have to write blogs and speak at events in addition to what they usually do. And I’ve seen well-thought-out DevRel teams that really rock.

There is another way in which DevRel shares DevOps’ destiny. Some notable consulting agencies seem to push hard on the idea that establishing a DevRel team will bring a company to the next level, increase adoption, strengthen brand loyalty, improve the free to paid conversion ratio, etc. They conveniently don’t attach a time frame to those claims, letting executives put unrealistically high expectations on their DevRel teams.

One of the critical factors when planning a DevRel team is the target audience of the products or services. If there are no developers involved, there is, technically speaking, no need for Developer Advocates. There still may be a need for fostering communities, though. If there are developers involved, the question is to what extent? Some software products (like APIs, frameworks, servers, etc.) are meant for developers. Others (like ERP software, online platforms, games, etc.) are intended to serve the general public but may have areas (for connectors, extensions, plug-ins, customizations, etc.) that involve developers. That ratio should determine the team’s structure, size, and priorities. The way I see it, there are three possible scenarios:

Community team

The best approach when the product is targeted solely towards end-users. Foster a community of happy users that can help each other and spread the word about your awesome offer.

DevRel as part of the Community team

Applicable when the developer-related surface is minor. Similarly, the main priority is to foster a happy and supportive community of end-users. But there is added value in attracting and supporting 3rd party developers, partners, extensions, etc. The structure makes sense because everything the DevRel team does contributes to the overall community value in this case.

Community as part of the DevRel team

The way to go when the company’s offering is primarily targeted at software developers. The focus, in this case, is 100% on ensuring the greatest possible developer experience. Developer Advocates play a crucial part here, fully utilizing the inbound and outbound channels discussed earlier. Naturally, software developers form a community around the product or service. Thus having community programs, recognition, awards, etc., is a nice add-on. Keeping an eye on and fostering other communities (around languages, concepts, techniques, etc.) helps understand developers’ needs and habits better. But overall all community fostering activities contribute to providing excellent developer experience.

Developer eXperience

And so we have arrived at the newest kid on the block - Developer eXperience. It is such a hot topic that sometimes the number of DX experts among my social media contacts is growing with every hour. I’m not one of them, but Zeno Rocha, a former colleague of mine and (at the time of writing this) VP of Developer Experience at WorkOS is. This is how he defines it:

DX is the sum of all micro-interactions that a software engineer has with an API, framework, library, or internal tool.

It’s hard to argue with that statement, although I think there is more to it. Like the not-so-micro interactions with the people behind the product or other community members. Or the ability to find demos and samples for various use cases. Or the size and condition of the given product’s ecosystem. There is probably a lot more.

But when you put it that way, it brings the question, isn’t DevRel supposed to provide the much-desired awesome user experience? Well, I think the answer is “not really” for at least two reasons.

First, Developer Advocates (or anyone by themselves for that matter) can not provide an experience. They can contribute to it, but the overall experience is a result of the work of many people. Even the best of us can not compensate for poorly written code, lacking features, overcomplicated APIs, business decisions restricting access, broken processes, etc. At least not without introducing extra abstraction layers or bending the rules. In that context, having a DX team indicates that developers’ experience is essential for the company. It’s is not the role of the DX team to provide it. It is to ensure everyone involved in the process takes it seriously. It’s about spotting developers’ frustrations, identifying what is causing them, and working with other teams to remove or minimize them.

Second, a vast area significantly impacting the developers’ experience is largely neglected by DevRel teams - namely Developer Education. I’m OK with stating that because blogs, conference talks, demos, etc., are not educational activities as far as I’m concerned. I am aware many DevRel teams have technical writers responsible for product documentation. Some larger organizations have dedicated teams working on courses, training, and even books. I’m not suggesting restructuring those but rather that the learning experience is part of the developer experience. Whoever is responsible for designing and implementing the learning experience must consider it in the broader scope of Developer eXperience.

Developer Education

To my surprise, there is not a lot of buzz around developer education. It’s almost like everyone takes it for granted. Meanwhile, it is a complex area requiring quite some expertise. I’m by far not an expert in that field, but I’ll share with you some of the key factors to take into account.

Starting point (prior knowledge and experience)

Whatever the assumption is, it is wrong. Not everyone needs “Hello world”, but not everyone knows the “basic concepts”. Not everyone knows the frameworks and tools required, but no one wants to scroll over things they already know to find the significant bits. The best approach is not to assume. Observing what people search for and can’t find, what they skip, complain about, etc. can help build targeted learning paths.

Learning material formats

Some people prefer to read. Other to watch videos or listen. Some can not learn without interactive exercises and having a teacher/trainer checking their work. The formats also come with varying attention spans that one needs to consider. There is no one format fits them all approach.

Outdated vs. relevant knowledge

The only constant thing is change. Products evolve, and knowledge important yesterday can be obsolete and misleading today. On the other hand, people don’t always catch up with the product. Some may still need to learn about an earlier version of the product. The more mature the product is, the more complex it becomes the manage the education effort.

Knowledge assessment and certification

It may seem that creating a test or a quiz is easy. But doing it in a way that reliably indicates something is very hard. There is a reason why certification authorities exist. Whether or not such authority needs to be involved in the knowledge assessment process depends on many factors. Either way, the quality of the process (or the lack of one) impacts the learning experience.

The above is far from an exhaustive list. But hopefully, it is enough to illustrate how developer education can improve or ruin the developer experience.

Summary

Developer Evangelism and Evangelists

are things from the past. While some of those units and titles are still around, I expect them to migrate to advocacy sooner or later.

Developer Advocacy and Advocates

are the industry-wide accepted terms. Those are the folks who promote and defend products and ideas but also plead the cause of the 3rd party developers. The double meaning of the word “advocate” nicely highlights the fact it’s a two-way street.

Community Management and Managers

are here to stay. The idea of managing people without having any formal relationship with them is an awkward one if you ask me. But no one else seems to be bothered by that. In reality, those folks probably do not manage the community itself but rather the tools, processes, and programs that improve operations and interactions.

Developer Relations

is the industry-wide accepted term for a given part of an organization where the roles mentioned above belong. It allows grouping, coordinating, and measuring the results of all advocacy and community-related activities.

Developer Education

is focused on providing the best learning experience to 3rd party developers. The primary goal is to flatten the learning curve as much as possible for as many people as possible.

Developer eXperience

is kind of an umbrella term for all of the above. It groups all specific goals into one uber goal - ensure developers have the best possible experience when interacting with the product or its surroundings.

My next post, titled “From DevRel to Developer eXperience” is about how those views shaped the structure of an actual team in the company I work for.

Why dev heck?

I’ve spent quite some time clarifying and organizing my thoughts on all those topics during the last few weeks. For what it’s worth, I thought I’d share them publicly. I hope you found them helpful or at least interesting. As always, your feedback is more than welcome.

Whatever your take on DevRel, DX, community building, or any of the related matters, I hope you’ll have many satisfied users and excited developers.