Is developer relations just another term for developer advocates? How can dev relations and dev marketing work together for the greater good of the community?
Bertrand Hazard, VP, GTM Strategy at SonarSource, sat down with Micky Teng, Head of Product Marketing at Magic, to discuss dev relations and dev marketing. Micky took us through how these two critical functions differ but also complement each other.
Here we’ve got the highlights from the Q&A, but if you want to listen to the whole thing, simply click below and enjoy all the insights. 👇
Q: Can you tell us a little bit more about yourself?
A: My background spans multiple different disciplines within marketing and, eventually, I fell in love with product marketing.
I got to dive in a little bit more on the developer side at InVision and Magic, where I'm currently leading product marketing and growth.
Magic is a startup that's transforming the digital identity space, focused on making it super simple for developers to add passwordless authentication into their apps.
Q: Could speak first to the differences, but also similarities between the dev relations and dev marketing functions?
A: Developer relations (DevRel) represent the voice of the developer community. At its core, developer relations is about building positive relationships and helping communities of developers become successful.
I'll emphasize the word relationship because of how important trust and empathy come into play when engaging with these technical communities. One way to think about it is: DevRel focuses on having a pulse on the community.
Developer marketing represents the voice of the brand (and/or product) to best support the community. In the developer market, you have to have a great product but then how do you get the developer community to understand it's a great product, get them to try it and to think about it in the right way?
That’s developer marketing.
In practice, the activities both functions cover can look very different from company to company, especially the day-to-day (depending on the needs and goals of the company).
At the end of the day, community is at the center of both functions. Developer relations and developer marketing complement each other and the closer the collaboration is between the two, the more you're supporting the developer community, which is the ultimate goal.
Q: How do you divide responsibilities between the two functions, and where's the overlap?
A: In my experience, the overlap is around the community. There are two areas repeated in both of the functions and that's developer experience (DX). Both DevRel and developer marketing empathize with developers' pain points.
Firstly, they translate this empathy and make it helpful, whether that's proposing a solution via content, or creating a guide or documentation; they have to show the concrete steps on how to build something. Utility is at the heart of it.
Then, ultimately, it's about the shared objective of driving growth for the company. There's this innate challenge with developer marketing where developers essentially have built up an immunity to traditional marketing.
We have to make sure that messaging doesn't sound quite like marketing, otherwise you'll turn off developers, which is why developer relations and developer marketing need to tightly collaborate to de-risk this challenge.
It's a symbiotic relationship where each function complements each other. There's unique value in each of them but, together, they can trulyimpact the broader organization.
Q: Do you see developer advocacy as the same as developer relations? Do you see it part of Dev relations or even part of Dev marketing?
A: The terms are always somewhat interchangeable in the industry but based on my experience at InVision and Magic, developer relations is not just another name for developer advocates.
Developer relations, in my mind, is the umbrella term for the team whose primary responsibility is building a community, both online and offline. That includes developer advocacy plus developer experience, events and, sometimes, even community management content. At some bigger companies, like Twilio, it can be a really big umbrella term.
A developer advocate is someone who likely has some sort of coding experience, whether it's an official computer science degree, coding school, or they've even been a full time developer in a past life.
In my day to day, I see they're often building sample apps, live coding, or even giving demos to developer communities and engaging on a more technical level. In my experience, working closely with two awesome developer advocates at Magic on my team, I’ve seen that each of them has a passion for specific tech frameworks and they're active on specific forums.
Q: From what you've encountered in your different experiences, where do you think the functions should live?
A: In my experience, there's no hard and fast rule for where they should live. It tends to be fluid. For example, sometimes, developer relations are really close to engineering.
It depends on the company's priorities and the organic org structure. Specifically for DevRel, no matter where the team reports, organizationally, it's important for developer relations to have a direct line to developer marketing, PMs and engineers.
In the case of Magic, we have developer relations within marketing, which is a natural fit for us because our biggest priority right now is growth.
To sum up, it’s context-specific but highly focused on bringing the product feedback back to the cross-functional teams.
Q: When is the right time to start a developer relations function? Is it like before devloper marketing?
A: The short answer here is, it depends. The right timing depends on the product and its maturity, what stage the company is in and, of course, how central the developer community is to the overall business and growth strategy.
If you feel like developer relations is an acute need that has to be solved, then that's the right signal to start building it from the ground up.
Developer marketing, because it can be so synonymous with product marketing but geared towards developers, can take shape in different ways. It's up to the leader of that function to start mapping the path for how it could align with the business strategy.
Q: How can these two functions work collaboratively? What's the best practice for them to work together?
A: They should 100% be working collaboratively and it's a huge mistake if these teams are operating in silos.
When it comes to OKRs (objectives and key results), you can share them around functions and iron out the brass tacks for how they come to life, process-wise or ops-wise. We can experiment together and rapidly iterate around the wins we see and share those learnings back to the company.
It’s about whatever works best for your specific company at the stage you're at but the departments should definitely be collaborating together.
Bertrand: The best way to collaborate is to have clarity around what should be the desired outcomes for each team so everyone knows what other kinds of expectations are on the other team and then they can work together to either help you support your objectives or your outcomes.
Dinesh Chandrasekhar
Q: Are there any tools or software you would recommend to scale and measure the impact of both functions?
A: The first thing that comes to mind is a tool called Orbit. It's a really helpful one-stop-shop to see a holistic view of all the metrics you'd looked at for community building and growth.
On the quantitative side, you can track online engagement. Some examples are:
- GitHub pull request
- Twitter comments
- Onsite metrics from conferences
On the qualitative side, it's a little bit trickier because community is so relationship-oriented you have to see the in-person connections (or virtual), and how do you map those out. What are the anecdotes and the verbatim quotes you can bring back to galvanize the company?
The warm handoffs is a metric on when developer advocates or developer relations bring back a connection and an intro to marketing. For instance, a customer who they want to feature in a case study or community member who wants to write a guest author blog post; those are the really cool wins only developer relations can bring back to that company.
I love to see the impact, map out and trend around quantitative metrics some tools can help us with, but also the qualitative side where it's more about the storytelling and how we can drive awareness for our brand.
Q: What would be your advice for a product marketing team, which is setting up a developer marketing or dev relations strategy for the first time?
A: My advice would be to start small. The world of developer marketing and developer relations is so vast, there's so much you could be doing at any given time.
To reframe, this a bit is about honing in on the exact experiments you want to do. Rapidly test, find the small wins, iterate and then socialize.
You have to be able to advocate for your advocates, which basically means being really honest with where you're currently at, figuring out the multiple phases of a campaign and a strategy to get to the future state, to hit a certain goal, set some baselines based on real data, and most importantly, invite input from the dev relations team.
Again, collaboration is essential and setting a new motion forward for the first time can be quite daunting.
Starting small, building momentum over time, socializing the learnings along the way to get buy-in from stakeholders and, ultimately, community building, takes time.
Stay patient with it and set expectations from everyone and you’ll be getting buy-in along the way.
Q: Do you have any specific advice for product marketing teams of one?
A: Patience, make sure you're transparent and open about things that will change. Community building, dynamic developers, dynamic trends are happening all the time, so just being open and transparent about your multi-phased approach, and that it's not an overnight success, as much as we all want it to be, is essential.
As much as we can be self-critical, honest and transparent with the small wins, they'll add up over time, and that's where the community can start to thrive and where the real growth is unlocked.
Key takeaway: embrace the community!
It's a great metaphor for how dev relations and dev marketing complement each other naturally for the greater good of the community.
It's about being the champion and helping the community be successful, as there are unique strengths each function contributes to the broader picture.
Have something to say? Why not contribute your know-how by writing for us?
Developer Marketing Alliance
