When building any large-scale product that provisions software access (via APIs and SDKs), invariably questions about how to support developers arise. Most large-scale software development projects require some form of formal developer support, so it’s not surprising we’re seeing the establishment and growth of well-thought-out developer relations programs. Generally speaking, it’s wise to plan for developer support with a developer relations program from the start, included in the product management and marketing plan.

So how is product management and developer support interrelated? In a very black & white nutshell, a well-managed product should support strong inbound marketing and developer relations should initially be built up via outbound marketing. Of course, this should enhance the inbound cycle, with solutions flowing in from developers – impacting the product in a positive (and inbound) way.

This is a bit overly simplistic, but it helps frame the discussion for how to maximize developer relations’ success with the goal of shaping, shipping, and managing a successful product (for example, be it an API, a complete SDK, or perhaps even a game engine & editor).

It’s important to note that most managers involved with developer relations for software products hold a firm belief that anyone hired to work with developers on behalf of the company need to be as skilled (or as technical) as those very developers who wrote the original product code. This article holds a slightly different view influenced by experience with sales engineers and technical marketing support folks from both software and hardware firms. Support from great sales engineers and well-informed technical marketing people can be as important to developers’ success with your product as your developer relations outreach efforts.

Here at GBR, from our analysis work, we have not seen much in the way of formal processes in place around gathering customer information and requirements from developer relations engineers but we have seen plenty of process and even worked with some awesome applications for managing inbound leads as well as outbound marketing practices – many of which were inspired by developers using the product. Therefore it may be worthwhile to apply some of the marketing industry’s best practices to engineering product management and good ole’ fashioned developer relations.

A keen awareness and repurposing of the various tactics, techniques, and tools from the marketing technology/automation industry can help provide a framework for successfully managing the developer relations’ process in such a way that it effectively optimizes product. But first, let’s take a look at some key similarities and differences between the two fields: marketing and developer relations.

Establishing trust between company and partner/customer is first and foremost for both. In any relationship, be it born of a marketing outreach program or ad hoc developer-to-developer relationship, one must first establish trust.

There is a great post on Quora based on the writings of “trust expert” Charles H. Green, who describes the 4 ingredients of Trust in (Understanding The Trust Equation). Here’s the conclusion, but we suggest reading the aforementioned Quora post if inclined, as the comments are also noteworthy.

Conclusion: Reducing perception of Self-Orientation is the greatest lever to increase trust in relationships.  Ask more questions.  Listen.  Don’t fill silences. Let the other person feel that their point of view, their feelings, their presence here are as important than your own. Charles Green also has a pretty cool infographics on trust on his blog.

Establishing a sense of trust and actually being trust-worthy are essential for any business to succeed, but seem particularly important in the sales and developer relation’s role. Perhaps this is why marketing and marketers often get a bad rap from engineers: they are just too far away from actual customers, and therefore the trust variable may not factor in as seriously as in developer relations or business development. In fact, it’s possible to find many folks in business development with strong technical backgrounds take on the role of developer relations as well, especially in start-ups and smaller companies.

Okay, now that we’ve gotten trust taken care of – which may be the most obvious outlier that differentiates marketing programs from developer relations programs, let’s take a look at what they really have in common.

Key tenets both Marketing and Developer Relations share:

  • Opportunity to share your vision with the community that you think will either entice them heartily to engage with your product and/or solve their problems
  • Proactively listening to what the community needs and filling developer needs with concrete help and support via any conduit possible
  • Providing an easy to find, easy to use conduit for developers to offer you feedback, e.g., using social media’s ability to bring market feedback back into the mother ship
  • Analytics tools to measure outreach and feedback success. Note that marketing seems to have more tools at their disposal than developer relations. Still, any developer relations program can be strategically planned to take advantage of some great marketing and sales tools if architected thus.

Now with these hopefully useful parallels, let’s take a look at some of the better-known developer relations programs out there today from the likes of Amazon, Apple, Google and Microsoft, just to see how they shape up in terms of “best practices.”

Let’s start with Google’s Scalable Developer Advocacy program:

From Google’s Reto Meier on Quora: https://www.quora.com/What-is-the-Scalable-Developer-Advocacy-team-in-Google-Developer-Relations:

Scalable Developer Advocacy is part of the Developer Relations team — whose role is to be the interface between developers and Google’s developer offerings.

More specifically, Developer Advocates on the Scalable Developer Advocacy team are engineers who operate at scale to inspire and teach developers about Google’s developer platforms, ecosystems, and APIs.

They are responsible for crafting a narrative based on developer and product needs and priorities; creating engaging, discoverable, and useful developer content (including trainingvideos,  blog posts,  social mediaweb sites, and conference appearances); and delivering and distributing that content at scale to as many developers as possible.

The team also receives and analyzes feedback from the developer community, and advocates on behalf of developers with Google’s product and engineering teams to adapt and improve the underlying platforms and APIs.

Google’s “content tsunami” pretty much sums up Google’s perspective on developer outreach, which while awesome in many ways, and certainly useful when searching for specific content help, may be a bit overwhelming to some. That said, a few years back, this author was very happy to have the Chrome daily builds and plenty of blog posts about their new WebGL support around when testing some WebGL code.

As Google is well known for holding the bar of rigorous technical hiring standards very high, it’s probably safe to assume the content and support coming out of Google is best-in-class. Last June, Reto Meier also wrote a great post, “The Core Competencies of Developer Relations on this very subject. He says: … a thriving developer ecosystem needs a trusted Developer Relations team made up of engineers who are the interface between 3rd party developers and the engineering and product teams building the underlying platforms.” This perspective will surely enable experienced developers on their platforms, but it may be a bit intimidating to developers just getting started on their software and platforms.

Next up, let’s take a look at Apple’s best in class developer programs:

Apple’s developer outreach and developer relations are today considered by many to be best in class; just go to https://developer.apple.com/ to see how succinct, streamlined and efficient it is for developers to get the info they need – to a point. The point being their developer support ecosystem is deeply meshed to point developers straight to developing and submitting for their respective operating systems.


Education is a bit buried but it’s still there, and their interfaces to information are second to none. I think Apple does a very nice job welcoming beginners and newbies as well to their platforms and OS’s.

And now Microsoft:

Microsoft’s generic website is a tad disappointing from the developer relations perspective, but a quick search for “Microsoft developer relations site” brings Microsoft’s top hit to Microsoft Edge,

apertura-microsoft-edge (1)

Outside of Microsoft’s deserved success for the Visual Studio IDE product line, crafting clever marketing terms such as “Edge Dev” (when you really mean “developing with Microsoft for the Web”) adds unnecessary overhead for developers with challenged memories for trivia. Why not just call it “Microsoft Web Dev” or something easy to remember and find like that? The key word “Edge” is not particularly memorable.

In any case, finding Microsoft developer support and information is not hard, and probably useful enough, thanks to Microsoft supporting developers for decades, as well as being fairly ubiquitous in the software industry, but it’s not necessarily something to model a new 21st century developer support program on.

Last, but far from least, is Amazon’s developer relations and outreach found at https://developer.amazon.com/public/solutions and from where I clicked on “Getting Started,” shown in the screen shot below.


Amazon does a great job segmenting support portals for their various markets including platforms (e.g., PC/Mac, iOS, their own Android OS based Fire, HTML5, even game engines such as Unity), devices (e.g., Fire TV), to services (e.g., Alexa). Beyond that, but quickly findable from their developer home page, it’s easy to find resources such as API help, resources, and more support. Extra credit for their Flipboard style home page:


But what about that framework discussed earlier that takes advantage of marketing technology to support best practices for developer relations?

There is not much on the internet in the way of research on how to best manage your developer relations program but this data focused article may be helpful (from the London based agency Metia). Their report shows just how solitary is the work of a developer, how frequently they do the majority of their work from home, and how reluctant they can be to engage off-line, and if they do, it’s generally for key conferences and off-site training to enhance their learning. This holds true in the game development world in particular.

Some of the marketing industry’s best tools can be put to effective use in the developer relations discipline if these programs can be repurposed to bring together connections and content to support your (developer customers’) code development process.

Thanks to the enterprise cloud computing era we find ourselves in now, many of these “marketing tech” SaaS tools provide the perfect test bed for in-house management of developer relations best practices. If an organization approaches management of developer outreach and relations similarly to how it manages product launches, this may enhance the developer’s experience with the supporting company, as long as there is no resulting marketing-like overhead to the developer.

What kind of tools can help?

CRM tools are of course now ubiquitous, but CRM is not DRM (repurposed here to mean ‘developer relationship management’), but… there are times a combination of a few great tools can be close to what is needed. Whether it’s community (forum, bug/issue tracking), or content (SDKs, code snippets, white papers, FAQs, etc.), “there’s an app for that” – and usually the one your developer end-user wants is open source and cloud based. Similarly to cloud-based applications such as Salesforce being nearly ubiquitous for business development professionals, applications such as Github, Bugzilla, Slack, Trello, Jenkins, etc. are where developers turn to for code access and maintenance, bug-filing and tracking, communication, build support, and twitter, StackOverflow, Reddit, LinkedIn, etc. for community, education and help. You might even consider adding one or two good project or product management tools to the mix too if that makes sense. A nicely curated product management tools list can be found on Product Hunt but this Quora post has a more comprehensive list; still we found no applications specifically targeted at managing developer relations. Note there always seem to be plenty of project management tools as well. Capterra’s new 2016 list of top project management tools is probably worth a look if so inclined.

From this author’s personal experience, CRM tools like Salesforce, Eloqua and Marketo can all be customized, to a point, to support developer outreach and developer relations programs, but I have yet to come across any marketing technology tools used specifically in a developer relations capacity (in practice). Finding, tweaking and using the best tools you can find may help your organization create best practices for managing their developer relations team.

But what about hiring former developers as DevRel managers?

Too often (and with the best intentions), corporate managers tend to hire former and current developers for their developer relations team – and developers tend to do what they do best – write or tweak code. This is great and on the surface makes perfect sense, but it’s also important (even on a very limited HR hire budget) to hire at least one developer savvy marketing or business development professional. Today, many people in marketing or business have been working with engineers for years, and many have even dabbled in their own development projects. However, perhaps more important than technical ability or deep insight into the product is the skill to bring empathy and then trust to the table, coupled with the skills learned through years of marketing technical products. These skills, applied to developer outreach and relations, can be very valuable to the company’s stakeholders.

Experienced individuals who’ve worked in marketing for a while generally know well how to craft information in an engaging way, how to message it, and how to track results, but may not be as tuned in to the developer mindset as an experienced developer relations professional (with development experience). Joining the two together on a team can be very productive. A two-way symbiotic relationship between marketing and developer relations can bring out the best products for developers that are not merely self-serving the company’s bottom line – something we see all to often in marketing programs.

Marketing to engineers and software developers is growing increasingly more common as many new products entering the marketplace are for use online, in gaming or some kind of alternate or mixed reality space (e.g., AR/VR), all of which come with APIs/SDKs/ADKs and toolkits to access or enhance end users’ experience with the core product offering. Metia, mentioned earlier in this article, posted a blog on Venture Beat a while back that is particularly applicable to this article:Software CMOs, meet your toughest customer: developers.” Beyond documenting some of the obvious ways developers are more discerning from other non-engineering consumers, perhaps the best takeaway here is the fact that companies marketing to software developers need to be “… prepared for their enterprise-class expectations in terms of ease of use, documentation, service levels, and reliability.”

Think of it this way: assume the software developer has a need to absorb your true value-add in a faster, more coherent way than what any traditional marketing campaign can deliver, delivered in a way that is counter-intuitive to the usual hype, rhetoric, or splash of a traditional marketing campaign. Work with actual developers both in house, and outside, to craft your messaging and deliverables.

As the Metia blog post says, “The resources most highly valued by developers originated from product teams, including documentation, critical updates, SDK, sandbox, and test tools. The least valued — loyalty programs, vendor news, and product brochures — typically originate from marketing.”

Conclusion: get developers what they need when they need it; use marketing tools to help deliver and manage your efforts but leave those fancy go-to-market plans for the actual consumer end-user products.