DevRel - Developer Relations - a scientific perspective

Hey, how are you? First of all: I’m Awdren Fontão and not Andrew/Andrei :). I’m from Manaus, but I live in Campo Grande (MS) - Brazil 🇧🇷

I’m a professor and researcher at UFMS, and I have a PhD thesis in DevRel (Developer Relations) with a research group focused on this area. I also worked in the industry as a developer evangelist for five years.

The idea of coming here is to share content about DevRel with the community. And it will be scientifically based DevRel content. The content includes research results from the group I lead.

This first part of the material is about the concept of DevRel.

📝 How this text is organized:

• Some highlights;
• The concept of Ecosystem;
• How the DevRel area emerges;
• The concept of DevRel (including explanations based on etymology);
• How some organizations are using the area;
• A list of upcoming posts;
• References used.

Some highlights:

1. DevRel is an organizational area, not a profession. It aims to establish synergy between developers’ experiences and organizational goals. You can be an evangelist, advocate, or DevRel professional, among other roles;
2. DevRel heavily depends on the local/regional culture, so studying the feasibility of strategies is always important;
3. DevRel develops around actions, services, and products for developers;
4. Based on etymology, we are talking about relation, not relationship.

A brief chat about Ecosystems

Organizations like (to name a few): Amazon, Apple, Canonical, Facebook, Google, Nintendo, and Microsoft invest in an environment to engage software developer communities. Here, a developer is anyone involved in Software Engineering disciplines, such as testing, UX, architecture, configuration management...

The mentioned environment involves complex dynamics of cooperation and competition among communities (which consume and generate resources), value creation networks, and energy flows. This can help organizations, among many other benefits, in developing and evolving contributions around their products, services, or platforms. This context has been studied as a software ecosystem, indeed an analogy with ecological ecosystems. And you may have heard in a meeting or lecture, that someone mentioned the organization’s “ecosystem.”

Engaged communities promote the ecosystem, providing relevant feedback for pillars (robustness, niche creation, and productivity) that sustain a competitive ecosystem. Community engagement leads to complementing the value that organizations offer to their stakeholders. Organizations depend on the ecosystem because the platform’s attractiveness and its products are determined by the frequent evolution of their software offerings.

DevRel area emerges, not DevHell

There is a need for strategies to support the ecosystem's ability to grow or maintain its communities over time and survive changes. In this scenario, the organizational area of Developer Relations (DevRel) emerges as a potential strategy.

But what is a relation?
I always like to, when understanding an area, look into etymology (grammatical study of the origin and history of words) for support.

For relation, there are two aspects:

1. from English: relations, everyday interactions, a micro view of interactions between people;
2. from French: rappaport, structural connections of society, a macro view of interactions.

Thus, a relation can be a collective and identity-building construction of interactions between people-people, people-artifacts, and artifacts-artifacts.

Awdren, artifacts? 😳 Yes, you also interact with computers, cell phones, code, documentation... From the interaction perspective, both people and artifacts are part of our relations.

Based on studies (review of scientific articles and technical articles from professionals with proven DevRel experience) and a qualitative synthesis method, the following definition for DevRel has been established:

An organizational area that creates synergy between an organization's goals (around products, services, or actions) and developers' experiences. This is done in an organic and structured way.

Shall we explore the concept?

🚩Awdren, but I heard it's the bridge between the organization (including its internal areas) and the communities. Yes, I agree, that's synergy.

🚩Ah, Awdren! I also read that it represents the community within the company and the company within the community. Yes, that's synergy between organizational goals and community members’ experiences.

🚩Hmmm, but Awdren, isn’t another view about relationships between the company and developers? Scientifically, and I see other more mature companies in the area using relation and not relationship. Let's go to etymology? I have a native English-speaking friend, and he explained the following:

... 'relation' shows the connection between several people, countries, organizations, continents, etc. Note that it is a formal kind of connection. 'Relationship', indicates the informal, smaller type of connection between people like close relatives, couples, etc.

Thus, it becomes clearer that we are talking about relations. Moving on to the concept, what is developer experience or DX? It is a UX-based aspect that addresses all expectations, desires, journeys, frustrations, perceptions of the developer within the community and in interactions (remembering that it can be interaction with people and/or artifacts).

Organizational goals are connected with vision, mission, strategies, roadmaps, products... Everything that the organization needs to deal with from a business and technical perspective.

Synergy, ok. Organizational goals, ok. Developer experience or DX, ok. But what about organic and structured?

• Organic 🌱🪴🌳: refers to the fact that DevRel strategies should consider the natural dynamism of the ecosystem communities and also support this happening. That the ecosystem self-regulates and organizes itself aiming for synergy with organizational goals and DX;

• Structured 🔻: connects with direct “interference” actions coming from the organization to the communities within the ecosystem. Something “bottom-up.” I like to call it intervention. These strategies must have some kind of feasibility analyzed. And that, in the future, they become, in some way, organic.

The DevRel area is responsible for creating and communicating technical resources (e.g., APIs, code samples, documentation), planning and conducting events (e.g., hackathons, lectures, partner company mentoring), and managing developer programs (e.g., AWS Heroes, Google Developers Experts, Microsoft Valuable Professional, university partnership programs), to name a few tasks. Spoiler: I have students working on refining activities, and in my thesis, there is a set associated with DevRel stages.

Planning and executing DevRel activities are not trivial and focus on delineating community actions without excessively restricting the desired level of value creation. DevRel professionals need to have a realistic view of value creation and DevRel's support structure within the ecosystem, aiming to meet community needs and achieve organizational goals.

DevRel also aims to help incorporate potential contributions (i.e., products, services, and complementary innovations) that arise from communities into the ecosystem's platform, products, and services. It helps balance the organization's roadmap with developers' needs. This area includes roles such as evangelism and advocacy. This will be content for another text.

Adequate resources, such as open-source components and tools, are provided to support communities, aligning the organization’s goals with different target audiences. These resources and tools are developed based on organizational guidelines that include platform specification, emerging ideas, best practices, technologies, development tools, marketing, quality criteria, and user interface design.

Why does DevRel need scientifically based content?

• The process of creating or contributing to a product (software) has the characteristics of production or engineering. And time-to-market, competition, cooperation, and socio-technical-business alignment require continuous and systematic improvement of process and product quality;

• This continuous and systematic improvement requires a systematically organized body of knowledge. This will support the use of strategies based on rigor, significance, and relevance;

• After all, would you expose your organization to something that could harm its growth or image? Therefore, you need science to support your business;

• As budgets are cut, there is more pressure to provide stronger evidence and more compelling business cases to implement new technologies or make process changes and even justify decisions already made;

• DevRel is no different. Even more so because it is an area that is still being established.

Some examples of how organizations use DevRel, briefly

🔔 Attention, the summary below is based on job announcements and other texts. However it does not mean that DevRel within each mentioned organization deals only with the listed set of activities. Also, it is not just these companies. But here I highlighted some, without preferences or biases, to show the diversity of the area. Thank you :)

1. Microsoft: Support and contribution to open-source platforms, tools, and processes. Promote products and services (e.g., Azure) and allow community members to do what they love: write, code, and learn. Create global online developer experiences such as docs.microsoft.com, Channel 9, and dev.microsoft.com. Connect with technical communities through programs, including Microsoft MVP, Microsoft Regional Director, Build Conference, and partner technical events worldwide;

2. Twillio: Cultivate a developer community both internally and externally. Coordinate developer events, such as hackathons. Create content such as blog posts and presentations that empower corporate developers to create with Twilio on a large scale;

3. Nintendo: Acts as a technical liaison between Nintendo and developers, ensuring that projects are successfully completed on schedule. Identifies and escalates obstacles for priority projects and software titles. Manages and supports platform developer programs, working with internal engineering support and third-party publishing teams. Provides support for developers in forums and generates reports for special internal projects. Screens, categorizes, and guides developer support issues for resolution. Conducts outreach with small development teams as well as educational institutions. Ensures developers have access to Nintendo's technical documentation through the Nintendo developer portal. Participates in industry trade shows as necessary.

4. Canonical: Engages with developer communities and ISVs to help them reach the Ubuntu ecosystem. Typically helps communities shape their snaps, charms, or Docker images based on Ubuntu and ensures Ubuntu is fully enabled in their CI/CD pipelines.

5. Azion: Creates and empowers a community of Edge Computing developers. It is part of the Developer Experience team that works in conjunction with the company's education, marketing, product, and engineering teams.

6. Google: Promotes the success of community members with guidance and engineering support, accelerating the adoption of Google technologies. Supports key developers in creating contributions to Google products and services. Helps develop developer strategy with product teams, acting as the communicator for their partners to bring mutually beneficial features to market.

7. Pipefy: In addition to connecting with the external community, the DevRel area focuses on establishing culture and knowledge management among the community members who are part of Pipefy.

What’s Coming Next?

• A model for DevRel (the DevGo): a model to structure DevRel in your organization and, of course, to better understand the area. It was proposed as part of my thesis involving various scientific and professional methods. The model includes focus areas, facilitators, lessons learned, roles, strategies, monitoring methods, and value transfer objects. It also covers stages of the developer’s advancement flow: Sensitization; Activation; Retention; Recognition; Maturation; Monitoring.

• Roles in DevRel: Shall we talk about the main roles? You may have heard of evangelist, advocate, partnership engineer, tech writer, DevRel professional... Ah! Just because your company uses a specific DevRel role doesn’t mean the others are unimportant or unnecessary. These roles were also recovered through a study by Raphael, a TCC student who was awarded for his work.

• Skills in DevRel: The ongoing results of Ana Elisa's master's research, in partnership with Glaucia from Microsoft and Gabs Ferreira from Alvin, will be presented. These results cover the skills needed to train individuals from graduation and help train those already in the industry.

• And more... which I will announce in upcoming texts.

References used in this text:

1. MACHEREY, Pierre. Aux sources des rapports sociaux: Bonald, Saint-Simon, Guizot. Genèses – Sciences sociales et histoire, n. 9, p. 25-43, 1992.

2. Fontão, A., Cleger‐Tamayo, S., Wiese, I., Pereira dos Santos, R., & Claudio Dias‐Neto, A. (2021). A Developer Relations (DevRel) model to govern developers in Software Ecosystems. Journal of Software: Evolution and Process, e2389.

3. Manikas, K., & Hansen, K. M. (2013). Software ecosystems–A systematic literature review. Journal of Systems and Software, 86(5), 1294-1306.

4. Thengvall, M. (2018). Building a developer relations team. In The Business Value of Developer Relations (pp. 73-100). Apress, Berkeley, CA

5. Oliveira, R., Ajala, C., Viana, D., Cafeo, B., & Fontão, A. (2021, September). Developer Relations (DevRel) Roles: an Exploratory Study on Practitioners’ opinions. In Brazilian Symposium on Software Engineering (pp. 363-367).

6. Minha tese :D