As we navigate the emergence of the DevRel ecosystem, Peritus CEO Robin Purohit sat down with OneSignal’s Head of Developer Engineering Jordan Adler to explore best practices around DevRel team building, success metrics, engagement strategies and key trends.

‍From Google to Startups: Building Bridges Through Developer Relations

‍By way of background, Jordan built the Engineering Productivity team at Cruise, led API Platform Engineering at Pinterest, and championed Strategic Partnerships and Developer Advocacy at Google. While working with Google partners, Jordan collaborated with Android developers, iOS developers, and anyone building on platforms that Google had a vested interest in, with the goal of enabling developer access to cutting-edge tools and APIs. His team championed Google’s one-to-one outbound engagement strategy to ensure partner engineers adopt their approach to web strategy, while also building a broader community and ecosystem.

Years later, he embarked on a similar journey at Pinterest, supporting the developer ecosystem in the adoption of an API that is now used by media-driven app developers around the world. Eventually, he made his way to OneSignal to lead their SDK team and build out their DevRel function within the company. As a result of his efforts, OneSignal now boasts one of the top 30 most used SDKs across the Android and iOS platforms.

‍Building Out a DevRel Function and Team

‍Since the advent of the Developer Relations, an ongoing debate has emerged around where DevRel teams should sit in an organization. Should a DevRel team roll into the engineering function? Should they report to the Marketing or Revenue teams? A critical component in answering this question requires carefully dissecting the Personas that the team’s product is selling into. Is the company selling to a Product Management persona, a Developer persona, or a Marketing persona? More often than not, however, company’s sell into many different kinds of personas from technical to business functions, including many new merger roles, that require different value propositions and service orientations. Because DevRel straddles several functions across a business, Jordan believes these teams should be interdisciplinary in nature. By building interdisciplinary teams, he argues, a company can deliver best-in-breed developer engagement experiences, optimized for their particular personas. Only by working back from that northstar, should a business build out a reporting structure for the DevRel team.‍

How To Measure Success in DevRel?

‍Many organizations struggle with measuring the success of their DevRel team. How can managers understand how particular DevRel activities perform in comparison with one another? How can they analyze, and prioritize, the team’s efforts? A natural starting point is measuring the number of engagements within developer-facing events per year. For example, if a business holds 50 virtual events annually, how many meaningful interactions are generated with leading engineers or developers? How many attended, who attended and what were their profiles? It’s crucial to measure all of these factors to capture the ROI of a company’s DevRel activities. Lessons-learned can also help customize and shape future activities to refine messaging content, prioritize product features and deepen (or broaden) engagement with the segments that are most receptive and valuable for the business. Traditional companies focus purely on the top of the funnel, but the DevRel function is now focused on increasing and measuring engagement across the developer experience.

‍How Do You Build Engagement in a Virtual Environment?

‍In today’s virtual and remote-first environment, the most important way to engage with developers is to meet them where they are. Whether it’s a SubReddit, a Twitter cohort, or a Discord server specific to a specific development ecosystem, DevRel teams need to get out there and engage with developers directly. Context is key, however. “If you're in a community space,” he points out, “you don't want to be walking into the public square and start yelling and sharing your advertisements.” Teams also need to ensure they’re equipped to help solve a specific set of developer problems. Jordan and his team at OneSignal focus on building open spaces and communities which they can manage actively. By leveraging communities on Twitter, LinkedIn and Discord, and engaging with developers directly, Jordan’s team can answer deeply challenging questions for users, while doing so in an open and accessible manner. Regardless of which medium a company selects, the key is to speak with users in real-time, and prioritize open engagement and workable solutions.

‍Building a Successful Beta Program

‍Across the developer communities that Jordan has built, the Beta program at OneSignal stands as one of his most successful undertakings. “You want to make a great first impression, and a beta program gives you the opportunity to make sure you are providing early access while asking users how you can be doing better,” he explains. Recruiting strongly opinionated beta customers provides DevRel teams with candid and actionable advice for the company’s install base, while generating valuable feedback before taking a product to market. “Your install-base is one of the strongest communities to tap into, as the developers already use your product and their businesses depend on your services,” says Jordan. “You should give them a chance to share their voice in shaping the future of your product while building ‘developer infrastructure’ to support them.” Absent an existing install-base, it’s important for DevRel teams to use Twitter, Subreddits, and Discord channels to reach new users. If necessary, they can also purchase leads from specialized market research firms when appropriate, to stimulate initial traction.

‍How Other Teams Interface with DevRel

‍When working to communicate and interface with other teams within your organization, DevRel leaders need to consider the metrics used by those teams in measuring success. Activation, acquisition, revenue, and referrals are marketing metrics that can still apply to developers when framed with a developer-specific lens. For example, how many developers were reached with this message or campaign? How many developers sign on to our service? How far do they get in the funnel? Those are all ways to frame marketing or revenue-facing metrics through the lens of DevRel. The entire developer journey and product experience includes content, developer documentation must therefore consider how much marketing language to integrate. There is a fine line, Jordan highlights, between technical documentation, which helps developers solve challenges while maintaining consistency with marketing messaging, versus marketing. However, the priority, according to Jordan, “is the qualitative analysis that comes from the one-on-one engagements with developers, through building out the products, or being the first developer to ever target a new API.”

‍What is the Difference between Developer Advocacy and DevRel?

‍While investor relations manages the relationship with investors, Developer Relations is the function in the organization that manages the relationship with developers. There are different ways that DevRel teams organize themselves, however. Developer Advocates, for example, represent a hybrid engineer and marketing role that conducts market and product analysis, engages with developers directly, and integrates into the product development lifecycle. DevRel teams often include technical writers who focus more on developing the documentation and content for developers. Some organizations focus on hiring Developer Relations engineers, or Dx engineers, who focus more on the coding aspect of the functionality, and building out code samples or sample use-cases for potential clients. Developer advocates are frontline roles who evangelize and communicate on behalf of developers. The challenge in hiring advocates is finding candidates who have a mix of social skills and technical know-how, so they can relate to and access developer pain points, and translate those into action items for product management and engineering teams, enabling them to make better products for developers.

‍Challenges and The Future of DevRel

‍Given the rapid evolution, and function, of DevRel teams, reading through the noise and learning to focus is key. For Jordan and his team at OneSignal, this means figuring out how to build out new DevRel capabilities. Whether it’s building out a guest creator program for the OneSignal SDK, recording a new podcast, or writing a new content piece, it can be challenging to juggle and prioritize the opportunities to engage with developers. The diverse base of personas at OneSignal, from game developers, to iOS, Android and web developers, demands broad subject matter expertise, even if with a lean team. Assessing gaps in capabilities, and recruiting top talent to fill the holes is, therefore, of paramount importance. “What we’re clearly seeing now is that everyone is trying to build some sort of DevRel discipline, or embrace some developer-led business model.” Whether it’s Product or Community-led growth, this buzz is extending from Silicon Valley across the entire world. The chart is looking up and to the right.