08 January 2023

tl;dr: The Developer Relations org isn't exactly Engineering, but it's not entirely Marketing, and it often isn't really Sales. So if you're a company looking to find a home for your nascent (or currently-existing) DevRel team, where do you put it?

Let's consider some of the traditional places a DevRel team appears first.


This often seems like the most natural place for a Developer Relations team--after all, developer advocates often come from engineering backgrounds, most DevRel activities involve code in various ways, and, after all, their target audience usually work in Engineering departments themselves, so.... This is the right place to put them, right?

Unfortunately, while this might be a reaonsable second choice, it's not ideal. Engineering teams' sense of success is to ship things, often "at scale", and that mentality often carries over into the DevRel team, leading the goals of the team to be centered around shipping things (blog posts, code samples, etc). Worse, the emphasis of "scale" leads engineering management to concentrate on actions that reach the largest number of recipients, regardless of the quality of the connection. DevRel needs to be a loop, connecting with developers outside the company, and bringing that information back around internally and the team can't do that if the conversations are always one-way with little to no loopback.

"But, what about things like documentation, samples, tutorials, and so on?" These are all good things that need to be done, particularly if the company promotes a product or an API (whether that's the principal item for sale or not), but these can be done by Technical Content Creators, such as Technical Writers do for documentation.

DevRel inside Marketing

It's a common place to put the DevRel team, particularly in developer tools/products/services companies. The reasoning here is pretty straightforward: if the company wants to connect with developers in order to convince them to buy/use the "thing" (the tool/product/service), put them in the Marketing team and let them do the Marketing things to attract them. Go to conferences, write the blogs, but more importantly, go out there and show off the "thing" and get developers excited about it.

It's not optimal to put the team here, though, for a variety of reasons.

Marketing is often a "one-way" exercise, the goal being to create awareness of the product and bring them to the "top of the funnel" (meaning the "sales funnel", the euphemism for the collection of people who move through the process around purchasing a product). Developer "relations" means having a relationship with the developer community, not just talking at them.

Practically speaking, the goals of the Marketing team will often differ in substance from what a DevRel team needs to do. For example, Marketing's metrics will often revolve around "page hits" or "eyeballs" or "site stickiness", all of which revolve around the number of people and amount of time that arrive at the website or booth to find out more information. There's little to zero measurement around the depth of the connection, and even less emphasis on taking the feedback from the developer community.

What's more, the lines of communication between the Marketing team and the Engineering team are often quite "distant". If the DevRel team cannot get feedback from the developer community outside the company to the developer community inside the company, then they're not really "relating" to developers anymore, and they're really just Technology Marketing or Developer Marketing.

SIDEBAR: The bigger the distance between any two nodes in the organization chart tree, the harder it is to communicate on a regular basis. By this, I mean, if Alice and Bob both report to Mary, their distance is 0 from each other; if they both don't report to somebody until reaching the CEO on the org chart, then they're essentially at opposite ends of the Earth from one another. That distance makes it nearly impossible to set up a regular conversation, because the day-to-day of those two orgs is enough to create organizational resistance in a variety of ways. Try it if you don't believe me sometime--set up a regular recurring 1:1 with somebody from Legal or somebody from the shop floor or some other department that's miles and miles away from you on the org chart, and see how long your 1:1 lasts.

While it makes sense for the DevRel team to be in constant communication and alignment with the Marketing team, DevRel needs to be independent enough to not be held to 'top-of-funnel metrics' and instead held accountable to things that promote total engagement with developers.

DevRel inside Sales

In some organizations, particlarly the ones that sell products/services to developers, there's a natural tendency to put the DevRel team in Sales, since the DevRel team relates to developers, and the target demographic for buying the product or service is developers, and DevRel team members are developers, so.... Natural fit, right?

Oh my goodness, no.

First off, developers grow up to learn a pathological distrust--if not downright dislike--of anything that smells like Sales. Let's be honest, a lot of that is learned behavior from their predecessors (aka me and my generation), which may not be fair. (Probably isn't fair, to be honest.) Part of that distrust stems from sleazy Sales campaigns that my generation was exposed to; I still remember the day the Symantec Java IDE hit the streets and its salespeople boasted--without a hint of caution or hesitation--that their IDE would enable a "400% productivity boost" just by using their IDE instead of any of their competitors. It was complete and utter fabrication with zero basis in reality, but it's not the first time--nor will it be the last--that a sales pitch aimed at words like "productivity" or "scalability" or "cost savings" as tangible reasons to purchase a product. Salespeople have an unwholesome reputation, that they will say or do anything to "close the deal", regardless of the factual accuracy of what's being said, and developers want zero part of that.

When the DevRel team goes out into the community to connect with the community, they need to build relationships based on a basis of mutual trust: That I as a DevRel, I'm a developer too, and I know where you're coming from and I'm here to help you be better at what you do. Theoretically, salespeople should be coming from a similar perspective in a variety of other domains; it's why we have commercials in which we see people facing the camera talking about the product--you're supposed to empathize with who they are, either because they're who you are, or they're who you want to be. When that trust breaks down, then the messaging is entirely lost. In fact, if that trust breaks down far enough, it itself becomes an obstacle to the sale; for years, I told people to steer well clear of the Symantec IDE just because I was so disgusted with that sales tactic.

In many scenarios, a developer-type individual can go in to a sales call as a supporting character to the salesperson's meeting. This is the world of Technical Sales, and in many cases is used to help flesh out the details of the product and/or provide reassurance of what the product can and cannot do, particularly if it's a deeply-technical product. So long as the salesperson/TechSales tandem is in sync with one another, having the TechSales there, keeping the conversation "honest" and being forthright about the details, creates a deeper sense of trust between the buyer and the salesperson, and enables deals where it otherwise would fall apart. And Dev Advocates can certainly take the role TechSales for that meeting--any Dev Advocate who's been in the industry for more than a half-decade has done that at least once--but it's not at the forefront of their job description, and it should never be anything more than a supporting role in the sales process.

Again, if we consider the metrics, salespeople often fall under the ultimate metric: commission. And if your DevRel team falls under that metric umbrella, they're not going to be concerned with building trust in the community (and making it easier to land sales), they're going to be held accountable to going out and making sales of their own. It completely undermines their ability to build relationships, and reduces them to the transactional mindset that permeates sales organizations so deeply. And most relationships--whether professional or personal--fall apart under even the tiniest stress when reduced entirely to a transactional basis.

DevRel inside HR

Believe it or not, a (admittedly small minority) group of folks think the DevRel team belongs inside the same organization that handles recruiting. "If the DevRel team is about building relationships with technology communities," the thinking goes, "Then it makes sense to think of them as an adjunct to our other department that provides resources to the humans of the company."

On the one hand, there is something to this argument. Frequently, the most powerful recruiting team in the company is the DevRel team--they are out and about in the community, they speak the same language as the developers the company is courting, and they have the trust of fellow developers that recruiters (sadly) lack within that crowd. It's a very strong advertisement: An attendee has just seen a Dev Advocate give an amazing talk at a conference, thinking, "This person is one of the Cool Kids!", and when they get to the booth, they find out that Dev Advocate's company is hiring, and thinks, "I want to go work where the Cool Kids work!" Many are the stories of a prominent open-source developer being recruited by one of the FAANGs because the conversation started at a conference, with one of the Dev Advocates, who could "walk" them to the right hiring manager or recruiter.

Additionally, if the DevRel team is being faithful to its charter, it is looking to connect with not only the developers outside the company, but also the developers within the company. In some companies, the DevRel team takes on some of the internal developer relationship activities, such as scheduling and arranging internal conferences or meetups, or acts as the point of contact for acquiring training for an internal team. (After all, the Dev Advocates are out and about in the community, rubbing shoulders with the people writing the books and recording the videos, so they'll be best-positioned to know who the right people are if we want "only the best" for our internal training needs. And we do want only the best, right?)

Unfortunately, while these are both important aspects to the DevRel team, we still fall afoul of many of the same previous arguments: the metrics in HR are often entirely "out of whack" compared to those we'd like to see for a DevRel team, and the HR team is a little too far removed from Engineering, Marketing, or Sales, for the DevRel team to be effective at accomplishing its other goals.

Even worse, in a lot of companies, the HR team is a cost center, meaning the company is looking to keep the costs involved to a minimum. DevRel activities require budget--conference sponsorships, conference participation, hosting for blogs--and time--for samples, tutorials, posts, videos, and so on--that are critical to the DevRel team's success, yet don't fit in to traditional HR targets. Over time, the DevRel team becomes less and less "technical" and more and more "organizational", and the participants end up being Technology Trainers or Technical Recruiters.

DevRel inside the Office of the CTO

Companies which have had sub-optimal success with the DevRel team in any of the three above locations often cast about in some consternation--where do we put a team whose amibitions and activities don't closely align with neither Engineering, nor Marketing, nor Sales? How many other departments are left?

In many cases, particularly younger companies (aka "startups", though many companies characterized as such have long left their startup days behind them), the CTO takes a personal interest in seeing a DevRel team chartered and founded. The CTO has oversight over a number things, all of them related to "Technology", so it seems to reason out that the team should be part of the CTO's "pet project division", often known as the "Office of the CTO" (or OCTO).

And, truthfully, in the early days, the team performs well here. They have a direct line to Engineering through the CTO, and the CTO can sponsor their inclusion in activities that bring them close to Marketing and Sales; the Marketing teams often need to consult the CTO on messaging for the technology things the company is doing, and Sales will often reach out to the CTO for the Technical Sales support it needs in tough sales cycles. They can also work closely with Recruiting to help hit recruiting targets.

Seems like a perfect fit!

Ironically, the fact that the OCTO gives the DevRel team to be flexible and free also often undermines the team's long-term success. So long as the CTO is personally engaged in seeing the team succeed, the DevRel team can do some good things, but without the CTO's constant support, they often start to lose momentum and ground, and eventually wither away, because the rest of the company doesn't know how to interact with them on an organizational footing.

Each department within an organization needs to know how to interact with its peer organizations, and often this is done (somewhat indirectly) through the establishment of processes and metrics. Departments hold each other indirectly (and sometimes directly) accountable through these: Marketing needed a feature, so it used an internal process to put it on Engineering's backlog, who then connected with Sales to see how the feature was received, all of this described and measured via a variety of metrics to help with decision-making. When the DevRel team is a "special project" of the CTO's, those processes and metrics have a tendency to be short-circuited, in the interests of making the CTO happy, and the rest of the company never quite gets into a rhythm of where and how DevRel fits in.

Then--as inevitably happens--when the CTO no longer is putting the DevRel team on their "short list" of personal projects, either because the team has been around long enough that it feels like they should be able to survive "on their own", or because the CTO has moved on and a new CTO is now prioritizing other things, the DevRel team has lost their sponsor and suddenly they have a short window in which to figure out where and how they fit into the organizational mix.

DevRel goes... where, then?

The DevRel organization's goals are not the same as Engineering's goals, nor are they aligned perfectly with Marketing's or Sales'. It isn't unusual for organizations to "break out" of one or another this way--a long time ago, Marketing and Sales used to be unified into a single organization, until the realization became widespread that their goals were different. The same often happens with the Public Relations team (now often referred to as "Communications" or "Comms"), which has deep ties to Marketing, Sales, but also Legal and HR. Legal used to be buried inside of Operations. And so on. Each top-level organization should be (needs to be) able to pursue its goals independent of the others, and the leader at the top of that organization needs to be able to meet with peers to accomplish this.

If the goal of the DevRel team isn't completely aligned with any of Engineering, Marketing, or Sales, then where in the organization does it go? The conclusion drawn here is actually not surprising, once we stop to think about it: Developer Relations deserves to be its own top-level organization within the company.

Just as companies are realizing the benefits of having a "Chief Marketing Officer" and a "Chief Communications Officer" and a "Chief Information Security Officer", a "Chief Developer Relations Officer" reporting directly to the CEO and providing the guidance and leadership to the CxO suite around the art and science of Developer Relations makes sense. Alternatively, if the "CDRO" title seems a touch pretentious, and the company lacks a CMO or CISO, then it's probably more appropriate to call it a "VP, Developer Relations", again reporting directly to the CEO or CTO as a peer to the VP of Marketing, VP of Sales, and VP of Engineering. (Who reports to whom depends on the organization, but in general the VPs all end up sitting in the same room together anyway, so at that point it's a little moot.)

This is not to say that DevRel is ever going to be at the same size as any of the others--it's hard to imagine a DevRel team that will span hundreds, much less thousands, of individuals. But the same is actually true of a lot of departments within an organization. Legal, for example, is generally not going to be hundreds of people in size except in the largest of companies. PR, similarly, can be made up of a dozen folks supporting thousands or tens of thousands.

The DevRel team being at a level reporting directly into the C-Suite means that now the CDRO or VP of DevRel establishes high-level goals and metric targets suitable for the team, but in conjunction with the overall goals of the company as a whole. If the company needs to make a major Marketing push because Engineering is releasing a new version, DevRel can adjust goals to provide tutorials and samples, as well as work directly with Marketing to get the Dev Advocates out into conferences and podcasts to talk about the new release and features. It can allocate some time to go with the Sales folks to help sell the new version. And so on. By allowing the DevRel team to draw its own goals and objectives--not to mention argue for its own budget and headcount alongside those teams--in direct consultation with its peers in Engineering, Sales, Marketing, HR, and the CEO and CTO, the DevRel team establishes itself as a team player with a clear mission and well-understood set of activities and metrics.

Every company needs a DevRel team, and it's high time we saw the importance of the developer community as large enough to merit its own organization dedicated to interact and grow with it.

Tags: devrel   management  

Last modified 08 January 2023