When structuring a DevRel team within a tech company, the question of where to position it often sparks debate. Should it report to marketing, engineering, product, or sales? Alternatively, should it stand as its own entity under the executive team? Each option has its own set of pros and cons, depending on the company's structure and culture.
In this post, we’ll explore these options, discussing their advantages and pitfalls while offering practical recommendations for each. These insights are drawn from the collective experiences of Bianca, Tessa, Brendan, and Michiel, who have worked in various DevRel roles across different industries and organizations.
>> Have you read Tessa Kriesel’s earlier post in this series, “Developer Relations: Trust is Built in the Trenches, Not Through Marketing”?
Option 1: DevRel Under Marketing
When DevRel is positioned under marketing, it often benefits from closer ties to marketing resources. The marketing team is well-equipped to amplify DevRel’s work. However, placing the DevRel team under the marketing team can be challenging in terms of philosophies and priorities. Let’s take a look at the pros and cons.
Pros:
Resource Alignment: Reporting to marketing ensures access to key resources like the design, content, and web teams. This can improve DevRel’s ability to produce high-quality educational materials. For example, you can work with the web team to quickly launch a landing page for your new hackathon and use the marketing budget to create a high-quality teaser video. Further, you can count on the outreach team to use their ad budget to promote this video.
Better Event Budget Usage: Combining marketing and DevRel budgets often results in greater flexibility for sponsoring hackathons, attending conferences, and hosting community events.
Amplified Outreach: DevRel can expand its reach with direct access to marketing channels, such as newsletters, YouTube, or other channels.
Cons:
Philosophical Misalignment: Marketing may not fully understand DevRel's philosophy, which prioritizes community building and education over lead generation activities. Our previous article highlighted this with the following quote: “Trust is Built in the Trenches, Not Through Marketing.”
Forcing DevRel Into Marketing Goals: Marketing teams often prioritize metrics such as the number of qualified leads, which can pressure the DevRel team to adopt these measures. This approach leaves little room for DevRel to establish meaningful metrics, such as the number of educated developers. This also has a downside: DevRel metrics that align with functions like Engineering often get deprioritized compared to those that align with marketing.
Option 2: DevRel Under Product/Engineering
Placing DevRel under product or engineering offers a natural alignment with the teams responsible for building and improving the company’s product. This structure allows the DevRel team to directly influence the developer experience and ensures feedback from the community gets integrated into the development process. However, this close proximity to engineering priorities can also create challenges in maintaining the broader scope of DevRel activities.
Pros:
Focus on Developer Tools: This structure emphasizes improving developer tools, such as CLI utilities, SDKs, and APIs. It aligns closely with DevRel’s goal of enhancing the developer experience.
Tighter Technical Collaboration: Reporting to engineering can create closer ties with the teams building the product, ensuring that developer feedback is acted upon quickly. The developer community will appreciate the shorter feedback cycle that this enables.
Cons:
Feature Showcase Overload: DevRel may spend most of its time showcasing new features while neglecting other important activities like education, hackathons, or community building.
Misaligned Priorities: The engineering team might undervalue activities like hackathons, speaking at conferences, or writing blog posts to drive awareness.
Option 3: DevRel Under Sales/Business Development
Placing DevRel under the sales or business development team allows them to focus on customer relationships and ecosystem growth. However, this setup can blur the lines between DevRel and roles like technical account management or integrations engineering, limiting its broader impact. Here’s an overview of the pros and cons.
Pros:
Strong Customer Focus: Placing DevRel under the sales team allows them to build close relationships with key partners and customers.
Cons:
Reduced Independence: DevRel risks taking on technical account management roles, hosting onboarding workshops rather than working at a more strategic level. This makes the team less independent and less valuable as they have reduced value on a broader company level, isolating themselves. Eventually, they might become the “technical person” in sales calls.
Integration Overload: Sales may assign much of the integration work to the DevRel team, while dedicated integration engineers should handle this type of work.
Option 4: DevRel Reports Directly to the Executive Team
Establishing the DevRel team as its own team under the executive team can be perceived as a bold move. Yet, we don’t need to underestimate its strategic importance within the company. This setup gives the DevRel team more freedom when selecting its goals, as they are not bound to another team’s priorities. However, this autonomy also comes with challenges, especially in justifying the team’s impact and navigating organizational dynamics.
Pros:
Autonomy: This structure allows DevRel to set its own priorities and act as a cross-functional team. It also enables the team to make faster decisions without going through multiple approval levels.
Higher Strategic Importance: Reporting directly to the executive team gives the DevRel team a higher strategic importance within the company.
Closer Alignment with Business Goals: By reporting directly to the executive team, the DevRel team can set goals that align better with business goals. For instance, reporting to a marketing team might push the goals towards marketing-oriented business goals, which are a subset of the overall business goals. Likewise, if it were to report to other functions, this would allow the team to better track their overall impact on business outcomes.
Increased Resource Allocation: Reporting directly to executives can translate into greater budgetary flexibility and resource investment. It signals that DevRel is a strategic function, which can result in better tools, staffing, and latitude to pursue its own strategy and plans.
Cross-functional collaboration: When the DevRel function sits at the same level as the Marketing, Product, Engineering, and Sales functions, it has a unique vantage point from which to collaborate across these functions. This is especially important given that a DevRel function’s roles and responsibilities are intrinsically multi-functional. This alone can lead to a highly productive and effective DevRel team acting as a “glue” between these other functions.
Cons:
Hiring Challenges: Finding senior DevRel leaders with C-level or VP-level experience can be difficult. Having such a person on your DevRel team is important to navigate the organizational dynamics most DevRels are unfamiliar with.
Proving ROI: Without direct ties to other departments, a DevRel team could find it more challenging to prove its worth. This is especially true when other teams or C-level executives lack a clear understanding of DevRel's strategic role. Setting goals and tracking metrics to support this messaging to the executive team is important. However, proving impact can be challenging because it is inherently difficult to measure a DevRel team's contributions.
Tension Between Departments: When DevRel exists as its own department, it can create tension with other teams as everyone competes for shared DevRel resources. However, it’s important to recognize that interdepartmental tension is a common challenge in many organizations, and it can be resolved by closer collaboration and open communication.
Recommendations for Positioning DevRel
Given the complexity of DevRel and its inherently cross-functional nature, here are some recommendations to ensure its success, regardless of where it is positioned:
Educate upwards: Continuously educate upper management about DevRel’s roles, responsibilities, and impact.
Create “dotted-line” reporting: Establish informal reporting lines to other functions. For example, DevRel can collaborate closely with marketing on campaigns while maintaining its independence.
Build external networks: DevRel teams should network with other DevRel teams to learn new techniques and create new collaboration opportunities.
Offer cross-functional services: Position DevRel as a team that offers services to other departments while maintaining independence. This ensures the DevRel team won’t fully absorb another team’s priorities.
Anchor strategically: While you want DevRel to operate as its own team, anchoring it under different departments by sharing strategic goals is a smart move. This allows you to share budgets, prove your strategic importance, and quickly get things done through cross-functional collaboration.
Conclusion
DevRel is one of the most complex and diverse functions of a tech company. It combines community building, education, advocacy, and technical expertise. Its value is often misunderstood, making its placement within an organization critical to its success. This is demonstrated by the inconsistency between different tech companies regarding where they place their DevRel function.
Ideally, DevRel wants to operate as its own independent team under the executive branch, but this is not always feasible. When positioned under another department, it is essential to clearly define responsibilities and boundaries to preserve DevRel’s cross-functional nature.
When a DevRel team is under one department, it is crucial for the lead (CTO, CMO, etc.) to understand that DevRel functions are also important to other departments of the organization. However, you always run a risk that your department head will default to reporting about its own department rather than adopting a cross-functional mindset. Therefore, “Option 4” is the most appealing option.
To conclude, reporting directly to the executive team gives the DevRel team a higher strategic importance within the company.
Ultimately, DevRel's success depends on the organization’s ability to align its structure with its unique goals while empowering DevRel practitioners to deliver value across the company and the broader developer ecosystem.
