Defining and Developing a Concrete Role for DevRel

‍When implemented with purpose and managed effectively, DevRel fosters broader change in a company. In this podcast, Peritus CEO, Robin Purohit explores the nature of the DevRel position and how we measure success with Steven Pousty, Developer Experience Manager at VMWare.

‍The Nature of the DevRel Position

‍Steven Pousty has a unique perspective on the nature of the DevRel position. Beyond his role at VMWare driving the Tanzu developer experience, he has hands-on experience as a Developer Advocate for Crunchy Data, DigitalGlobe, Red Hat, LinkedIn, deCarta, and ESRI. With a Ph.D. in Ecology and broad experience with Containers, Kubernetes, Data Analysis, Java, Python, PostgreSQL, Microservices, and some JavaScript, Pousty offers numerous insights on the role of developers in the modern enterprise.

Pousty defines DevRel as an operational function within an organization with many possible roles on the team, including Developer Advocacy. Advocates are largely internal-facing, working with developers within an organization, speaking on their behalf to stakeholders and other departments—acting as a bridge across silos. Developer Relations is a broader take on the concept, nurturing those relationships both internally and externally. They go out, teach on behalf of the company, interfacing with developers, and solicit feedback for the engineering team. These distinctions are important because there are many people who would like to get involved with Developer Relations but may not have the technical skill to write code. Advocates who speak the same language and have the same technical background as developers are vital in such a system, but there are places for community builders, communicators, and facilitators who excel in nurturing relationships across those boundaries.

Having worked at five different companies as a Developer Advocate, Pousty has extensive experience with variable structures. While he doesn’t think there is a specific location DevRel should live at in an organization, he identifies certain factors that can influence the efficacy of the department. For example, in marketing, DevRel can be seen as a talking head and will face challenges in giving feedback to the engineering team that will improve the product. As part of R&D, DevRel faces questions about budgets and direct contributions to the codebase. While not universal, these represent possible challenges depending on the politics of an organization. Pousty reiterates the importance of “making sure the developer advocates have the ability to go both ways and present outwards and inwards, giving feedback to engineers when necessary.” DevRel is a bridge between different groups of an organization, both internal and external, so it’s important that it has the flexibility and access needed to achieve its goals. This will vary depending on the structure of each organization.

‍Measuring Success in DevRel

‍Despite having a Master’s Degree in Statistics and several advanced degrees in quantitative sciences, Pousty is leery of over-reliance on statistics and hard metrics to measure DevRel performance. Often, DevRel departments optimize for metrics rather than organizational goals defining their position. For example, if there’s a KPI focused on developer signups, an advocate might focus on the wrong audience because they convert at a higher rate. They focus on hitting their metrics more than achieving the goal of their position—to connect with developers who might use the product. There are certainly situations in which vanity metrics like the volume of signups or size of a community are important, but such decisions should be intentional, and not driven by artificial metrics that don’t represent the goal of a DevRel position.

The end goal of DevRel, which can make some in the position uncomfortable, is to prep the field for sales. Developers are often averse to the concept of sales, but at the core of the role is building relationships that lead to increased users. This requires a sale. There’s a fine line to walk here, of course. Sales activities in a vacuum can turn off developers. Cold calls, cold emails, and other aggressive tactics are generally ineffective, and even less so with developers. But building relationships, following up, and providing value are all key to success in DevRel. Measuring success against these efforts is more fluid, but it’s important to focus on results more than any single quantitative metric.

‍Writing Effective Documentation

‍DevRel is inherently about crossing divides—incorporating skills in working with engineers, coordinating and pushing to sales, and communicating technical information. Pousty discussed the need for people with the right combination of technical knowledge and communication skills to write effective documentation. He discusses how VMWare uses a combination of Product Managers and Developers to build documentation effectively. Engineers are responsible for the first light draft of a reference document, often in their own editing tools to avoid shifting systems or breaking flow. PMs then review and ask for clarification or expansion. This process works well when dedicated technical writers who can understand the systems, operate them, and write effectively are needed. Writers must be curious, able to speak with engineers on their level, and capable of crossing those boundaries seamlessly. They need to be willing and able to ask specific questions, recreate issues, and transfer knowledge to documentation seamlessly. To this end, Pousty notes that he believes documentation writers should be on the engineering team, and that the resulting documentation should be tested and treated like any other part of a release. All pieces of documentation should receive end-to-end testing to check for errors in the text or changes in the software not captured in the documentation.

‍The Future of DevRel

‍While DevRel has grown in recent years, Pousty notes that it’s not always clear why a DevRel team is being started. As a result, they often aren’t given a clear mission statement. This lack of clarity can create issues right away. Pousty’s vision for the future is for DevRel to become a standalone profession and not an add-on to engineering. In the same way that computer engineering is its own field today with dedicated schools, pedagogies, and degrees focused on success in a specific channel, DevRel deserves similar treatment. That’s not to say Pousty believes a degree in DevRel should be required to enter the field. Rather, he hopes to see standardization and study develop around the field to help clarify the goals, best practices, and expectations of a very important part of the development process. A student in college should be able to recognize that their affinity for writing and communication, a keen understanding of technology, and a desire to work with developers points to a career as a Developer Advocate. “I want people to be able to see this as a career they can choose that will be worth their time and for which they well be respected.”