Why Do We Pay These People Anyway?
Relating to Developers for Fun and Profit
Why are Developers Important?
In my view, the decision to build a platform is based on how to best serve your users.
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. Your create a much bigger pie in exchange for cutting it into smaller slices.
If a platform benefits from increased user adoption, it needs products and services to attracts those users; an ecosystem of 3rd party developers is how they get built.
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 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.
Continued in Platforms and Ecosystems: What’s the Point? (Coming Soon)
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 made up of engineers; engineers who would be equally capable of working in roles on the core platform or as 3rd party developers.
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.
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 legit.
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 of the code they produce, and the advice they provide. Ultimately the quality of the platform itself will be evaluated though the quality, comprehensiveness, and usability 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.
Continued in The Core Values of Developer Relations (c0ming soon)
What Isn’t Developer Relations?
Developer Relations isn’t Marketing, Business Development, or Sales — none of which are engineering teams.
- Developer Marketing work together with Developer Relations, helping improve awareness of content, providing market research, supporting developer events, and creating consistent branding.
- Business Development team 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 work 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.
Next up in the series is The Core Values of Developer Relations, where I’ll start exploring what are (in my opinion) the key skills and responsibilities that make for a successful and impactful developer relations team based on my own experience.
