31 December 2022
tl;dr: In my 2022 Tech Predictions, I asserted that more companies would be building DevRel teams, and I've repeated that in my 2023 Tech Predictions. I have reasons for that; I've been at many wildly-different companies, many of which with wildly different business models, and I've concluded that every company (that is in any way associated with software beyond a cursory level) in the post-2000 era has need of a Developer Relations department or organization. That said, DevRel is not the same at every company, and varies with the kind of things the company does to make money.
These are bold words, and often generate reactions ranging from quizzical to "are you trying to sell me something?". I stand by them, though, because every company in the post-2000 era that does something with software--whether they buy it, use it, or build it--engages with developers in some way, and therefore needs to relate to them.
If you're still willing to hear me out, let's revisit my definition of Developer Relations:
That part of the company that engages with developers, both internal and external to the company, for the purpose of using that relationship for net gain. This can take the form of many things, but ultimately, (a) it's aimed at developers, (b) it's intended to facilitate greater positivity to one or both sides, and (c) it centers around developer activities of one form or another (that is, it could be technical, "human skill", or process, but it kinda-sorta has to be around the world of software development).
Let's also consider a simple categorization of companies, according to my own (very biased) experience and perspective:
Developer-facing product companies. Your Microsofts, Googles, JetBrains, and so on. These companies make and sell products that are sold directly to developers, making them the target audience and the source of interest and income for the company. These are the ones that pioneered the Developer Relations concept, and for that reason, these are often the companies that come to mind when thinking about DevRel. Wikipedia calls these "Developer-First" companies, and says they have a "Business-to-Developer" (B2D) business model. This makes sense, although I think there's still value in thinking in terms of companies buying the developer-centric product, as opposed to developers buying it for themselves. (But maybe that's splitting hairs.)
Product companies where developers "value-add" indirectly. These are companies Consider, for a moment, one of my previous employers, Smartsheet. This is a product that does not sell directly to developers--in fact, it often finds itself in categories where professional developers are explicitly not allowed or desired (e.g., "low code" tools or "citizen developer" products). Wikipedia thinks of these as "Developer-Plus" companies, and thinks of them as business-to-business (B2B) or business-to-consumer (B2C) models, and says "While the primary focus of Developer-Plus companies is to create and sell products for businesses or consumers, they also make products or services available to developers which benefit or enhance their strategy including: opening new market channels, creating new use cases, contributing to innovation strategies, or optimizing/enhancing existing products."
Companies where integration is a key core of the business. Rocket Mortgage would fit this definition, since much of their ability to sell mortgages (which is clearly a non-developer-facing product!) depends on their ability to integrate with the other various financial players out in the world. Consumers won't see code, they won't touch code, but the value of the product will definitely grow (or shrink) depending on developers' ability to connect "our stuff to other peoples' stuff" (such as banks, escrow companies, title companies, credit organizations, and so on). It could be argued that this is more "Developer-Plus", but we're starting to stretch the definitions some here; for some companies, being able to provide integration capabilities is "table stakes" and means the difference between a partnership or sale and a waste of salespeoples' time.
Consulting companies. This is its own category primarily because there's so many of them, and they all have the same basic goal: Sell their developers to companies that either don't have developers, don't have enough developers, or don't have the right developers. The company's core business model is in putting their smart developer people to work for you, regardless of what sort of developer people you already have--either in conjunction with your smart developer people, or as a complement to your overworked developer people, or as leaders to your less-smart developer people, and so on.
Each of these companies needs a DevRel team, but for different reasons:
Developer-facing product companies. Pretty clearly the DevRel team's job here is a combination of marketing,sales (technical pre-sales, actually), and engineering:
For the most part, these are pretty self-descriptive, and I doubt most developer-types reading this would disagree strongly with this characterization.
Consulting companies. The consulting company needs DevRel because consulting companies that cannot convince potential clients of the consulting company's technical skills and apititude don't stay in business for very long. We are smart consultants! Your company needs us! Thus, the consulting company's DevRel team needs to:
Recruiting: In many consultancies, the best source of consultants is through the same venues and activities that DevRel engages--so consultants are encouraged to do those activities as a recruiting effort.
Note that in most consultancies, the current DevRel activities are generally done by the consultants themselves--Principals, Software Architects, senior consultants, and so on--but very, very few consultancies actually accept that this is a role in its own right, and most senior consultants who do this work do so during their non-billable time. In fact, even though most consultancies accept that Sales and Marketing are both activities that require being outside the umbrella of "billable hours", anything that requires technical skills means those Sales and Marketing folks have to beg time from consultants--who are in turn now caught on the horns of the "If I do this it's non-billable time, and my end-of-year bonus is tied directly to my billable time percentage, so either I sacrifice my bonus or I'm doing it off-the-clock as a volunteer effort."
NOTE: If you're a consultancy, stop doing this! Or, rather, consider how much more effective your company could be at finding and placing consultants if the people doing it were doing it full-time, just as your Sales and Marketing folks are. Not to mention the opportunities it gives you to rotate consultants through this team so that they get some experience doing something other than code--it helps grow the company in a variety of ways.
If you can think of a company that's larger than a thousand people in size, there's a good (better than 50%) chance that that company has an API. Even a soft drink manufacturer has an API. Chances are strong that your executive team has been looking for ways to turn your company into a "tech company" and provide a "platform" for people to build with. (By the way, most executives have no idea what that platform should be or look like, they only know they need one. Talk to me if you're an executive and want to figure out what one for your company should look like and provide.) Even if you're not looking to build a public API, chances are even stronger that you're building a private one--which means you need a DevRel team.
Companies where integration is a key core of the business. You're not Ford, you're a bank or some form of B2B business, where the company's main line of product requires integration to work or optimize. A lot more companies are in this bucket than you might imagine--airlines, for example, are always looking at various other systems they want or need to integrate with, starting with other airlines (as they share loyalty programs, for example), rental car companies, hotel chains, and other players in the travel industry. If the business is a restaurant chain, developers can make use of APIs to automate the supply chain, tying the restaurant's inventory to orders, for example.
Here, the company's goals are to build developer tooling that makes it as easy as possible for other companies' IT to mesh with their own, to enable the integration scenarios that every CEO dreams about. That means building the platform that has copious entry and exit points, dozens of ways for integration to occur, and a plethora of documentation for the integration partners' developers to consume while working to make everything work. And the Developer Relations team will be squarely at the center of it all (working, ideally, with the integration partners' DevRel teams, because their CEOs all read this article, too).
Now, keep in mind that when I talk about the role of developer relations, I'm not just speaking of the activities of developer advocates; a modern DevRel team will have a variety of different folks on a DevRel team, and in many cases those activities will be different for the different roles on the team. DevAds will often go and speak at conferences, for example, whereas Technical Community Managers will be taking more of the social media management on themselves, while Technical Content Engineers will be focusing on content creation (such as documentation, videos, and so on), and Developer Support Engineers will be the first line of support for external developers, and so on. These roles overlap, to be sure, but it's the rare case where one person will do everything. (Frankly, those cases should probably be reserved for those companies that are just getting started and need somebody to kick things off in the DevRel space--just like the startup's technical co-founder writes the code, builds the website, manages the bugs, and so on. Over time, you need to scale up and out, and that means more people.)
Every company that uses software, needs Developer Relations.
Last modified 31 December 2022