The Truth About DevRel & How To Make It Work
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 (how 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 Expectations
There 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.
Step 2: Get Your Metrics Right
The critical thing to remember is that DevRel cannot be held responsible for the final outcome, whether that is a guest post, a partnership, a new hire or a converted customer. The value DevRel delivers is the connection itself—the opportunity for marketing or product or sales or another team to transform the DevRel qualified lead into a valuable business asset. That’s what you have to measure.
The key to accurately assessing how successful your DevRel efforts are is focusing on the right details. Instead of tracking work output–whether the DevRel team published a blog post–or even the amount of traffic the post received, you’ll want to recognize wins like when that piece you syndicated to another website got a great comment from a developer who’s curious about how the author implemented a particular piece of your product. That’s engagement. That’s great feedback. That’s a relationship in the making, which is the value DevRel brings to the table.
Once you’ve selected which metrics you’ll use to track DevRel progress against specific objectives, you want to make sure you keep a practice of regularly revisiting those metrics to see what’s working and what’s not. The exact frequency for review will vary depending on each company’s goals, but quarterly is a good place to start. Just be careful not to cut yourself short. Remember that DevRel is a long game, and there are also outside factors (like how much traffic your website is getting overall) that can affect DevRel efforts. Make sure you’ve considered all the possibilities before you decide to give up on something that doesn’t seem to be working in the short term.
Finally, don’t forget to listen to your community members. They are a great source of insight into which goals you should be setting for the next quarter. What are they asking for? Which are their favorite resources? Which topics do they find most helpful? Which areas could use more coverage?
Step 3: Document and Share DevRel Efforts
In addition to reframing the way DevRel work is perceived (and measured) within your company, it’s really important to keep a paper trail of DevRel activities and relationships. There are several reasons to do this:
Clarify what DevRel actually does.
There’s a pretty broad lack of understanding about what the DevRel team actually does on a day-to-day basis. This is largely because so much of what DevRel does is behind the scenes, so people are often only aware of the most visible aspects of the effort. For instance, while someone outside of DevRel might characterize a speaking gig at a conference as “just flying to another conference and spending time drinking, eating and hanging out with people,” someone who understands DevRel knows how much went into making that happen—finding the right conference, submitting a CFP, writing the talk, preparing the presentation, and so forth, in addition to the time on the ground connecting with community members and building relationships. There’s a lot more to DevRel than meets the eye.
Avoid crossed wires.
There are cases when another department can make a critical misstep if they aren’t aware of DevRel relationships. Imagine that DevRel is tracking their activities in your company’s existing CRM, including a relationship with someone at the Acme company. And then imagine that sales is trying to do a deal with the Acme company and notices the DevRel contact in the CRM database. Sales reaches out, inadvertently doing tremendous damage to a relationship that DevRel was carefully nurturing. The trust is ruined and the opportunity is lost, all because the sales team didn’t realize what DevRel was working on and completely jumped the gun.
Demonstrate the value of DevRel.
Because it’s a long game, DevRel is often at risk of having their thunder stolen by another team that works on a shorter time frame. For example, say your DevRel team builds a relationship with someone at a startup. This person isn’t ready to buy, but they are interested in your product and engaged in an ongoing, informal conversation with DevRel. Two years later, the startup has grown exponentially and finally has need of your product. DevRel hands the lead off to enterprise sales who lands the customer and celebrates the big win independently because they don’t have any documentation about all the upfront work DevRel put in with the prospect over those first two years.
Identify success patterns.
Finally, carefully tracking DevRel activity can help you uncover which types of experiments have yielded the best results over time. This insight will help you determine where to focus future efforts and show you exactly which levers are worth pulling.
As for the mechanics of tracking and sharing DevRel activity, I’m a huge advocate of plugging into whatever CRMs your company is already using so long as everyone understands that the leads the DevRel team adds to the database are not sales leads. This will help avoid those crossed wires and ensure that credit is given where it’s due.
If it’s not feasible to set up silos between DevRel leads and regular sales leads within a unified CRM or other shared platform, you may need another way to keep everyone in the company up to date on what DevRel is doing. A weekly email to the rest of the company is a simple way to keep everyone abreast of the latest DevRel connections, and those types of communications can be highlighted for managers and heads of departments to ensure the right people are seeing the pertinent info.
Much More than Just Avocados
While I stand by my avocado comparison, one of my all-time favorite analogies for DevRel comes from my good friend Amy Hermes who likens the role of DevRel to that of a cruise director. If you’ve ever been on a cruise, you know that the cruise director is the person who makes sure everyone has what they need, no one feels left out and everyone has someone to talk to. DevRel professionals are the cruise directors of the technical world.
We are responsible for having our finger on the pulse of the community at large and being tuned into individuals within the community so that we know which people to introduce in order to increase engagement, strengthen relationships and uncover or create opportunities. We see the threads of conversations that haven’t happened yet, and we bring people together to get those conversations started. That’s how relationships get built, and from there — anything is possible.
This episode features Vlad Magdalin, Co-founder & CEO of Webflow, a business that took four tries to get off the ground. Find out how they think about creating a product that’s applicable to as many people as possible and why adding incremental value is more important than shipping a perfect product.
Many tools have emerged to help PMs do their jobs more effectively. These make up the product stack, composed of more than a dozen categories. But what is the actual function of each category? Here, we drill down.
Founder & CEO of Postman, Abhinav Asthana, explains how the team designed a product for the end user using a PLG strategy. Read here.