Which Department Does Developer Relations Belong In?
The battle over which department Developer Relations belongs in continues to be long and ongoing.
Does Developer Relations belong in Product? Marketing? Engineering? Any of the above? None of the above? How do company details factor in?
Discussions — and arguments — over where Developer Relations should align in an organization often become heated and passionate. Many practitioners have very strong feelings about this, occasionally holding views that are not aligned with where their organization’s executive leadership believes Developer Relations should report.
The thing is, the answer here is complex and nuanced. Developer Relations is so many disciplines combined. Developer Relations is about:
- Connecting with developer users and audiences
- Cultivating, growing, and nurturing developer communities
- Advocating on behalf of developers to make better products with a great developer experience
- Advocating on behalf of the organization to bring products to more developer users
- Understanding the product on a deep, technical level and providing education, resources, and support to developers
- Engineering demos, samples, real world repos, code tutorials, etc.
- …and so, so much more
These goals and responsibilities fit into several different “segments” of a typical tech organization. Developer Relations also needs resources, cooperation, and collaboration across many teams and departments in order to be successful.
So the question repeatedly arises: where does Developer Relations belong in an organization?
Well, the answer isn’t simple. It depends entirely on the organization.
I have worked in Developer Relations at many different companies. I have had countless conversations with peers in the industry regarding org structure, and where Developer Relations belongs in order to be successful and effective. In these conversations over the years, the often-repeated stance I kept hearing was that “Developer Relations shouldn’t be in Marketing.”
I have heard this dozens of times. I have said it myself in the past.
But why?
Why do we keep insisting that Developer Relations doesn’t belong in Marketing? And why then, is DevRel very often in Marketing anyway?
First Ask This: Is Your Core Product for Developers?
To ensure we’re on the same page, let’s consider two different types of companies:
- Companies whose primary product is targeted at developer users
- Companies whose primary product is B2C, B2E, or B2C and is supported by technical integrations, SDKs, and APIs that are used by developers (but developers are not the target customers themselves)
In organizations where the primary product offering is not directly solving a problem that developers have, then Developer Relations often fits better in Product or Engineering (or a cross-functional combination of both). In this case, business revenue and product adoption is not dependent on developers. Instead, developer mindshare and growth is high on the list of concerns for specific departments within the organization (chiefly Engineering and Product, possibly Technical Support and Developer Success), but it doesn’t drive the core business financially. In this case, Developer Relations is often focused on the developer experience, growth and development of developer libraries, SDKs, and tools, spreading the word, and advocating on behalf of the developer to the company in actionable and meaningful ways.
For companies who provide a product that requires developers to adopt and use, the story can be a little bit different. Developer-led companies are the ones I’m going to discuss in more detail today.
Myth: “Leadership Doesn’t Understand Developer Relations”
Every developer-focused company I’ve done Developer Relations at has had the team in the Marketing org. Why would companies do this if it was not appropriate? As practitioners of Developer Relations, do we actually believe that our employers would put so much money, care, and sheer effort into hiring Developer Relations teams and providing them with substantial financial resources if they didn’t understand the reasons behind having DevRel in the first place?
For years, we’ve claimed that Developer Relations is such a new discipline, executive leadership doesn’t understand its true purpose. We’ve insisted that our leadership thinks Developer Relations is about pipeline, or lead gen, and doesn’t get that it’s something else.
But Developer Relations is no longer a new discipline in tech. Company leaders are not hiring DevRel teams without understanding what they mean and what their goals are. They aren’t doing it because their competitors have DevRel teams. Hundreds of thousands — even millions — of dollars are poured into DevRel teams. Org leaders do not do that carelessly. They do not do that if they don’t understand what they’re doing it for.
It’s time to give our executive leadership more credit than that. And it’s an exciting time: Developer Relations has matured to the point now that there are executive DevRel roles. Developer Relations, as a key discipline, has earned its place at the leadership table.
The old argument of “my org’s leadership doesn’t understand Developer Relations, that’s why they put us in Marketing” no longer stands up under scrutiny. It is still true in some companies, but I would strongly encourage folks who are looking for DevRel roles to vet potential employers carefully during an interview process to determine if the greater understanding of DevRel is shared by leadership. (Just ask “what does developer relations mean to your company?” and you’ll get your answer. If there’s not alignment between the answer and your fundamental philosophy, it might be a sign to pass and look elsewhere!)
Myth: “Developer Relations Isn’t About Making Money”
Weeelll…
That’s untrue. It’s untrue because (unless you work for a nonprofit) every team at a tech product company exists to make money. Engineering and Product create, build, and ship products to make money. Design designs products to make money. Marketing promotes products to make money. Sales sells products to make money. Investors invest in startups to make money. Companies raise funding to eventually become profitable (a.k.a. make money). And yes, Developer Relations educates and shares and helps to — you guessed it — make money.
In DevRel, we sometimes like to say that we aren’t “selling” the product. But that isn’t entirely accurate. When we evangelize a technology — even an open source one — we are selling people on the idea that a technology or product can help them or make their work better / easier / faster / etc. While that isn’t Sales in the classic sense, it is about encouraging people to choose to use something in order to improve their lives in some way.
And that is the crux of Top of Funnel marketing. We want to increase brand awareness. Our team hopes the developers we reach will choose to use our products. We hope they have a great experience with us and want to continue to be users of our products. And we hope that, at some point, they will get enough benefit and value out of the product that they consider it very worth paying for.
Myth: “Developers Hate Marketing”
This blanket statement is not true either. A more accurate statement might be: “Developers are good at detecting BS.” As we should be!
We developers are consumers too. We consume products, watch ads (okay, mostly when forced to), glance at sponsored content, read signs in shop windows, and check out sponsor halls at conferences.
I — as a human being and also as a developer — want to be told about products and technology that can make my life better. It’s in my best interests to discover new tech products and developer tools that are a pleasure to use, increase efficiency, and help me do my job. Please do your best to market to my interests! I’m a tough crowd, but I welcome it. And I’m more than happy to pay for your product — if it’s worth it.
The notion that “developers hate marketing” is really just an oversimplification. The misconception that marketing is inherently insidious or disingenuous is where this idea goes seriously astray; and that’s why DevRel’s role in Developer Marketing is so pivotal at companies that make developer tools or software.
Developer Relations 💙 Developer Marketing at Developer-First Companies
Whether your Developer Relations team reports to Product, Engineering, Marketing, directly to the founders, or elsewhere in the organization, DevRel is — at its core — Developer Marketing.
This is a good thing. And it’s time for us to recognize and acknowledge that it’s a good thing.
At developer-first product companies, Marketing is a great place for Developer Relations. I want to make this distinction very clear though: when a company’s primary objective and business model is centered on creating software or tools for developers, the understanding of Developer Relations comes from the top down. Open Source or developer software companies have a prime directive that focuses on developer satisfaction, adoption, and happiness. At these companies, DevRel being in Marketing makes sense.
Note: At companies in other product sectors, it may make much less sense for DevRel to be in Marketing. If your company sells a consumer product, B2B, or B2E — and you also provide APIs, etc., then DevRel may serve much better in Engineering or Product. I have worked at multiple product-led companies where DevRel is in Product, and it’s the perfect fit at those particular organizations.
DevRel in Marketing at developer-first companies can work well for several reasons:
Marketing has a deep-rooted, cooperative relationship with Product. Espoused in the discipline of Product Marketing, Marketing as an organizational powerhouse has an intimate but also holistic knowledge of what’s going on in Product and Engineering: what features are being developed, what’s happening when, who the primary users would be, what user research is being done, how should the product be presented to the market, etc.
Marketing has budget for the types of things Developer Relations teams do. DevRel is expensive! Sponsorships, swag, airfare, hotels, streaming, recording, production, running programs and campaigns, etc. cost a lot of money. Marketing is generally allocated significant budgets for exactly these types of things. If Developer Relations is in Engineering or Product, DevRel teams may struggle with obtaining enough budget for things like big sponsorships, sweepstakes prizes, etc. since DevRel activities may not be well incorporated into the bottom line for how the department’s performance is typically measured (but of course, YMMV).
Marketing is data-driven. Developer Relations is notoriously “hard to measure” — but is it really? Marketing organizations are data-driven, and operate with growth in mind. Having ready access to metrics like attribution, website and blog traffic, npm traffic, signups, trials, HubSpot, Twitter, YouTube, Twitch, competitive analytics, etc. can be quite beneficial for plotting a course for increasing DevRel performance, engagement, and adoption. Working alongside Marketing teams like Data, Brand, and Growth can make a huge difference in enabling DevRel to gather, predict, and respond to a broad spectrum of data regarding how a company interacts with users and potential users.
Marketing operates with a growth mindset, and thrives on experimentation. Experimentation and testing different strategies and tactics is par for the course for a Marketing organization. And experimentation is a crucial component of Developer Relations. Testing different DevRel strategies, programs, and campaigns is a mode of operations that Marketing supports, encourages, and has the means to execute quickly. Pivoting on a dime won’t shock Marketing leadership, and unsuccessful experiments result in good learning experiences, not reprimand or backlash.
Marketing owns the strategy around how a product is delivered to an audience. Different types of products require different GTM (Go To Market) strategies. Open source software release? Developer Relations can be out ahead of that: connecting with OSS devs, running interference on GitHub, holding demo livestreams and office hours, doing talks at events, and more. Big commercial release? Maybe DevRel supports Product Marketing by hosting technical demos, sharing access to new features with community champions, arranging impactful event sponsorships, and forwarding booth inquiries to Sales. DevRel is an integral part of GTM, and being in Marketing enables DevRel teams to have ownership over their role and responsibilities when product releases go public. Some DevRel teams in Marketing wrote and own the entire GTM strategy and process for OSS launches.
These are just a few examples of how DevRel fits well into a Marketing org. There are many more (e.g., working closely with Content Marketing, Brand, Growth, Social Media, Partners, Marketing Engineering, Data, Demand Generation… the list goes on).
Developer Marketing Core Philosophy
My core philosophy around Developer Marketing is concerned with three primary tenets:
- Be Genuine
- Build Trust
- Deliver Value
Developers want their work to go smoothly, be efficient, and be interesting; there’s a nuanced difference between this and wanting things to simply be “easy.” Developers are interested in technology that enables these things, and allows them to do work that they are then proud of and feel good about.
Being genuine and building trust are of tantamount importance at an ethical level. Companies that focus on this are going to be more successful. Developer Relations is the piece of the organization that most strongly embodies this, and cultivates relationships built on clarity and trust with the developer community.
Then put your money where your mouth is: Developer Relations is about delivering value to developers. Back up words with actions: share knowledge, take feedback, make things happen as a result.
This is what marketing to developers is about: are we offering something that is genuinely useful? Is it helpful? Does it improve life for developers, and for their teams? Does it have a great developer user experience? If yes, developers are going to be open to trying it, building a relationship with a technology or brand, and becoming practitioners.
Developer Relations is About Relationships, Not Sales
Developer Relations operates on the front line of this Developer Marketing philosophy. A Developer Relations team works to demonstrate how a company’s products help developers enjoy architecting something they can then be proud of. It can elevate champions in the community and be the friendly, helpful, knowledgeable faces of an organization.
Developer Relations is also uniquely positioned to be truly genuine with developers. Is the product not the best suited for someone’s situation? DevRel folks can outright say so! They can offer other solutions, and clarify when and how their company’s products help — and when they don’t. Unable to afford a commercial add-on from a company, but like to use their open source offerings? DevRel won’t say “come back when you have the money.” Instead, developer advocates help developers think through (or even build) an affordable alternative.
Developer Relations is Cross-Functional
At the end of the day, no matter what department Developer Relations lives in (or if DevRel is its own department or reports to the Office of the CEO), DevRel is a heavily cross-functional discipline.
An effective Developer Relations team does not only build relationships with the community outside the company: it also builds relationships and collaborations within the company and many — if not most — of the other departments.
For this reason, Developer Relations teams in Marketing have an advantage: Marketing departments have cohesive relationships with a lot of the rest of the organization already (Product, Customer Success, Support, Sales, Engineering, etc.). The teams within Marketing are also key collaborators in DevRel’s goals and mission (as discussed above), and working alongside them on a daily basis empowers DevRel to position itself optimally to have great reach and influence.
So no matter what formal department your DevRel team lives in, Developer Relations as a discipline should follow the tenets that guide good Developer Marketing: be genuine, build trust, deliver value, and have fun bringing cool things to devs to make their lives better (and maybe even make money while doing it!).
