First, Understand the Company Goals
"What is the main goal of a DevRel team?" is a question I've heard for years, and every time, the answer starts with "well... it depends!" What if I told you that the main goal of DevRel -- no matter what company you're at -- is to support the company's empowerment of the developer community?
From this understanding comes awareness of your products (speaking at conferences or writing up best practices), enabling your audience (getting started guides and tutorials), and engagement (making community members feel welcome and included). From this singular goal, you can more easily see where you fit into the broader tapestry of your company's goals and objectives for the weeks, months, and years ahead. The end result? A stable Developer Relations team that can easily point to the value they're bringing to the community as well as the company.
Metrics to Track (Wrong Answers Only)
In amidst all of those “well… it depends!” answers, you’ll likely hear some of the following answers when asking people what the primary metric is for a Developer Relations team:
Social Media Statistics
Number of Downloads
Number of Talks Given or Tutorials Written
What Gaps You’ve Filled (e.g. Technical Support Staff for the Community Forum, Events Management, Social Media Management, Project Manager for Product or Engineering Teams, etc.)
I should note that these things aren’t necessarily bad in and of themselves, but they’re not enough to prove the value, and more importantly, the impact of your work. There needs to be a larger story attached to them.
For instance, tracking social media statistics like Twitter followers or GitHub stars doesn’t tell you anything about the actual engagement from the community or who they are. Download metrics don’t tell you whether the people who downloaded your platform are still using it or whether they were able to successfully solve their problems. These metrics quickly become what we call vanity metrics: items that are easy to track but don’t often speak to the larger business value of the work you’re doing.
Work output is the second category of metrics that are typically tracked. While tracking how many blogposts, tutorials, or talks your team can accomplish in a single quarter can be helpful in figuring out a good work cadence for your team, once again, delivering these metrics to your senior leadership doesn’t speak to the impact that this work has had on the company or the community. All of the awareness, enablement, or engagement that you’ve worked toward with these tasks (the truly important things) is left by the side as you emphasize to management just how much work you were able to accomplish.
This last category of metrics often isn’t explicitly defined, but can simply occur as companies try to figure out where a DevRel team best fits within the company. Do we belong in Marketing? Product? Customer Success? Filling gaps from other teams is often an easy way for the company to justify the expense of a DevRel department. Is the team able to handle all of the technical support questions that come into the forum from the free or open source community members? Do they handle all of the events management and staffing for developer-facing events? Perhaps they run the developer-centric social media accounts for the company or help the Product and Engineering teams with project management tasks. While all of these tasks are important (and sometimes fall under the purview of Developer Relations), none of them highlight the unique qualities that DevRel professionals bring to the table.
Finding the Right Goals
So if those are the wrong answers… what is the goal of a Developer Relations team? It turns out, “It Depends” isn’t always a bad answer! Your end goal will depend on which audience your company is focused on, what stage your company is at, and what the maturity of your product is, but there is a question you can answer that will solve most of these problems for you.
How can we help our colleagues, using our own unique talents to support their goals,
while still providing value to the community?
In order to successfully prove the value of our work in a way that the company understands and sees as beneficial, we need to attach the main goals of the Developer Relations department to the goals that are shared by the company as a whole. Let’s break this down…
This work has to be done in a way the company understands. It needs to be related to the work that another team is doing in a support capacity (e.g. helping to build out a social media presence with a technical audience) or in a way that actively furthers the company vision (e.g. collecting feedback from trusted community members which will help shape the product roadmap).
This work needs to be seen as beneficial. What is the impact of the work that you’ve done? It’s not just enough to answer questions on Stack Overflow that are related to your product. After all, Engineering, Technical Support, or Product could likely do that as well. But if you can spot patterns and trends throughout the tech industry while spending time engaging with your community on Stack Overflow, you’re then able to bring your unique perspective back to the company. This information can then be used by Marketing to create additional content, Product to decide on the best way forward with a new feature, and even Sales to highlight new use cases during their calls with prospects.
The work that we’re doing needs to be attached to the team goals, which then point to the broader company goals. This is where we go back to the three-part goal of awareness, enablement, and engagement. Is your company trying to raise its ARR? Finding ways to increase developer awareness of your product through speaking engagements, unique tutorials, or syndicated content is just one way to increase traffic to your site. Perhaps they’re attempting to reduce churn. By focusing on developer experience, you can ensure that developers are having a great experience from the start. When this is followed by a great experience with your community, customers are that much more inclined to stick around a while longer!
The Big Question
This brings us back to the big question I referenced earlier:
How can we help our colleagues, using our own unique talents to support their goals,
while still providing value to the community?
This is a big question because it requires us to actually know what our unique talents are! What do we bring to the table that sets us apart from the other departments? What value do we bring to the company as well as the community that other people aren’t able to achieve?
Here are a few examples:
Gather community opinions and translate them into actionable feedback that the Product and Engineering teams can benefit from
Connect with community members one-on-one and start a relationship that’s going to keep them coming back to day after day, even if they do run into issues
Make introductions between community members and our coworkers that bring significant value back to other teams (see also: DevRel Qualified Leads)
What’s important is that we find these unique qualities that set us apart as we engage with our communities. These qualities allow us to further our co-worker’s goals as well as our company’s goals while still providing that tremendous value back to our community at the end of the day.
Libby Boxes: Let’s Get Practical
Libby Boxes, a predictive framework popularized by Cornell Accounting Professor Robert Libby, allow us to draw directly from the company objectives all the way down to the specific work output we’re working toward during a specific sprint (monthly, quarterly, yearly, etc.). This helps the DevRel team ensure they’re working toward common company goals while still serving the community (which is our top priority at the end of the day). It also gives senior leadership a way to see the direct impact the DevRel team is having on the company and reinforces our value internally as well as externally.
This framework is used to illustrate the relationship between the strategic objectives you’re trying to achieve and the initiatives (or levers) you use to reach those goals
The top row of boxes is for the concepts or ideas that you’re working toward. Once these more general ideas are identified, you’re able to move to the lower boxes where you’ll start to think more tactically about what initiatives you might explore and how you can measure the success of these concepts to ensure that they’re going to have an impact on that overarching goal.
Asking these questions gives you an opportunity to easily trace your work back to the company goals.
Let’s break down the questions you’ll be asking in each of these boxes:
Top right: What’s the company goal you’re trying to work toward?
I try to choose the goal that I know we’ll be able to impact the most. For instance, I’ll rarely choose the Sales goal of increasing annual recurring revenue (ARR), as Developer Relations doesn’t often directly impact the number of closed opportunities (we do have a significant impact on long-term growth, but that’s a topic for another blogpost). If ARR is indeed your company’s one and only goal for the foreseeable future, you could pivot the goal slightly to awareness, as the work output of a DevRel team typically increases the general developer awareness of your product.
Top left: What’s one of the ways you want to try to impact that goal this quarter?
These answers are very general (they might almost feel too general sometimes!) but are buckets of items that you could experiment with throughout this particular time period. For instance, I’d list “Create content” rather than “Write blogposts,” since blogposts are a subset of content, which also includes videos, tutorials, live streams, and more.
Bottom left: What are the specific tactics or “levers” you’re going to pull in order to test the experiment?
This is where we start to explore the more tangible items. Perhaps we’ll start to look at whether external advocates (non-employees) are writing content or speaking at conferences on our behalf, which may help us to decide whether a Champion Program might be a useful initiative to explore in the future.
Bottom right: How will you know whether or not the experiment was a success?
These metrics could be the number of attendees reached with a conference talk or the amount of traffic to developer-focused content on your website. While we referred to these earlier as “vanity metrics,” they come in handy here as a way to measure whether or not the particular work that you’re doing has had an impact or if it’s time for another “lever” to be pulled.
These boxes give you a way to easily trace your day-to-day work back to the company goals as a whole. It also gives you the freedom to switch between tasks and decide that one particular tactic isn’t working, allowing you to move on to the next experiment. For instance, if halfway through a quarter you realize live streaming isn’t driving the traffic you’d hoped it would, you can end that experiment and continue with the next tactic on the list. Rather than needing to get buy-in from upper management on this change in tactics, you can explain that live streaming was simply one tactic of many that you are trying in order to increase the overall awareness of your product.
Another angle that Libby Boxes help with is when upper management hands down a decree that requires you to engage in a particular activity, such as publishing technical content every Friday or attending a certain number of meetups per month. When you can’t get satisfactory answers as to why they’re asking you to do this work, you can show the greater impact by putting those “work output” items into that bottom right box and figuring out which tactics they fit into, which experiments they may be supporting, and which overarching company goals they’ll be impacting.
Why Should I Care?
If you aren’t responsible for the DevRel strategy or you work for a company that intrinsically understands the value of community building and doesn’t require you to prove your value, you may be wondering if this applies to you. It does!
This practice of attaching our day-to-day work to the broader company goals is how we ensure the longevity of our role and the protection of our community. If we’re unable to prove the value of our work as well as the resulting value that the community provides for the company, the company may lose faith not only in the DevRel function, but also in the value of reaching out to the broader community to get feedback, generate awareness, and increase the enablement of the developers we’re trying to serve.
This brings us full circle to my earlier statement:
In order to successfully prove the value of our work in a way that the company understands and sees as beneficial, we need to attach the main goals of the Developer Relations department to the goals that are shared by the company as a whole.
By making sure that our Developer Relations goals are attached to the broader company goals with the help of tools like Libby Boxes, we communicate the value of our work as well as the value of the community without question. Our unique talents shine as a result and are often sought after in order to support the company goals while still providing value to the community. When we then take the results of our experiments and show the direct impact we’re having on the broader company goals, we remind others throughout the company of the value that we bring to everyone involved, which allows us to continue bringing greater awareness, enablement, and engagement to our community.