Does Developer Relations Belong Under Marketing or Engineering?
A frequent question that rises with companies as they build out their Developer Relations team is where should it be located within the organization. Should it report up to Engineering, or Marketing? Although I’ve spent the vast majority of my career as a developer, my undergraduate studies is in Organization Learning. This question of engineering or marketing already gets me excited to dust off my educational roots.
Before looking at your organization structure, my suggestion is to take a step back and consider what stage your company is it, and why you are looking to grow the developer community. In short, there is no right or wrong answer, but the following insight may help you choose the right path. I’ll use funding series as a general guide, but obviously different companies can be at very different phases of growth and maturity.
Early Stage Companies (Seed, Series A, B)
For early stage companies, Developer Relations should be as close to the Engineering and Product teams as possible. It’s a clear case of early hands on support of product fit and much less about hitting metrics such as sign ups or adoption. Putting Developer Relations under marketing too early risks a rush to increase signups, often at the detriment of developer experience.
In the early stages of a company, your product is likely missing features, seeing frequent updates, many of which may be breaking changes, or you are still figuring out product-market fit. You are experimenting on what works and what developers need. You may not even have an ungated sign-up process yet. You should be using concepts such as double-loop learning to validate assumptions and adjust accordingly. It’s a time to experiment constantly.
The goal of Developer Relations in this sort of environment is two-fold: First, act as an outbound product manager: be the voice of the developer to relay feedback into engineering about what works and what needs improving. Second, create initial code samples, and learning material to not only help early adopters onboard, but also as alpha testers for product teams. Generally, Developer Relations are working on a 1-to-1 model with your developers.
Mid Stage Companies (Series C, D)
Mid stage companies should be seeing a maturation and resilience in their product and developer offerings. APIs change less frequently and are rarely destructive, personas are stable and well defined, and you likely have PLG metrics in place. For Developer Relations, the recommendation is to still keep them under Engineering, but lean into a shared services model for marketing and demandgen.
The key to mid stage companies is to start to show growth and scale. PLG models and ungated sign-up are critical. Marketing and demand generation know how to optimize the top of the funnel, and your Developer Relations team is likely too small to have headcount to it. Developer Advocates are busy writing more learning content, long lived training material for workshops, and sales is probably starting to request their time on strategic deals.
Your Developer Relations team should be heads down starting to build 1-to-many engagement models such as forums, community events and more. At the same time, Marketing is likely looking to run more webinars, blog content for retargeting and demandgen, and establishing field marketing calendars and relationships with partners in the ecosystem, all of which require good technical content and speaker, aka your advocates.
The primary goal of Developer Relations at this stage is to champion a great developer onboarding experience and do it with a very small team. By keeping Developers Relations close to Engineering ensures that the feedback loop to product remains strong and is not distracted by the next big deal the Sales teams are working or the ever increasing marketing rolling thunder. In the end, if the developer experience is poor, telling more people about it is counterproductive to everything.
Late Stage Companies (Series E, and beyond)
Late stage companies have solid, and growing, revenue and do a good job of predicting growth. Now is the time to get more formal with big OKRs to measure the developer funnel. Developer Relations can clearly define the developer lifecycle, they have worked with Engineering to instrument the product, and PLG strategies are playing out along with Marketing and Growth teams. Developer Relations are less occupied with first-line of support and 1-1 onboarding. They should now be looking at how to spread the word as far and wide as possible. To do this, they need to be very close with Marketing, but it’s a toss up where they fit in the organization.
My best advice is that if the company’s primary persona is the Developer, then Engineering may make sense since you have a more technical product and developer advocates need to be more deeply technical and understand the product, roadmap, and implementation intimately. Remember, Developer Relations should always be the conduit from first-hand developer feedback back to Engineering, but if your PLG motions are driving large numbers of developers into your product, Developer Relations should have already written the key onboarding content and the product is mature enough that the majority of developers can get started successfully.
In late stage companies, Developer Relations starts to operate more as arm of marketing, and also looking to massively scale their processes. They should be actively pursuing community contributions for content and event speaking to feed the need for more content and geographical coverage. They will either rely heavily on marketing, events and demandgen to reach more and more developers, or start hiring Developer Marketers, event managers, dedicated demandgen folks, and growth engineers within the Developer Relations org.
At the same time, the Developer Advocates may begin to specialize in order to penetrate specific developer communities, or the emphasis may shift from signup heavy to ensuring healthy MAU and retention goals. If this shift to MAU and retention is a primary goal, keeping Developer Relations under Engineering is a good strategy. If so, make sure you have a good shared services model in place to allow Developer Relations to leverage marketing and demandgen teams without having to always justify attention of the developer audience.
Mature Companies
I’m going to use mature companies as a sort of catch all for a company that, regardless of size, has products in the market, solid and consistent revenue, established developer lifecycles, and generally has a regular cadence around product launches, marketing activities. Developer Relations in mature companies frequently sit under Marketing for many of the reasons already described above. When they don't, shared services for access to marketing and demandgen are critical.
However, successful developer-first companies need to always remain abreast of the latest technologies and go where the developer is.
Developer frameworks and patterns change daily and can quickly disrupt marketing calendars. Not to mention, the likelihood of acquisitions come more into play. In order to remain agile, I strongly suggest creating cross functional teams of product, developer relations, marketing, and demandgen for new product releases. These teams should own the launch plan and define metrics on a project by project basis. Very often, for example, a new product is going to need early developer adopters, new tutorials, frequent iterations and feedback loops as well as targeting marketing to existing developers or new personas.
By combining skills across departments you can avoid being too focused on organization OKRs that be too coarse grained and miss important aspects that may provide invaluable insight to the health of a new product or service. Go back to your double-loop learning from your scrappy startup phase to validate the success of your launch. Experiment, learn, and repeat as a team, not as an organizational structure.
Summary
n summary, where you place Developer Relations within your organization really depends on product maturity. The more change you see in your product, the closer Developer Relations should be with the people that write the product. As your product matures, the need to rely on the Marketing megaphone will increase. Just aways remember that the primary goal of Developer Relations teams to ensure every developer has a great experience using your product.
If there is one thing I have learned from 15 years in Developer Relations is that you get one shot with developers. If you do not constantly listen to what they need, and the changing technology landscape, they will vote with their keyboard and kill -9 immediately.