A presentation at Vanilla Forums Webinar by Mary Thengvall
1
Some house keeping items. Today’s webinar will be recorded and will be emailed to you so you may watch it again at a future date. You can ask questions at any time during the presentation using the question panel as you see in the picture on the screen So without further ado, on to our presenters. 2
Hi I’m Adrian, the voice you’ve been hearing up to now. I am the Head of Community at Vanilla Forums. If you don’t know, Vanilla is a hosted forum platform used by many companies to connect with their communities. It’s also used by lots of developer communities. Just a small taste of customers using our platform include the Linux Foundation, Xamarin, Oculus and many many more companies looking to build an online space with their developers. We also like to focus on educating and supporting the community of those building these spaces. With that in mind, we’re so happy to introduce our guest speaker, Mary Thengvall who will be talking to all of us today about the Business Value of Developer Relations. 3
Mary Thengvall is a connector of people at heart, both personally and professionally. She loves digging into the strategy of how to build and foster developer communities and has been doing so for over 10 years. After building community programs at O’Reilly Media, Chef Software, and SparkPost, she’s now consulting for companies looking to build out a Developer Relations strategy. She’s also the author of the first book on Developer Relations: The Business Value of Developer Relations.
Hi everyone! As Adrian said, my name is Mary Thengvall and I’m the Founder of Persea Consulting. I’m really glad to be here talking to all of you today. You can find all of my basic information on the screen in front of you, including my twitter and my personal website where I have a blog, past speaking engagements, more about the projects I work on, and other ancillary information. Before I dive in, I thought I’d give a little bit of background for those of you who don’t know me. I have a journalism background, but have worked with various technical communities for over a decade and I’ve noticed more than a few patterns along the way. One of the biggest patterns that I’ve noticed is that many companies simply don’t understand the business value of community building, and more specifically, Developer Relations. 5
As a result, I founded Persea Consulting in late 2017. The goal of Persea Consulting is to provide resources and education about Developer Relations and Community Management both for those who are practicing in those areas as well as the business decision makers who are trying to figure out what in the world those terms mean. In doing so, my overarching mission is to advance the Developer Relations industry as a whole. The logos on the screen are a handful of the resources I provide as a part of this goal. The most relevant one for today is the book on the far left up there: The Business Value of Developer Relations. A lot of what I’ll be speaking about today is also covered in the book in far more depth. As you might have seen in the promotions for this webinar, Adrian’s got 5 copies of my book to hand out to attendees today, which is exciting, so stay tuned for that! All this to say… I do a lot and have a lot of side projects and am very involved in a lot of things. but most importantly, I’m incredibly passionate about driving the Developer Relations and Community Management industry forward and working with companies just like yours to make sure that both the communities that you’re building and the DevRel professionals that you’re employing are set up for success. 6
Today I’m going to talk to you about just that: how to set up a DevRel team for success within your company. These principles will apply to you whether you’re in the DevRel trenches or simply DevRel-curious. First, we’ll touch on “What is Developer Relations” (including the difference b/t Community Management & DevRel)? Before moving to asking why we need to advocate for DevRel… after all, it’s a buzzword, right? Next, we’ll explore why we need to put resources behind building relationships w/ developers? After all, can’t we just set up a “developer welcome page”? We’ll also touch on setting expectations internally with stakeholders and board members. And I’ll close you out with a few tips on where you can start. Buckle up… we’re covering a lot today! So first of all… let’s make sure we’re all on the same page here with definitions. What is Developer Relations? 7
Let’s first address the elephant in the room. There are avocado versions of people on the front of my book cover… there’s an avocado logo for the DevRel Collective Slack team… and if you’re particularly observant, you’ve likely noticed that my business logo is an abstract avocado as well. So… why avocados, you might ask? Besides the fact that they’re amazingly delicious (I can say that… I liked them before #avocadotoast took over our world), Developer Relations has become known as “the good kind of fat” within tech circles. This was an analogy that picked up steam 3 years ago while I was working with the Developer Relations team at SparkPost, an email API service based here in SF. It all started because one of our Project Managers had a hard time saying “Developer Advocate” when she got to talking quickly. Instead, it often came out as “Developer Avocado.” 8
Given how much my co-worker Aydrian Howard loves avocados, he took on the mantle of “Developer Avocado” without much prompting 9
…and as the team grew, we became known as the “Developer Avocado team.” We decided to own this title — not only internally, but externally as well, and pretty soon, an analogy was born. You see, as a notoriously expensive department, what with sponsorships, swag, travel, and a general lack of traditional ROI numbers such as lead generation, we’ve become known as a “fatty” department. But I’d argue that we’re the good kind of fat — and that when used in the right ways, at the right times, with the right combination of items, our efforts can result in incredibly healthy and beneficial benefits not only for our community, but for our company. And with that explanation in mind… let’s move forward. 10
In order for us to define Developer Relations, we first need to define Community. I’m guessing most of you here today are aware of what community is at its essence, but here’s the definition that I’ve been using for a few years that seems to ring true no matter what industry you’re a part of. <CLICK> Community is a group of people who not only share common principles, but also develop and share practices that help individuals in the group thrive. How you define who falls into the realm of community at your particular company will depend on what your intentions are — I cover more about this in my book — but in general, “community” includes your current customers, as well as prospects, and anyone who could in the future be interested in using your product. 11
So how does this fit into Developer Relations? Developer Relations is the umbrella term for the team whose primary responsibility is building a community both online and offline. This includes Developer Advocacy, developer event management, community management, etc. It can even go so far as to include roles like documentation and developer education and training at some bigger companies like Twilio or Microsoft. 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 their company and the developer audience—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. <CLICK > I like this little mantra to explain that symbiotic relationship: To the community, I represent the company. To the company, I represent the community. I must have both of their interests in mind at all times. 12
So what’s the difference between DevRel and Community Management? Honestly… it’s not all that different. It’s basically community management with a technical audience, which has existed for decades through Open Source Community Management. So why is there a separate name and industry building up around it? The short answer is that when companies started creating developer-focused products — ones where the end user is a developer or someone who works with code on a daily basis — they needed technically-minded people to communicate to the technical audience. So they started finding extroverted developers who were able to write technical content, willing to speak at conferences, and interested in helping the greater technical community understand why their particular product was one that they should be paying attention to right now. The biggest difference between traditional community management and Developer Relations is that you need tech-savvy individuals on the team. You’ll notice I said tech-savvy and not someone with a technical background. I’m very keen on this point, largely because as I mentioned earlier, I don’t have a technical background. In fact, my journalism background is a HUGE asset for me, allowing me to make observations and draw patterns where others might not see the same correlations. It 13
To the community, I represent the company. To the company, I represent the community. I must have both of their interests in mind at all times. 14
So I prefer to look at DevRel & Community Management like this… not in competition to one another, but instead, working together to achieve a complete goal: empowering and educating their technical community. 15
So now that we all have an understanding of what Developer Relations means, we can move on to our second question: Why do we need to advocate for Developer Relations? After all, DevRel and Developer Advocacy are huge buzzwords these days, which may make you think that we don’t need to advocate for it internally. After all, I spread the word about 140+ DevRel-related jobs every week in DevRel Weekly and that number is growing exponentially — I recently published a blogpost with data from my first year of running DevRel Weekly that shows as much — the link is down in the bottom right if you’re interested in learning more. But despite it’s “buzzwordiness”, we still have an education problem among stakeholders and board members within these companies. Hiring a Developer Advocate or Technical Community Manager has become a checkbox item -something that companies must have, but often one that they don’t understand. There’s not always a need to advocate for a team or a role to be created, but there IS a need to prove the business value once the team has been created. Otherwise… 16
Best case scenario: these teams wind up shuttled into a variety of jobs (social media management, sales, product implementation, etc.) that aren’t a good fit (aka square peg, round hole). Worst case scenario: the whole team gets dissolved because the stakeholders only see the money spent and not the value derived. Either way, burnout, confusion, and frustration ensues. So when stakeholders — VPs, C-suite, or the board asks you what the point of DevRel is and what value they bring to the table, what do you say? Do you, as community professionals, have an answer? Or, do you, as the board or C-suite member, know enough about the value that Developer Relations and Community Management can provide to know what goals and metrics to be asking for? 17
And here’s the real question behind the “Why?” — why do we need to put resources behind building relationships that may or may not pay off in sales in the long run? Why not just put up a developer welcome page letting devs know that we’re there for them and then let Sales & Marketing do their jobs with the buyers? We’ve got documentation… we’ve got technical account managers and customer support… we’re exhibiting at developer conferences telling people what we do… why do we need to take the time to actually build relationships with the technical community? 18
If we build it, they will come, right?! 19
Not so much… The reality of the matter is… developers don’t just appear out of nowhere, magically having sensed that you have a developer site on your webpage now. This is where relationship-building comes into play. But it’s not just about spending money on developer events or buying community members a cup of coffee when they’re in town. We need to put some actual goals behind this relationship-building venture. 20
By understanding the true needs of our technical audience, we have a unique opportunity to meet those needs. But again… it’s not magic. We don’t just show up to a meetup one time and have developers lining up to tell us what their needs are. It takes time to build trust and have enough conversations with them to understand what the true needs are under the surface. 21
Understanding our audience’s needs results in a number of questions. For instance… ○ ○ ○ Which needs can you already meet? This question can be answered by your sales dept. Which needs could you potentially meet in the future? You’ll go to your product & engineering teams for this answer. Which needs aren’t in your scope, but could be accomplished through a partnership or integration? This is a conversation for business development / integrations. 22
Ultimately, understanding the needs of our audience allows us to enable them. Not to market to them or sell to them, tho understanding their needs helps us help our teammates to do that as well, but the role of Developer Relations is enablement. I love this quote from Zan Markan’s recent blogpost: <CLICK> Enabled developers are productive, less likely to churn, and better suited to champion our products and services inside their teams, organisations, and wider networks. 23
So what does this enablement look like? It means your product is fulfilling a need that a developer has. It means that once they’ve decided to use your product, developers can get up and running on your platform quickly. It means that once they’re up and running, if they have questions, there’s a community ready and waiting to help if they run into any issues — perhaps on a platform like Vanilla! It means that if they do run into any problems, you’re available and willing to hear their feedback. Lastly, it means that when you find a community member who may be a good fit for a project elsewhere in the company, you make the appropriate introduction. You’re all familiar with Marketing Qualified Leads? I like to call these “DevRel Qualified Leads.” 24
I came up with this term after meeting with yet another team who had metrics traditionally given to sales (how many people signed up this month?), recruitment (how many applicants did we get this month?), or marketing (how many leads did you get at that conference?). These are all things that DevRel and Community Professionals have zero control over. Who knows whether the person you 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, but the hiring manager said they didn’t care. Whatever the case may be, you can’t be held responsible for whether or not that individual got hired… you have no say as far as salary, compensation, or any number of other negotiating factors go, or whether they’ll be a good fit with all of the other team members. However… you DO have control over knowing things about your community members, which puts you in a unique position to make connections that are useful not only for your community but also for your company. So what does this look like? <CLICK> 25
Once we understand what needs our audience has, we can set about improving their experience. Developer Advocates (the DevRel teammates who have often been a developer in a past life) have a unique advantage here, since they’re often able to make tweaks to the product themselves, filing pull requests (changes to the code) or advocating for particular solutions from within engineering. But this is also why everyone on the DevRel team needs to be technically savvy -we’re the intermediary between the various departments, but we’re also the gobetween between the community and the company, which means we need to be able to translate the needs of the community back to the reality of the business, and vice versa. Our ultimate goal for those interactions is to improve the experience the developers have when they interact with our product. 26
There’s a super fancy term for this… it’s called Developer Experience. Bet you couldn’t have guessed that ;) It’s a fairly straightforward idea but I really like this definition from Hackernoon: DX describes the experience developers have when they use your product, be it client libraries, SDKs, frameworks, open source code, tools, API, technology or service. 27
David McKay gives us another way to look at it: A good developer experience is making it so a developer will succeed with intuitive decisions rather than informed decisions. 28
So let me play Devil’s Advocate for a second, because there’s a somewhat valid question here if you aren’t familiar with the value that Developer Relations brings to the table: Why do we need a DevRel team to get this feedback and improve the Developer Experience? Couldn’t this be done with a combination of Product or Marketing surveys, engineering support, and a technical writer hired to write a good blogpost or two or improve the documentation? Which leads us back to this mantra from the start of the webinar: 29
To the community, I represent the company. To the company, I represent the community. I must have both of their interests in mind at all times. What is it that sets DevRel apart… that makes us uniquely able to fulfill the relationship-building and listening and understanding that goes hand in hand with building a community of loyal customers, is that our primary focus and our goals are first and foremost based around the community. This focus and attention gives us the opportunity to build up trust among the community. When they know that we’re asking them for feedback so that we can advocate for their needs internally, they’re far more likely to be honest with us. Authenticity breeds authenticity, and while it’s entirely possible for Product & Marketing Professionals to have this viewpoint as well, their priorities are split between feature releases and lead generation, respectively. 30
There’s a fairly obvious answer here… a better experience benefits the community because they have an easier time using the product. They’re able to more easily get onboarded with your product; they have a better experience with the docs because you’ve worked with the support team to better explain & resolve some of the major questions; they can easily find answers and also offer answers in the forum; they know that they have a team of people who have their best interests at heart. 31
So here’s the more important question: How does it benefit the company? Well… Adrian… how much time do I have left? Because I could go on about this for hours! Let me try to distill it into a succinct list… 32
Let’s start with the most obvious one: When your customer knows that they’re using a product that not only suits their needs, but also working with people who care about their needs, they’re genuinely happy with their decision to use your product. 33
As my friend Jeremy Meiss says, the core of DevRel is building relationships with developers. And at the core of building relationships is the mantra, “Developers don’t care that you know until they know that you care.” 34
While “caring” seems arbitrary and a bit ambiguous, there’s a direct benefit here -your care directly results in customers caring, which leads to things like direct feedback. Ask any Product person how difficult it is to get solid, consistent, useful feedback. Better yet… tell them that you know of a way to get solid, consistent, useful feedback, and they’ll be eating out of your hand, begging you to let them in on your secret. 35
This next one is closely related… beta testers who are engaged and excited to be helping, and who… guess what… will give solid, consistent, useful feedback. 36
Sticking with the Product theme for one more minute… with an engaged community of customers, you’ve suddenly got folks who are very invested in giving you feedback on your product roadmap. Now, you’re not always going to be able to implement that feedback, of course, but simply knowing what’s important to whom is a huge step in figuring out what to prioritize next. This is a big reason why I emphasize the need for a diverse community — you need to know what the problems are for your free or open source customers as well as your enterprise-level customers or else you’re going to find yourself in an echo chamber. 37
This one’s fairly obvious. A lower-tier customer you can keep for years is worth far more than 2 new enterprise customers who churn after a few months, both because of onboarding costs, particularly for companies who have Technical Account Managers, but also because of the amount of time that the Sales team invested in bringing that one customer on. 38
Let’s start with the most obvious one: When your customer knows that they’re using a product that not only suits their needs, but also working with people who care about their needs, they’re genuinely happy with their decision to use your product. With this customer loyalty comes the next point… External advocates. Suddenly, your customers widen the reach of your your marketing and sales teams… at zero cost. You could have the best Sales & Marketing teams in the entire tech industry, but your customers are always going to be better, because like all of us, developers trust people who are like them. 39
When your community begins advocating on your behalf, your reputation grows. After all, it’s no longer your Marketing & Sales teams advocating on your behalf… that’s not going to make waves… it’s literally their job. Everyone expects them to do that. But when others start advocating on your behalf, the industry starts to pay attention. They know that there must be something legit about the way that your product works, the way that you’re running your business, the way that you’re interacting with the technical audience that is unique and special… and they want to be a part of it. 40
Now if you take advantage of this attention and use it as a springboard to explain why you made the technical decisions that you did and how you’re doing things differently… say, how your product is changing the industry… and you do it in a way that’s relatable to your technical audience (perhaps by running things by your DevRel team, or even your engineering team, before releasing it?) you have the potential to be seen as an industry leader in your field. This sets you up for future growth but also allows you to become the Hubspot, the Twilio, the PagerDuty of your field. Your brand is suddenly the one at the top of people’s minds when they think about your particular niche. 41
And if you’re an industry leader, people start to listen to what you have to say. They understand that you’ve done the research… you’ve listened to and invested in your audience, and will continue to do so in the future. You care about them just as much as you care about your product, because you understand that if the community succeeds, so does your product. It’s a symbiotic relationship. 42
Alright. So now you know what your main goals are for Developer Relations, and the business reasons for implementing a team. So what next? 43
The first thing you have to do is set expectations, and not just with your team, but with your stakeholders throughout the company… with your board members… with your founder… with everyone and anyone who might be involved in this process. And as we’ve touched on, your DevRel team is going to be working with pretty much every team. This means your pool of stakeholders is much larger than just the person in charge of the department that you’re hoping to put DevRel underneath. 44
So what do I mean by stakeholders? Quite literally, stakeholders are those who have a stake in the business endeavor, though who your specific stakeholders are will differ from company to company. At an early-stage startup, the stakeholders might be the founder and the board. At bigger companies, they’re likely the heads of the departments—the CTO and CMO, for instance. In short, these individuals have a significant interest in what overarching tasks Developer Relations will be responsible for, as well as what metrics will be tracked in order to prove value. They’ll also be directly impacted by the actions of the Developer Relations team. You can usually figure out who these people are by asking a few questions: • Who outside of your immediate department is involved with the project? • What team may be affected by the project’s outcome? • Who gains (or loses) from the success of the DevRel team? • Can you clearly identify the benefit of this relationship for the DevRel team? • If your relationship with this stakeholder improves, does it positively impact your team? You’ll want to have a meeting with them to understand their expectations and help them understand the value that DevRel brings to the table. 45
And now you understand the title of my book :) But seriously, helping them to understand the value is an integral piece to setting up the DevRel team for success. 46
The key here is finding the business value that resonates with them. One of the key skills of a Developer Relations professional is storytelling. Not telling stories as in white lies, but taking the information in front of us and presenting it in a way that makes sense to someone else. Making data, both quantitative and qualities, relatable to someone else’s needs and desires. But this takes some research on your part. For instance, when you’re talking to your stakeholders, you’ll want a solid understanding of both what the company goals are and where this particular department head or board member is coming from — their goals — personal, as well as professional — their needs, their shortcomings. You’ll want to focus on the areas where Developer Relations can offer assistance, expertise, or value within the company. Which departments could be doing more but never get the head count? Which processes could be streamlined if additional help were provided? What’s out of the scope of your marketing team (for example, technical content), product team (for example, having one-on-one conversations with your community as someone who both understands your product and what the dayto-day developer life looks like), or engineering team (for example, being the public face of the company at various conferences)? 47
Understanding these key points can lead to consensus around not only what the Developer Relations team is responsible for, but what the overall company goals are as well. As a consensus builder, you have to understand how each department relates to the overall goals. You also need to know how your work relates to the overall company goals while at the same time supporting other departments. 48
I’m not going to go into this much because I cover it in far more depth in my book, but here are a few tips with regard to creating goals for your DevRel team. First and foremost, create a DevRel Mission Statement. This Mission statement will drive your goals and metrics for years to come. I know Carrie Jones wrote an article about this recently on Vanilla — the link is in the bottom right. The main takeaway from the article is that by crafting a singular mission rather than letting yourself and your team be pulled in a myriad of directions, you narrow your focus, honing in on the items that only you can do. You make it clear not only to you, but to your manager and stakeholders as well, that you provide distinct and unique business value which wouldn’t be reached without your team in place. 49
The primary way to remind stakeholders of the value that you provide is to consistently contribute to the overarching company goals. This not only shows that you understand the business priorities, but also that despite the long sell and time spent building relationships, the activities that Developer Relations is involved in are worthy of spending time and money on because they continue to push the company forward. 50
Don’t conflate work output with goals. This can be SO easy to do with DevRel. “I’m going to submit 3 CFPs this quarter.” “I’m going to create an editorial calendar this month.” “I’m going to have 50 conversations with community members at this conference.” While these aren’t bad things in and of themselves — they’re actually great tasks! -they don’t show how you’re contributing value to the company. They show how much money you’re spending (travel costs) or how much time you’re spending on something the customers will never see (CFPs or internal editorial calendars). 51
So we’ve covered a lot of ground today, as I promised! We covered what DevRel is… it’s building relationships with and advocating for a technical audience. We talked about why DevRel needs to be advocated for despite the fact that it’s a buzzword. We touched on the primary goals of DevRel: to understand the audience better so that we can improve their experience. We walked through the benefits of DevRel, including the formation of external advocates and the retention of your current customers. And lastly, we learned how to set expectations with stakeholders so that DevRel is set up for success within the organization. As always, I love chatting about Developer Relations — particularly the topic of how to set a team up for success. If you have in depth questions about your particular company, I’m more than happy to continue the conversation via email. Thanks so much for having me today! 52
What does Vanilla do? We help companies build engaging customer communities. (No need to go over bullets if you just presented the previous set of slides) 54
Talking points: A good user experience = business success If it’s easy to use and if it’s a rewarding experience, your customers will use it and come back and the community will be successful for you and your company. We have reinvented community forum software and we’ve moved it forward with innovations such as Reactions, an integrated gamification and reputation system, and peer-driven moderation. 55
Talking points: A good customer experience requires a well integrated community Integration means: 1. Vanilla can be themed to perfectly match your website and provide brand and visual continuity for customers 2. Login can be done through SSO so that your customers don’t face a barrier and don’t even know they are leaving your website 3. Vanilla has integrations to your favorite apps such as Salesforce and Mailchimp 56
We support your success, beyond onboarding. This is more support, this is about being successful at creating long term success with your community with a dedicated advisor. 3 parts: ● ● ● Training - tailored onboarding, training on software and on best practices of community management Launch - take care of migration and work with you on a smooth launch plan Grow - CSM regular checkpoints, works with you to measure, improve and scale your efforts. They are there to provide guidance and best practices as your community grows. 57
We handle more than 3 billion interactions yearly, so we can support communities of all sizes. 58
If you’d like to learn more about Vanilla, you can click contact sales on our website, or fill in the form to start a 30 day free trial, no credit card required! Linus Foundation, Xamarin, others. 59
Let’s look at the questions
I’ve dropped some information about my book in the lower left-hand corner of your screen and all of my contact info is up there as well. As always, I love chatting about Developer Relations — particularly the topic of how to set a team up for success. If you have in depth questions about your particular company, I’m more than happy to continue the conversation via email. Thanks so much for having me today! I’d love to take your questions if you have any at this time. 61
Everyone recalls the “Developers, Developers, Developers…” song from Steve Ballmer, and most companies know Developers are important, but what does that really mean? Are you ready to learn about Developer Relations and what it means for your company?
Watch as Mary Thengvall, a leading voice in the Developer Relations community explains the “Business Value of Developer Relations”. The following topics are covered:
The following resources were mentioned during the presentation or are useful additional information.
for free. You
can too.