Why Do We Pay These People Anyway?

Why do companies build developer platforms?

If a platform benefits from increased user adoption, it needs products and services to attract those users; an ecosystem of 3rd party developers is how they get built.

A healthy ecosystem elevates your platform, providing a richer offering than your products alone by filling the gaps you’re unprepared, unable, or unwilling to fill yourself. You sacrifice exclusivity in the market but in exchange create a larger opportunity for yourself and others. You can create a much bigger pie in exchange for cutting it into smaller slices.

Ecosystems also provide flexibility in otherwise rigid vertically-integrated products. Both Android and iOS are platforms for App developers, and as a result the devices that use them are much more useful than if each device were limited to software written by Google or Apple respectively. Android takes this approach even further as an open ecosystem for device manufacturers.

On a different scale, the Google Maps APIs have created an ecosystem of millions of apps and websites, each with an embedded Google Map. This increases the use of Google Maps through the 3rd party implementation of opportunities far in excess of what Google could build itself.

In practice, the underlying goals of creating a developer ecosystem are complex and interwoven. For the platform owner, it grows the audience for the 1st party apps and services they contribute, and they may monetize by charging developers to use the platform, or to distribute within the ecosystem. A platform can also be a hedge against dependence on a competitor, or be an attempt to spur innovation. Given the cost of creating a platform and ecosystem, most likely the goals are a combination of several of these factors.

It doesn’t always make sense to turn a product into a platform. Doing so risks enabling competitors that can draw users away from your own offerings, or allow a diminished user experience for your product.

A healthy ecosystem is self-sustaining and mutually beneficial, where the success of 3rd party developers helps your users and supports your goals, and vice versa.

What is Developer Relations?

Developer Relations’ role is to create a vibrant ecosystem of 3rd party developers, by being the interface between those developers and your platform’s product, engineering, and design teams.

To ensure that interface is high fidelity, Developer Relations must be credible.

In addition to building awareness, Developer Relations is responsible for creating everything needed by developers to build great products using your platform. Everything from collecting bugs and filing feature requests for developers, running early access programs, writing documentation, creating samples, creating training and technical videos, speaking at conferences, and answering questions on forums and Stack Overflow.

They also help adapt the platform to the needs of developers, by engaging with the community—online via social media, and in person at meetups and conferences—and acting as their advocates with your product and engineering teams. This ensures that the platform evolves in line with the needs of your ecosystem.

Ultimately Developer Relations is responsible for your platform’s developer experience. This will help developers build better products, which in turn creates a better user experience, that leads to more successful apps, and a more successful ecosystem—which in turn encourages developers to build better apps.

The virtuous cycle of Developer Relations

In small companies (or nascent products) Developer Relations tasks are often the responsibility of the product and engineering teams. Eventually your platform will mature to require engineers who focus full-time on these activities, and to expand their efforts to include more complex programs like training and community engagement, and through the development of more comprehensive narratives that support outreach, and include multiple platforms and APIs.

What Makes a Good Developer Relations Team?

Trust. Developers need to trust your DevRel team; for that to happen they need to be credible.

Developer Relations is the public face of your developer products—the primary source of information for, and interaction with, 3rd party developers. It’s critical to translate those interactions into a trusted relationship.

The trustworthiness of your Developer Relations team will be measured by the quality and usefulness of the code they produce and the advice they offer. Ultimately the quality of the platform itself will be evaluated through the quality, comprehensiveness, and usefulness of the material produced by your DevRel team.

Developers must be able to trust the code, technical answers, best practices, and training provided by your team as the best, most accurate, and canonical source of developer information.

Your Developer Relations team must also be trusted by your internal engineering teams to accurately represent the thoughts and experiences of 3rd party developers, to give candid technical feedback, and to honestly represent the platform to the developer audience.

They will gain some initial trust simply by being the representatives of the company offering the platform, but to have real impact, they must build trust through legitimacy in a way that’s independent of the company they represent.

What Isn’t Developer Relations?

Developer Relations isn’t marketing, business development, sales, or support. Those teams are important but their incentives are different—and engineers know this.

Developer Marketing work together with Developer Relations, helping improve awareness of content, providing market research, supporting developer events, and creating consistent branding.
Business Development teams work with business decision makers who need more than a good developer experience to convince them to invest resources into building on your company’s platform. BD typically works with a small number of marquee partners whose individual success can accelerate adoption of your platform amongst users. Once a commitment is made, Developer Relations often work with the corresponding engineering teams to ensure a successful collaboration.
Sales teams are typically used to grow platforms that monetize their customers directly—for example cloud or advertising platforms. Sales teams will sometimes be paired with Sales Engineers, their technical counterparts, who are able to work 1:1 with the customer’s engineering team to support the sale or based on a commercial relationship.
Sales Engineers (and Technical Account Managers) are a lot like Developer Relations Engineers, the main difference is that they typically work with existing customers or “pending” customers, where there is an existing relationship with a sales team. Developer Relations sometimes works with partners, but there is typically not a commercial relationship involved.

This article was originally published on my Medium page, and has been lightly edited before being republished here.