Leveraging the Power of Community

Hi everyone! As ___ said, my name is Mary Thengvall and I’m here to talk to you how nurturing a technical community can benefit your product in tangible ways. I’ve been involved with a variety of technical communities for over 12 years now and I’ve observed a lot of patterns along the way.

The first pattern I’ve noticed is while companies understand that having excited and engaged customers who are essentially unpaid support, marketing, and sales teams can be extremely beneficial to spreading the word about their awesome product, they don’t always know how to create, foster, and grow that group of people.

The answer that a lot of companies are turning to, especially B2D companies, is Developer Relations. What is Developer Relations, you may ask? At its foundation, the purpose of Developer Relations (or DevRel) is to build relationships with the developer community. DevRel professionals act as a liaison between your company and the developer audience, who are typically the end users of the product. While most professionals have the best interests of the business at their front of their minds driving their day-to-day decisions, DevRel professionals have the best interests of the community as their driving factor. They, of course, care about the success of the business as well—it is, after all, what pays their bills—but they understand that if the community is happy and successful as a result of using the product, the business is far more likely to succeed as well. So these B2D companies are hiring a Developer Advocate or two — Developer Relations professionals who typically have a developer background — with the intention of building out these relationships with customers who will turn into unpaid external advocates of the company. This is every company’s dream! Hire one person who can in turn recruit other people to do the same work… for free! Right?

But unfortunately, all too quickly after these fantastic Developer Advocates are brought on board, the excitement about this new Developer Relations initiative turns from an exclamation point, lightbulb moment, into a question mark. And it does so for one major reason: metrics. How in the name of everything good, do we measure the work that these Developer Advocates are doing? And when you ask the Developer Advocates this question… this is their response.

Metrics — and the stakeholders who continually ask “what’s the ROI on that?” — have often been the bane of Developer Relations professionals. I know I can relate with this meme… I believe I’ve made that face myself more than once after a frustrating conversation with an executive who just doesn’t understand the value that my team provides on a daily basis.

But I also completely understand the viewpoint of the executive who desperately needs us to prove our value. After all, these departments aren’t cheap, between salaries, speaking gigs, supporting open source projects and communities, not to mention the event sponsorships. And what do you have to show for it? You can’t exactly go to your board and say that these Developer Relations professionals are traveling around the world speaking at conferences, creating sample applications that generate dad jokes, and contributing to open source projects that only tangentially relate to your core product. What we need is a metric that works for stakeholders (whether board members, company executives, or DevRel management) as well as the Developer Relations team.

Enter “DevRel Qualified Leads.” What exactly do I mean by DevRel Qualified Leads? And how exactly does this apply to metrics? Show of hands: How many people in the audience know what a Marketing Qualified Lead is? Most of you! Great. For those of you who don’t know…

How many of you gotten your badge scanned at a conference? Bingo! You’re most likely now a Marketing Qualified Lead for some company out there. In other words, you’re someone who the Marketing team has identified as a potential customer. They got your information — in this case, while at a conference — then vetted your information to make sure it met their standards or expectations, and then handed your information off to the Sales team for them to reach out to you with a sales pitch. Marketing has now done its part of filling the Sales pipeline, and their job is done. They aren’t responsible for making sure that person becomes a customer. That’s the Sales team’s responsibility.

This is a fairly well-understood business metric in most companies. It’s typically accepted that sales is a multi-step process and Marketing has the top-of-funnel responsibilities. Once Marketing’s job is done, they go back to finding new ways to create more “leads,” or people who have found the website, the company, or the product in some way, which they then “qualify,” or vet to make sure that they’re potential customers, and again, pass off to sales.

So some of you may be asking, why did I choose a term like “qualified leads”? Particularly when the jump can so easily be made to sales? For those of you who are familiar with my work, you know that I don’t believe DevRel or Community should ever (EVER!) have sales metrics to gauge their success. It muddies our work too much and changes what should be a genuine relationship into one that revolves around money, which isn’t sustainable.

However… most stakeholders understand the relationship of Marketing passing off work to sales when I say “qualified leads,” and the term is recognizable. Most of you in this room raised your hands when I asked you about it! While most people might initially only think of sales as the resulting success, you can add on top of the foundational knowledge rather than trying to introduce a completely new business concept and metric that people aren’t familiar with. By asking people to adopt a new definition of “leads” which includes “folks who can contribute value to the company in some way” rather than just potential customers, we can create an industry standard for communicating the value of a Developer Relations team in a way that’s not only understood, because we’re speaking the same language, but is also respected by stakeholders and executives throughout the industry. Tweaking something slightly is always easier than completely rebranding, and in an industry where we struggle to understand the true value of Developer Relations, it’s necessary to adopt some of the known business terms in order to gain the respect and understanding of our colleagues and board members.

I came up with this term after meeting with yet another one of my clients, whose team had metrics that were traditionally given to another department, such as sales (how many people signed up for an account this month?), recruitment (how many applicants did we get this quarter?), or marketing (how many leads did you get at that conference?). And let me just say… I don’t blame companies for passing down these types of metrics. I completely understand that we have to have metrics in order to communicate value, and that Developer Relations often feels like trying to put a square peg into a round hole when it comes to setting metrics based on the standard business definitions of success. However, these are all items that DevRel Professionals have zero control over. Who knows whether the person we met at the most recent conference will even apply for the job, let alone whether the hiring manager will hire them. Maybe their application won’t make it through the system because of the one quirky thing about their education, or perhaps they don’t click with the hiring manager. Whatever the case may be, we can’t be held responsible for whether or not that individual got hired… we have no say as far as salary, compensation, or any number

Maybe the team encountered someone who’s answering questions on your forum consistently and has obviously had a very good experience with your product. That community member might be a good contact to pass off to Marketing for a Case Study. Or perhaps they’d be interested in turning some of their longer forum pieces into a blogpost.

If your team is getting exceptional feedback from an individual, passing them directly to Product might be a good idea. The Product team will be able to have a longer-form conversation with that community member and parse the important pieces that they’ll implement in future features rather than you playing messenger. Or if the you’re getting close to rolling out a new feature that a handful of community members have been asking for for some time, perhaps you pull them in before it’s released to the public for beta testing.

Or perhaps a community member has stumbled on a particularly hard-to-solve bug and is willing to help your engineering team reproduce it and get to the bottom of it.

Maybe one of your Developer Advocates meets another Dev Advocate who is willing to help build out an integration that will help customers use your products in tandem. Your Business Development or Partnerships team would be more than happy to handle that conversation going forward.

On occasion, the Developer Relations team comes across community members who just get it. They click with everyone at the company. They understand the product. They’re passionate about the cause. They’re already contributing during their free time anyway… so when a position opens up, they’re a perfect person to pass off to recruiting.

And of course, they’ll occasionally run into someone who’s interested in purchasing your product, so they’ll pass them (or the manager or team lead) off to sales. You get the idea… these connections are incredibly valuable and might not have ever happened were it not for the Developer Relations team’s direct involvement in the community who now knows and trusts them.

These DevRel Qualified Leads are incredibly important to keep track of for a number of reasons, the most obvious reason being, of course, that it’s a definitive way to attribute value to the activities that the Developer Relations team is involved in. Additionally, in aggregate, it’s a valuable way to see which activities overall are more effective than others in the long run as well as track themes throughout the industry. For instance, if the DevRel team meets three front-end developers who are really interested in your product, which is traditionally focused on ops or security professionals, they’ll make a note of that. Or perhaps they start to see more interest from a non-technical group of folks. Keeping track of these outliers and reviewing their notes at least once per quarter will help them determine new patterns in your audience, which can help inform the personas that the marketing and products teams work on.

These leads also contribute community value, because as you’re making these introductions between community members and your coworkers, you’re also making introductions between community members. And this leads us to my favorite analogy for Community Building, thanks to my good friend Amy Hermes: Community Management is a pseudonym for cruise director. Those people who all mentioned the new topic that they were pursuing? I, as the community cruise director, am responsible to introduce them… to foster that relationship… to make sure that they’re not only pursuing that topic and reporting back to me with interesting tidbits, but that they’re enjoying doing so. Part of what we can do to ensure this is build a community around that topic, which, of course, requires other people. So Marie, let me just introduce you to Bob over here, and the two of you can chat about the latest doodads and thingamabobs that you’re looking into, and let me just fade into the background while the two of you get more and more excited about this fascinating topic.

We as Developer Relations professionals have a unique talent — we don’t tend to wind up in community by accident — we’re already doing all of these things in our personal lives, and many of us just seemed to stumble into this work by default. We have this talent of connecting people, bringing people together, making people feeling comfortable and confident and empowered. This slightly expanded definition of Qualified Leads allows us to highlight this value rather than be forced to find a more traditional metric that encapsulates our unique abilities.

But… so what? Who cares? Why, at the end of the day, do these connections truly matter? They matter because of the core definition and purpose of community building. At its foundation, the purpose of community building is to build relationships with, empower, and enable our various communities. And this empowerment is beneficial for both the community and the company.

I love this quote from Zan Markan’s blogpost “Developer Relations is Developer Enablement” and I think it applies to all communities, whether they’re technical or not: “Enabled developers are productive, less likely to churn, and better suited to champion our products and services inside their teams, organisations, and wider networks.”

Twilio’s Developer Evangelism team puts it this way: Our job is to inspire and equip developers to build the next generation of amazing applications. This means understanding what they are trying to do, pointing them to tools and training, and generally helping them be successful. Is this an inexpensive endeavor? No! But is it worthwhile? Signs point to yes! When Twilio was first founded, they were told they didn’t stand a chance with a developerfocused, community-driven strategy, but they went on to land a 1 million dollar seed round from a group of angel investors and one VC. The first full-time employee that they hired, Danielle Morrill, built out what is now acknowledged as the startup world’s most effective developer marketing program and is now an investor and startup founder in her own right. Now, with customers like Dell, Twitter, Lyft, Salesforce, Hulu, Twitch, Intuit… the list goes on… they continue to cater to developers and build out what is now known as one of the top Developer Relations teams in the entire industry. Twilio has invested a significant amount of money into something that they were told would never make them successful, because they understood the true value of

And this leads me to my final point. We need a single metric of success that can be used across the industry to prove the value of Developer Relations. Far too often, the best answer to the question “what are your metrics of success?” is “well… it depends!” and let me be clear — that’s not a BAD or WRONG answer. What success metrics you use really does depend on the company! I tell all of my clients, “Your goals for the community need to be aligned with goals for the company,” which means, realistically speaking, that the Developer Relations initiative is not going to look exactly the same in every company. But having a single metric across the industry that everyone can point to and understand is an important part of moving the Developer Relations industry forward. For Developer Relations teams, it helps them assign a success metric to something they were already naturally doing on a day-to-day basis. And for executives and stakeholders, it helps you point to one of many outcomes that not only drives forward company awareness, but actively (and tangibly) proves the value of nurturing a technical community.

Thanks so much for your time today! You can find my information up on the screen behind me. Much of what I’ve talked about today comes directly from my book: The Business Value of Developer Relations. I’m always happy to chat more about community building and developer relations! Please don’t hesitate to find me later today or reach out after the conference.