DevRel Collaboration: How Should Developer Relations Interact with Other Departments?
DevRel Collaboration: How Should Developer Relations Interact with Other Departments?
It depends on company stage and goals, but focus on good two-way relationships and clearly aligned KPIs
For my first SubStack post on the topic of Developer Relations (DevRel), I wanted to dive into one of the topics I get asked the most about, “when and how should Developer Relations teams interact with the rest of an organization?”
We all know that the answer to any interesting question is “it depends”! It depends on many things, such as how you define the DevRel role and function, what size and stage of a company you work for, and how clear roles and responsibilities are within your organisation.
So when answering this popular question, I typically take the following approach:
Share my definition of DevRel to make sure both the person asking the question and I are aligned on the core function and responsibilities (this can involve a little back and forth, as my definition of DevRel is by no means the definition).
Aim to understand the current stage and goals of the company, i.e. do you have product market fit, how is the reporting structure set up, are shared KPIs defined, etc?
Share my thoughts on how the DevRel team should currently interact with the wider organization, which typically involves aiming to align on goals and making the collaborations a win-win all around.
Let’s take a look at each of these stages in more detail.
What are Developer Relations, Developer Advocacy, and Technical Evangelism?
There is a lot of discussion on the interwebs about the goals of Developer Relations and the differences between the various related jobs and role titles. I can share my thoughts on this in a later post if folks are interested, but for me, the most important parts of DevRel are generating awareness, education, creating technical demos, community building, empathizing with developers (and the wider audience), and acquiring feedback.
I try not to get too caught up with different role titles, but a core tenet is that a Developer Relations function is a two-way street between the wider audience and the company. I may speak, but I also listen (and often do so more).
This is in comparison with the “technical influencer” role, which typically involves one-way (outbound) communication. You’ll find technical influencers often living their best life on the ‘gram or Twitch while pitching how a new tool or tech will change a developer's life.
It’s also worth noting that when I speak with groups of people that include folks outside the realms of software development or technical marketing, often the label “developer relations” makes no sense to them. I found this when I was chatting with attendees at the recent SaaStr Europa conference. In this case, I typically follow John Cutler’s lead, say I am a “product evangelist”, and then empathize that the “relations” part of the role means that the communication isn’t just one way.
DevRel through the ages (or company stages)
With my definition of DevRel shared, I then enquire about the stage and goals of the questions asker’s organization. I like to work with early-stage companies, so I often chat with pre-product market fit folks or teams in the early stages of scaling up.
Here is the advice I typically give for three company stages.
Pre-product market fit: It’s all about the problem and the product (obvs!)
If your company is pre-product market fit, then expect to be doing a lot of audience exploration, product demonstrations, “thought leadering” (and potentially category creation), and community building.
You should also be listening a lot more than you are talking to understand what problems the community and potential customers are struggling with.
In this company stage, I expect DevRel to interact a lot with the product (marketing) team. You need to understand how the organization thinks you should pitch the product, and you want to provide associated real user and audience feedback to the product team.
You want to have at least weekly meetings with the product team (which often heavily involves the founder at this stage) and ensure these meetings are two-way. You also need access to the issue tracker and backlog/roadmap, and you want to be tying community interactions with specific requests or feedback.
Shared KPIs here can include the number of community folks and prospects interviewed, backlog issues influenced, and views (and comments) on content, etc.
Early-stage product-market fit: Getting snug with sales
This advice may be controversial (and I’ve not always followed it!), but when your company starts getting traction with your product, the DevRel team can learn a lot by integrating with the sales team.
I can hear some folks now. “Wat!! Devrels don’t do sales!” But the reality is that everyone does sales 🙂
At this stage of a company, where the solution engineering and customer support teams are nascent, the DevRel team can add a lot value to pre- and post-sales motions. DevRel teams can also learn a lot about the problem space and how customers are applying (and often misapplying) your product and solution.
Trust me when I say that there can be a world of difference between how folks in the community use your product versus how prospects and paying customers use your product.
Learning about the latter can help drive relevant content creation and ensure the DevRel team focuses on the relevant problem space.
At this stage, I recommend having a weekly meeting with the sales team or sales leadership, where you can share your insight from joining select sales calls (or watching sessions via Chorus/Gong) and also learn about common questions, objection handling, competitors, etc.
Shared KPIs here can include backlog issues influenced, sales enablement material generated, DevRel-influenced pipeline, etc.
Scale-up: Match-making with marketing
A lot of great DevRel-focused content has been created for dealing with this company stage. The problem space and product are well-defined, and your go-to-market (GTM) motion should be humming along. I believe at this stage, the key to successful developer relations is aligning well with the wider marketing team.
I’ve seen a lot of misalignment and a fair bit of conflict between marketing and DevRel teams over the years.
It can be tempting for the marketing team to treat DevRel as a service department (“write this blog post, produce this demo”), particularly if the marketing leaders have not worked in the software development space before.
Equally, DevRel folks can look down at marketing teams and attempt to blaze their own “more authentic” (often chaotic) path to reach developers.
Both of these issues should be avoided.
At this stage of a company, I recommend close integration and the establishment of shared goals between DevRel and the marketing team. The marketing team often have useful insight into key personas (of both users and buyers) that help DevRel teams target their efforts. And DevRel teams can provide guidance on the core messaging/positioning and also check for technical authenticity.
Weekly alignment meetings between marketing and DevRel are essential, and the two functions should collaborate on board-level KPIs and presentations.
Shared KPIs here can be focused on the classic metrics, top-of-funnel page views, MQLs, SQLs, and PQLs etc., but should also include full-funnel metrics like DevRel influenced revenue.
Want to know more about DevRel?
I hope this first post has helped clarify the importance of relationships and integration between DevRel and other departments within an organization.
Please comment below and let me know if you would like more information on the types of collaboration between teams.
And don’t forget to subscribe! I’m aiming to share a post every two weeks or so.