18
Which Department Does Developer Relations Belong In?
The battle over which department Developer Relations belongs in continues to be long and ongoing.
Does DevRel belong in Product? Marketing? Engineering? Any of the above? None of the above?
Discussions — and arguments — over where DevRel 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 DevRel should report.
The thing is, the answer here is complex and nuanced. Developer Relations is so many disciplines combined. DevRel 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. DevRel 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?
I have worked in Developer Relations at four different companies. I have had countless conversations with peers in the industry regarding org structure, and where DevRel belongs in order to be successful and effective. In these conversations over the years, the often-repeated stance I kept hearing was that "DevRel 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 DevRel doesn't belong in Marketing? And why then, is DevRel very often in Marketing anyway?
Every company I've done DevRel at has had DevRel 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 DevRel 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 DevRel is such a new discipline, executive leadership doesn't understand the true purpose of DevRel. We've insisted that our leadership thinks DevRel is about pipeline, or lead gen, and doesn't get that it's something else.
But c'mon now. DevRel 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: DevRel 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 DevRel, 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 DevRel 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.)
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 builds 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, DevRel 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. We hope 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.
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. I want to be marketed tech products that are a pleasure to use, increase efficiency, and help me do my job. I encourage you: 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 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.
Whether your DevRel 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.
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 DevRel 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 DevRel 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. DevRel 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 DevRel. 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? DevRel 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).
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.
DevRel operates on the front line of this Developer Marketing philosophy. DevRel demonstrates how a company's products help developers enjoy architecting something they can then be proud of. DevRel can elevate champions in the community and be the friendly, helpful, knowledgeable faces of an organization.
DevRel 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, DevRel helps developers think through (or even build) an affordable alternative.
At the end of the day, no matter what department DevRel 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 DevRel 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, DevRel 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!).
18