This post is by Mary Thengvall from Openview Labs
Click here to view on the original site: Original Post
I once wrote a post about how developer advocates and developer relations teams are like avocados. Among other things, I pointed out that avocados and DevRel teams are both good for you and have the potential to deliver amazing benefits. They also both take a while to ripen and tend to be a little pricey. But, in the long run, patience and a willingness to invest in longer-term returns almost always pay off. The problem a lot of companies have is that while they’re waiting to reap all the benefits they don’t know how to effectively track the efforts and contributions of their DevRel teams. A common mistake is to try and apply metrics traditionally used to measure the performance of other functional areas like sales (how many people signed up for an account this month?), marketing (how many leads did you capture at the conference?), or recruitment
many applications came in?). This approach falls apart pretty quickly, though, because DevRel has zero control over those things; and you can’t measure a team on something they can’t influence. (Well, you can, but it’s not really fair.) A much better and more effective way to get a handle on how your DevRel team is doing is to look at their work through the lens of qualified leads, which is a term most stakeholders are very familiar with. The idea is to change the focus from traditional sales and marketing tactics to what DevRel professionals excel at: the connections DevRel makes and the relationships they develop. In the same way marketers aren’t judged on whether or not leads convert, DevRel shouldn’t be graded on whether or not certain connections and relationships “convert” into buyers, contributors, or new hires. DevRel’s responsibility is to create the opportunities—the qualified leads—not convert them into specific outcomes. Establishing and integrating this kind of DevRel strategy is all about a) getting really clear on goals and expectations, b) knowing how to measure progress against those goals, and c) being consistent about documenting and sharing the DevRel efforts.
Step 1: Set Clear Goals and ExpectationsThere are two main questions that I ask of all my clients when they come to me looking for guidance on developing a successful DevRel initiative. First, why do you want a community? Second, what do you hope to accomplish? Uncovering the honest answers to these two questions really helps me to drill down into the best way to build, structure and situate a team. For instance, once we understand the “why” and the “what” behind a DevRel initiative, we can make better decisions about the role of the DevRel team and where that team should live within the organization. If your objective is to build a strong customer community, DevRel might fit best under marketing since you’ll likely be focusing on identifying advocates and influencers. If, on the other hand, your goal is to create a significantly better feedback loop, it might make more sense to put DevRel in the product group so there’s a direct line for sharing advice and updates between the people using the product and the people building it. Or maybe you’re working on building sample applications and improving documentation, in which case engineering might be the most appropriate home for DevRel. This ability to deliver a wide variety of connections to many different parts of your organization is one of DevRel’s primary strengths. For example:
- Marketing: Maybe there’s a developer in your forum who has a lot of good experience with your product and is doing a great job answering forum questions for other users. This person might be a good contact to pass off to the marketing team as a reference for a case study or community contributed content.
- Product: If you come across a technical individual who routinely provides exceptional feedback, they might be a great resource for the product team. By connecting them directly, you can open up the door to more productive, longer-form conversations that might lead to the community member’s involvement in beta tests and so forth.
- Engineering: Similarly, maybe a community member has stumbled onto a particularly hard-to-solve bug and is willing to help your engineering team reproduce it so they can get to the bottom of the issue and resolve it.
- Biz Dev/Partnerships: You might find a Developer Advocate at another company who is willing to build out an integration to help customers use your two products in tandem. This would be a great DevRel qualified lead for your business development or partnership team.
- Recruiting: On occasion, you’ll find someone in the community who just gets it—someone who clicks with everyone at your company, understands your product, and is passionate about your cause. When the time is right and a position opens up, these are the people to hand off to recruiting.
- Sales: Finally, there will be some connections that ultimately convert into sales. Who you pass these individuals off to depends on the nature of the inquiry and the relationship. You might start with the solutions architect or sales engineer or you might go straight to the enterprise sales team depending on whether you’re working with a community member who’s an individual contributor or a decision maker on the engineering team.