March 21, 2019
Kwan’s Hierarchy of Product Needs: The Four Levels of Product Managers
A common dilemma faced by developer company founders is that while CPOs add significantly greater value than junior and senior PMs, they are...
In part two of our series on Collaborating with Developer Relations, we explore the opportunities and challenges arising from collaboration between sales and DevRel teams. Check out Part 1 covering DevRel and marketing to get up to speed.
Since many DevRel teams either report into marketing or work closely with them on content and events, the opportunities for collaboration might seem obvious. But the touchpoints between DevRel and sales teams aren’t as clear-cut. Worse, the two teams often experience tension and conflict, leading to decreased productivity and a poor customer experience.
But even though both teams have different goals and often different cultures, each can benefit from the other. In fact, they actually share more in common than is initially obvious.
Both DevRel and sales teams spend time with customers and prospects out in the field, which creates mutual understanding. If nothing else, they can probably share some tips on expediently filing expense reports.
While we believe both teams can learn a lot from each other, we’ll also explore some common pitfalls. Cultural differences between the teams can lead to misunderstandings and miscommunications. As in any healthy relationship, it’s important to define and respect boundaries.
Despite their differences, both teams focus on building relationships with people, and introductions between teams is a great place to begin collaboration. Account Executives (AEs) and Sales/Solution Engineers (SEs) can send developers to the DevRel team to help them learn more about the developer community and gain confidence in the solution. DevRel can make introductions between prospects and AEs when the time is right.
For many AEs, speaking with a skeptical developer can be a daunting task, so if sales isn’t sure how to approach a dev at a prospect or customer, they can talk to a DevRel to see how they would go about getting that connection.
In general, DevRel can provide a more developer-centric way to start a conversation with a technical prospect, versus a more traditional sales approach like an email outreach.
In action: Define a process for how sales can ask DevRel for intros. This could be a Slack channel or weekly email request digest. Define the information that should be included with each request, such as: why the intro is needed; the rep’s connection to the developer or company; details of any deals that are in motion; and potential deal size. Define another process for how sales and SEs can send customer developers to the DevRel team who are interested in getting involved in the community.
Although it should be done sparingly, DevRels can help support AEs by participating in the occasional sales call. This should happen when there is a specific reason, for example:
These are a few of the most common situations. There are more, but it’s very important to set boundaries here and utilize the DevRel time when it’ll be most impactful.
In action: DevRels should intentionally set boundaries with their colleagues, defining a realistic number of calls they can sit in on per month.
In return, the sales team should make sure that they are acknowledging the work that the DevRel team is doing and communicate that up the chain. Although not its primary function, DevRel does help create revenue in these situations and it’s important that the contribution be visible to company executives. The DevRel team will really appreciate this and may be willing to offer more of their time for calls in turn.
Sales teams generate plenty of content on their own, from slide decks to outbound email campaigns. Collaborating with the DevRel team on the tone, voice and messaging of that content if there’s a chance that developers will see it will increase the effectiveness of these efforts.
In addition to the content itself, DevRels should provide guidance on messaging frequency, since it’s easy to overwhelm developer prospects with sales messages and turn them away.
We know of multiple instances where a DevRel has received back-channel messages from developers at prospect companies complaining about an overly-enthusiastic sales person.
In action: Schedule a messaging review between sales and DevRel to discuss what’s working and what’s not, and to share insights and best practices. In this meeting, the team could go over sales messaging overall, as well as specific drip and outbound campaigns, covering both content and timing.
Review sessions like these will help ensure messaging and outreach resonates with developers, and prevent the DeRel team from having to do damage control.
Both sales and DevRel spend a large percentage of their time at conferences and in the booth. The inevitable event downtime and happy hours can be used to build rapport.
The two teams should collaborate to make sure every visitor that drops by talks to the right set of people and has a good experience. Visiting developers should be routed to DevRels first. If a possibility for a lead exists, the DevRel can do an introduction then or follow up later depending on what feels right.
In action: Prior to an event, DevRel and sales should discuss strategy, spelling out which personas are relevant for which teams, and agreeing on how to gracefully forward visitors to the right representative in the booth. Discuss the job titles and key accounts the sales team is particularly interested in, and rehearse smooth hand-offs between team members.
After an event, conduct a post mortem where DevRel and sales share notes on interesting attendees, either for joining the developer community or for the sales team.
Finally, if there was any tension or confusion during the event, this is also a good time to debrief and address it.
Partnerships are central to many successful go-to-market plans, and DevRel teams are in a good position to help business development teams. DevRels are tightly connected to their peers at other companies, which makes for easy intros and early conversations.
Certain partnership activities like events and sponsorships can benefit both the DevRel and BD teams, meaning they can join forces (and budgets) where it makes sense.
Finally, it’s common to see developer tools companies partner with development agencies or integrators. In that context, DevRels may offer in-person trainings and workshops for partner developers, helping them become productive faster and also making them aware of the community.
In action: Schedule monthly reviews between the business development and DevRel teams. Discuss the status of current partnerships and brainstorm new opportunities. Review any high-priority prospective relationships and discuss tactics for starting those conversations.
While the different culture and objectives of sales and DevRel represents a common source of tension in many companies, both teams work directly with customers, and each team can learn a lot from the other. Just remember to set boundaries. With a bit of trust, honest communication, and clear expectations, both groups can tap into what makes the other team great.
Join us again in a few weeks for the third installment of the Collaborating with Developer Relations series, we’ll explore the relationship between DevRel and the Product team.