Developer Relations
[Author’s note: I originally wrote this in 2020 as an educational piece for management at VMware. Consequently, some of the examples may seem out-of-date, but the fundamentals of DevRel like its mission, organizational structure, and responsibilities are just as relevant today]
Introduction
This paper provides an overview of Developer Relations (aka “DevRel”), how this organizational function first came about, describe its mission, structure, and briefly review DevRel organizations at other large tech companies. If you’re interested in learning the key functions of DevRel and are debating the need to create a centralized Developer Relations team in your organization, this article may help you.
The Origin of Developer Relations
The organizational structure within platform companies that concerns itself with the health and welfare of their external developer ecosystem is typically called Developer Relations. In many companies, this is an organization designed to support the many different business units and product teams within a platform company. DevRel organizations are sometimes placed within the Marketing, Engineering, or Product teams. Sometimes they’re separate professionals sprinkled throughout these organizations without a formal structure of their own, and as I’ll do my best to demonstrate, this method does not produce optimal results.
The first Developer Relations teams emerged as a result of the “OS Wars” in the late 80’s and early 90’s. Guy Kawasaki had a team of “Evangelists” that were heavily promoting Apple computers as a place to target their apps. In response, Microsoft created a team in 1989 as a result of the apparent success Guy Kawasaki’s Evangelists were having, but Microsoft tweaked the Evangelist title and created their own role “Technical Evangelist”. They then formed a team called the Microsoft Developer Relations Group. A member of that original team (and my former boss at BlackBerry), Bob Taniguchi, once compared Microsoft’s approach to DevRel with that of Apple’s in a 2013 post to his “ecosystemville” blog titled, In the beginning, BillG created the Evangelists in his own image ¹. Here is an excerpt:
From the beginning Microsoft’s Technical Evangelists were very different than Apple’s team. First and foremost, we were all developers. We had coded apps for Windows, Unix, workstations, mini and mainframe computers. In contrast most of Apple’s Evangelists were MBAs and were non-technical. Secondly, our evangelists were laser focused on helping partners deliver their code, gain distribution in the channel and market their products. Apple Evangelists, in a weird bit of foreshadowing, delivered an “experience meeting” more like a big tent revival. As the other Japanese American technology evangelist in the industry at that time, I was always hearing comparisons to Apple’s Guy Kawasaki. Although he and I had the same goal, to lock up ISV platform investment, we employed very different tactics. During these early days of evangelism I heard many times that “Guy was here last week…” then “… you guys are very different…” and most importantly that “… we’ve decided to do the Windows version of our app first”.
Microsoft knew that developer evangelism had to be technical and had to support the goals of Microsoft. While the technical evangelists would appear as if they’re on a mission to help developers, the internal laser focused goal was on helping Microsoft. Indeed, the definition of evangelism at Microsoft was:
“Evangelism is the art and science of getting developers to ship products that support Microsoft’s platforms” ²
The Microsoft Most Valuable Professional, or “MVP” program emerged from the developer community as a way to enlist and entice technology experts in the industry to become evangelists for Microsoft as well. The benefit of being selected as an MVP was huge. You got early access to products, access to members of the product teams, and an invitation to the exclusive Global MVP Summit hosted in Redmond Washington. Many Evangelism programs have been modeled after Microsoft’s MVP.
Over time, Developer Relations teams grew to focus on broader areas of interest, beyond simply Evangelism. In addition, they have spread into new industries as new technology platforms emerged. Since the OS Wars, DevRel appeared during the Browser Wars (Firefox, Explorer, Chrome, Safari), the Mobile Wars (Android, iOS, Windows), and more recently during advancements in IoT, FinTech, AutoTech, AI/ML, Data Science, and Cloud. Just as Marc Andressen’s now-famous quote “Software is eating the world” has become evident, along for the ride was DevRel, which can now be found in virtually every industry.
The Mission of Developer Relations
The mission of Developer Relations can be broken into 3 main areas: Grow the Ecosystem & Increase Dependence, Accelerate the Customer Journey, and Provide Ecosystem Feedback to Product Teams. More detail for each is outlined below:
1. Grow the Ecosystem & Increase Dependence
While this may seem obvious, the goal here is to acquire and retain developers and make sure they’re successful. Most DevRel teams maintain metrics that track the number of developers they have, the growth rate, and the cost/developer (how much it costs them to acquire a new developer) and the value/developer (the estimated value each developer brings to their platform), and more simple metrics like TTHW (Time to Hello World).
At the organizational level, DevRel team’s success, especially in the ubiquitous world of SaaS, is measured best along two dimensions: Adoption (the extent to which 3rd party apps/solutions play a role in acquiring new customers or upselling existing customers), and Retention (the extent to which 3rd party apps/solutions keep customers on your platform. Sometimes this is referred to “stickiness”).
The goal is to make sure they’re successful and profitable by providing value that your platform doesn’t provide. Problems occur of course, when they start providing value you should be providing (this is a topic for another time). In the simplest form, when your developers are making money, their applications and solutions are selling, which means customers are buying their apps and the dependency on your platform increases.
2. Accelerate the Customer Journey
The main idea here is to be strategic with the partners you bring into your ecosystem. You want partners/developers to fill product gaps in your platform that are required by your customers, but beyond the scope your company’s product roadmap. By encouraging solutions like this, you’re accelerating your customer’s journey. They have problems to solve and your platform along can’t solve them all, so you’ve judiciously chosen partners that can do so.
Sometimes your developers are also customers as is the case with many platform companies. Accelerating the customer journey here is ensuring these customer-developers are able to get to market as quickly and smoothly as possible often via a high-touch engineering support, or special go-to-market promotional programs (in cases where their market extends beyond their own internal use of their app) or co-selling motions with your sales teams.
3. Provide Ecosystem Feedback to Product Teams
Most companies have recognized the incredible value found in customer feedback. DevRel teams feel the same way about Developer feedback. If you treat your developer surfaces (APIs, SDKs, Portals, Developer Docs, etc.) as products, then getting feedback from your developers is customer feedback. Fast, tight feedback loops here help you correct issues very early on since developers and partners often see your products before your customers do. In addition, developer feedback can highlight areas of opportunity you might not have thought about for your platform, which can have real competitive advantages.
How Other Companies Approach DevRel
Virtually all the top platform companies have Developer Relations teams. I define a platform company as any company that exposes APIs to other companies/developers for the purpose of building applications that run on or interact with the company’s products.
Over the last decade, there has been enormous growth in the number of companies that follow the “platform” business model. Not only do platforms enable the building of ecosystems of solutions that depend on the platform company’s core products, but they also add value to customers where the underlying platform companies cannot –either because they don’t have the resources, expertise, time, or strategic interest to do so.
A Typical Organizational Structure
Not all organizations structure DevRel in exactly the same way of course, but in the dozen or so I’ve come in contact with either by working in DevRel organizations myself, or through industry contacts and conferences, virtually all have an executive leader at the top. It is often someone with a “Vice President of Developer Relations” title that has responsibility and oversight across the company’s developer engagement effort. This can include full ownership over client-side APIs.
In much the same way Marketing organizations have subgroups like Branding, Social Media, and PR etc., DevRel organizations have typical subgroups that focus on 4 functional areas. These go by different names and the work can be divided up differently, but for the purposes of this paper, I’ll propose these names: Developer Operations & Infrastructure, Developer Engineering, Developer Marketing, and Developer Advocacy. A typical DevRel organization might be structured as follows with their primary job functions listed below:
DevRel Team 1 — Developer Operations and Infrastructure
The Developer Operations and Infrastructure team typically manages the developer portal and all the developer assets hosted on the site. This team can also own the app marketplace infrastructure. Portions of the developer portal and marketplace include content that originates elsewhere. For this team, those other groups providing the content are it’s customers (e.g., Developer Marketing, Developer Engineering, Product Engineering, etc.). The operations team works closely with all these teams.
As a result of managing the developer portal and related infrastructure, the operations team has unique access to the developer engagement analytics (page views, new memberships, event registrations, and downloads) and makes these available to the rest of the DevRel organization especially Marketing and Advocacy.
Developer Programs are often managed and defined by the Developer Marketing team but implemented by the Operations & Infrastructure team as they surface on the developer portal. Developer Programs bundle a host of benefits targeted at developers that entice them to join the program. For more information on this, see: Developer Programs & Market Research.
DevRel Team 2 — Developer Engineering
The Developer Engineering team works very closely with the product teams to make sure the APIs and Developer Docs are consistent across the company and provide the best Developer Experience (DX) for developers. Google’s DevRel team decided that working with the product teams wasn’t good enough to ensure consistency. Google DevRel actually owns the client-side APIs and the Developer Documentation completely –not the product team. Amr Awadallah (back when he was VP of Developer Relations at Google Cloud) told me that they’ve taken full control over the client-side APIs because “uniformity and consistency are critical across the product lines, and the product teams can’t do this”.
Developer Engineering also works closely with key/strategic developers and partners to make sure they’re successful. Developer Engineering makes sure the Advocates have the latest information about updates from the Product teams as well as receive the feedback from the advocates back to the product teams.
DevRel Team 3 — Developer Marketing
Spend any time with developers and the one thing you’ll learn is they do not like talking to “Marketing” people, most of the time. Developers care about getting their apps written and if you can’t speak the language of code, you’re of little use to them. However, there are a few cases when developers actively seek your Developer Marketing team. These include help with improving their apps performance in the Marketplace or with other GTM activities such as joint PR, sales lead generation, social media amplification, and of course, any discussion having to do with getting free swag or discount codes for conferences.
Perhaps the most important and visible activities performed by the Developer Marketing team are the Developer Events they run. Often these include one large annual Developer Conference like Microsoft’s Build, Google I/O, or Apple’s WWDC.
Marketing also hosts or sponsors smaller, localized events and recruits passionate local developers to run them. They would equip them with care packages of swag (“meetup-in-a-box”), visiting Developer Advocates with demos of upcoming APIs or platform advances, sample hardware, and a small budget for pizza and drinks. Intel, for instance, is particularly good at this.
As mentioned earlier, Developer Marketing typically defines and manages the Developer Programs. They also acquire Market Research that helps them understand how their DevRel Programs stack up against others in the industry across functionality, price, satisfaction, engagement, and more. For some examples of this, check out my article: Using DevRel Market Research to Compare Developer Programs.
Developer programs offer many benefits such as access to APIs, Tutorials/Labs/Workshops, Testing Resources, SDK downloads, Support, Marketplace publication, and more. The value of these Programs to the company offering them is they provide a mechanism to track the growth, control access, and measure engagement of their developer audience across different segments. It also provides a convenient gate for click-through agreements that satisfy the company’s legal requirements concerning liability and general legal issues as well as access, distribution, and payment terms in the case of an App Store.
For more reading on Developer Marketing, I recommend the book: Developer Marketing, the Essential Guide³.
DevRel Team 4 — Developer Advocacy
This group used to be called “Evangelists”, but the industry has moved away from that term preferring “Advocates”. The rationale here, as I’ve heard it best described by Sam Ramji (back when he was VP or Product Management at Google), is that Advocates is bidirectional. You can advocate on behalf of your company and you can advocate on behalf of the developer. Conversely, Evangelism is a one-way communication and as such doesn’t promote the idea of championing the developer’s needs back to your product team.
Developer Advocates are your road-warriors. They’re on stage, on screen, or in print as often as possible. They are a rare combination of super-star developer and great public speaker. Their job is to engage with your developers out in the field or wherever they are and teach them how easy it is to build applications on your platform. They build demos, run meetups, record glass-board how-to’s, respond to questions on Stack Overflow, write blogs, and maintain an active social media presence. When I ran the Advocacy team for the Americas at BlackBerry, I tracked a number of KPIs for our team including the number of developers reached/engaged, blog post frequency, app submissions/region, developer feedback, and number of new devs onboarded.
During my final year with BlackBerry as we fought to stay relevant in the lead up to our BlackBerry 10 device, I found myself on stage at a conference, pitching to company, or presenting at a meetup, 50 times in a 12 month period. I do not recommend this pace.
Centralized Leadership
DevRel teams are led by a strong leader, typically with a “VP of Developer Relations” or “Head of Developer Relations” title. Most successful platform companies I know have a single DevRel organization with one leader at its head. Here is a snapshot of some of these from LinkedIn that include large platform companies, some hardware, some software, and a few smaller and/or open source companies that appoint executives to lead their Developer Relations organization:
As mentioned, I wrote this piece about 3 years ago as an educational tool to help my management at VMware recognize the importance of a centralized DevRel team. The names and job titles have changed in the last 3 years, so I’ve blocked out the old data. One thing I’ve noticed recently however, is the DevRel organizations are getting larger and specializing. For example, Google today has VP of DevRel for Cloud and a separate VP of DevRel for Android. They even have VPs of DevRel for different regions of the world. To my knowledge, VMware today still does not have a central DevRel team which will make it very difficult for them to climb out of the lower-left quadrant in the Benchmark chart above without a dedicated team.
Perhaps the most notable platform company that does not have a centralized DevRel organization is Amazon/AWS (if this isn’t still true, please let me know in the comments). I discovered this in a conversation a while back with a former colleague of mine who was a previous executive at Amazon. Amazon “has a cultural aversion to anything centralized” he said. Not having this centralized “caused a lot of problems like inconsistent messaging, mismatched interfaces like EC2 and RDS, and duplication of effort”. The only way to drive change across the company he told me, was through public shaming. In an effort to get all the product teams to localize their developer materials, they started scoring each product team’s doc localization progress and shared those scores on a regular basis with Andy Jassy.
In my opinion, having to shame product teams into doing the right thing by involving CEO in this way is a sure sign of a dysfunctional organization. I’ve seen this behavior before in other companies myself. It happens when a team has a noble goal, something that is really good for the company, but they don’t have an executive leader/sponsor. Amazon/AWS is successful with developers for other reasons, my colleague had told me, and certainly not because of their lack of structure. He wondered how much more success they might have had if they centralized Developer Relations and coordinated their outreach efforts. Perhaps this is why Amazon ranks in the middle of the pack with developers on both engagement and satisfaction and not in the upper right quadrant with Google and Microsoft (see Developer Program Benchmark above).
Another good reason to have a central DevRel organization is that it provides an organizational structure for career advancement of your DevRel practitioners (Amr Awadallah). I couldn’t agree more.
Summary
Developer Relations has been around for a long time. It’s evolved from an Enangelism role started by Microsoft and Apple to include Developer Marketing, Developer Engineering, and Developer Operations (not to be confused with “DevOps”). Developer Relations exists for 3 reasons: 1) to grow your 3rd party ecosystem and increase dependance on your platform, 2) accelerate the customer journey, and 3) provide feedback to your product teams. Most large platform companies have organized Developer Relations into it’s own centralized org structure with executive leadership because this allows them to focus and deliver the best value to their developer ecosystem enabling it to grow and support the platform.
References
[1] Taniguchi, Bob, Ecosystemville, In the beginning, BillG created the Evangelists in his own image
[2] Plamondon, James., Effective Evangelism.doc, Microsoft, 1997. link saved by the wayback machine
[3] SlashData (Author), Nicolas Sauvage (Editor), Andreas Constantinou (Editor), Developer Marketing, the Essential Guide, 2018
