Which Department Does Developer Relations Belong In?  ## Metadata - Author: [[DEV Community]] - Full Title: Which Department Does Developer Relations Belong In? - Category: #articles - Document Note: ## 📜 Summarize: This article discusses the ongoing debate about where Developer Relations (DevRel) belongs within an organization. The author highlights that DevRel involves multiple disciplines, including connecting with developers, nurturing communities, advocating for better products, providing technical education, and more. The complexity of DevRel's responsibilities often leads to disagreements over which department it should align with: Product, Marketing, Engineering, or other teams. The article challenges the common belief that DevRel shouldn't be in Marketing, asserting that executive leadership generally understands the purpose of DevRel and invests resources accordingly. It also dispels myths that DevRel is not about making money and that developers inherently hate marketing. The author emphasizes the crucial role of Developer Relations as a form of Developer Marketing in developer-first companies, where it fosters genuine relationships, builds trust, and delivers value to developers. ## 📝 Bullet Points: - DevRel is a multifaceted discipline that encompasses various responsibilities, such as community building, advocating for developers, and providing technical support and education. - The ongoing debate centers around where DevRel should belong in an organization, leading to passionate discussions and differing views among practitioners and executive leadership. - The article dispels the myth that executive leadership doesn't understand DevRel, pointing out that DevRel is no longer a new discipline, and organizations invest significantly in its teams. - Another myth addressed is that DevRel isn't about making money, but in reality, every team in a tech product company exists to generate revenue, including Developer Relations. - Developers don't inherently hate marketing; instead, they appreciate genuine marketing efforts that deliver value and improve their lives. - In developer-first companies, DevRel aligns well with Marketing due to shared goals, budgets, data-driven approaches, and a focus on experimentation and growth. - The core philosophy of Developer Marketing involves being genuine, building trust, and delivering value to developers, which fosters successful relationships. - DevRel plays a crucial role as a friendly, helpful, and knowledgeable face of an organization, genuinely assisting developers and elevating community champions. - DevRel is a cross-functional discipline, building relationships both outside and within the company, making it advantageous to be part of Marketing, which already collaborates with various departments. ## 📜 Paraphrase: 1. **DevRel and Leadership Understanding**: The article challenges the common perception that executive leadership doesn't truly understand Developer Relations. Although DevRel was once considered a new discipline, it has now matured, and organizations invest considerable resources in their DevRel teams. This indicates that leadership comprehends the value of DevRel and its role in supporting developers and improving product experiences. Instead of assuming that leadership is unaware of DevRel's purpose, the author encourages job seekers to ask potential employers about their understanding of DevRel during the interview process to ensure alignment with their own philosophy. 2. **DevRel's Role in Marketing**: The article emphasizes that Developer Relations is, at its core, a form of Developer Marketing, particularly suitable for developer-first product companies. In such companies, the primary focus is on creating software or tools for developers, making Marketing an ideal fit for DevRel. Marketing departments have well-established relationships with other key departments like Product, Customer Success, Support, Sales, and Engineering. They also possess budgets and resources that align with DevRel activities such as sponsorships, swag, and campaigns. Being part of Marketing enables DevRel to access valuable data-driven insights, experiment with different strategies, and take ownership of the Go To Market (GTM) process for product releases. ## 📝 Conclusion: The article dives into the ongoing debate about the placement of Developer Relations (DevRel) within organizations. It challenges common myths and perceptions surrounding DevRel, such as the idea that leadership doesn't understand its purpose and that it isn't about making money. Instead, the author asserts that executive leadership generally comprehends the value of DevRel and invests significantly in its success. In developer-first companies, DevRel finds a suitable home in Marketing due to shared goals, budgets, and a data-driven, experimental approach. ## ❓ Questions: 1. How can companies effectively balance the responsibilities of DevRel across different departments, considering its multifaceted nature? 2. In organizations where DevRel is not in Marketing, what challenges might arise regarding budget allocation and access to data-driven insights? 3. How can DevRel teams ensure that their marketing efforts are genuine and build trust with developers, as suggested in the core philosophy of Developer Marketing? 4. What are some successful strategies DevRel teams can employ to maintain open and honest relationships with developers while representing their organizations' products? 5. How can Developer Relations professionals effectively measure their impact and success, especially when traditional metrics may not fully capture their contributions? ## 🏷️ Auto-tagging: Developer Relations, DevRel, Developer Marketing, Organizations, Leadership, Myth Debunking, Genuine Relationships, Cross-Functional Collaboration, Data-Driven Marketing, Experimentation, Go To Market (GTM) Strategy, Budget Allocation. ## 📚 Index Creation: - Developer Relations: Page 1 - Developer Relations Placement Debate: Page 1 - DevRel Responsibilities: Page 1 - DevRel in Marketing: Page 2 - Leadership Understanding of DevRel: Page 2 - Myth: Leadership Misunderstands DevRel: Page 2 - Myth: DevRel Isn't About Making Money: Page 3 - Myth: Developers Hate Marketing: Page 3 - Developer Marketing Core Philosophy: Page 4 - Tenet 1: Be Genuine: Page 4 - Tenet 2: Build Trust: Page 4 - Tenet 3: Deliver Value: Page 4 - DevRel and Relationships: Page 5 - DevRel in Cross-Functional Settings: Page 5 ## 📑 Table of Contents: 1. Introduction 2. Debunking Myths Surrounding DevRel Placement - Leadership's Understanding of DevRel - DevRel's Role in Making Money - Developers' Attitude Towards Marketing 3. Developer Relations in Marketing: A Fitting Alliance - Core Philosophy of Developer Marketing - DevRel as a Genuine and Trustworthy Face - The Cross-Functional Nature of DevRel 4. Conclusion 5. References ## 📚 References: - [Link to article or source 1] - [Link to article or source 2] - [Link to article or source 3] ## 🔍 Future Research: 1. Investigate and compare the effectiveness of Developer Relations teams placed in different departments (e.g., Marketing, Product, Engineering) to determine which arrangement yields better outcomes for developers and the organization. 2. Conduct a longitudinal study to track the development and growth of Developer Relations as a discipline over time, exploring its impact on open-source communities and commercial product adoption. 3. Analyze successful Developer Relations case studies to identify best practices for building genuine relationships with developers, fostering trust, and delivering valuable experiences. 4. Explore the role of data-driven marketing in Developer Relations, examining how data-driven insights can influence decision-making and improve engagement with developer communities. 5. Conduct surveys and interviews with developers to gain a better understanding of their perceptions and preferences regarding marketing efforts, identifying key factors that contribute to successful marketing in the developer community. ## 🔬 Hypotheses for Future Studies: 1. Hypothesis 1: Developer Relations teams placed in Marketing departments will demonstrate higher levels of collaboration with other departments and have greater access to Abstract: This paper looks into the question of which department deve - Document Tags: [[devrel]] - Summary: The battle over which department Developer Relations belongs in continues to be long and... - URL: https://dev.to/kimmaida/which-department-does-devrel-belong-in-3om The battle over which department [Developer Relations](https://dev.to/kimmaida/the-developer-relations-explainer-431o) 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*? #### Myth: "Leadership Doesn't Understand DevRel" 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.) #### Myth: "DevRel 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 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](https://blog.taboola.com/effectively-top-funnel-marketing/#:~:text=Top%20of%20the%20funnel%20marketing%20refers%20to%20the%20first%20stage,hopefully%2C%20eventually%2C%20become%20customers.). 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. #### 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. 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. #### Developer Relations 💙 Developer Marketing at Developer-First Companies 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). #### 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 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. #### Developer Relations is Cross-Functional 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!)., Which Department Does Developer Relations Belong In?, DEV Community, 01gtw5y8m8y2h1g98jt80kze69.