Welcome to the Uncommon Book Club - a gathering place to learn from community authors. We had the pleasure of hosting Mary Thengvall to discuss her book, The Business Value of Developer Relations. The conversation focused on topics around a few themes from her book, including the value of a developer community, how to build one, and how to maintain positive relationships with that community.
We've highlighted a few key questions below, and you can hear all the details in the video above.
One of my favorite passages from the book is the DevRel mantra you share: “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 advice do you have to help successfully maintain this juggling act?
It is definitely a juggling act. I think the biggest thing here is there's a lot of times when I feel like we overthink this, right? We feel like we have to be perfect. We can't possibly show up with a hair out of place, or the wrong word that we say in the title of our talk, or anything like that, right? We have the impression that well, I'm a representative. So I have to be officially representing, which means I need to know everything, I need to have an answer to every single question. I need to be completely on at all times. And that's not true. I think it's far more important to be human, be available, be accessible to people. And part of that is saying, "Hey, I don't know the answer to that question, but I do know the person to point you to" right? Or I don't know the answer to that question and let's figure it out together.
Let's dig into the documentation, let's dig in to the code, let's find the answer together. And so in doing that, you're representing the company, you're representing that we value the community, we value the feedback, we value the information that you're bringing to us. And you're being authentic as well and saying, I don't know everything and that's okay. And I don't need to know everything. But then the idea of then taking that authenticity that you're displaying with the community member, and taking that back internally as well is a huge part of it. Because I've worked with a number of companies when I was consulting, who everything was external, everything was to the community. And so, very little of what they did was then going back internally and saying, "Hey, by the way, we went out to these places, and we had these conversations and we did these things. And here's the feedback that we heard, and the information that people gave us and the conversations that we had."
And so, there were companies that I went and worked with, where employees were there for, like leaders in the company had been there for three or four years. And I asked them well, cool, to you what does the developer relations team do at the company? And their answer was, I don't really know. Like, okay, but you've worked at the company for three or four years. And you're a leader that they should be interacting with fairly often. What do you mean, you don't know? And they're like, well, I mean, they give talks at conferences and they talk to our community members. And that's about the extent of what I know. And so, if we're not taking that information back internally, if we're not engaging with the other teams across the company, I'm not surprised that company isn't going, I don't actually understand what it is the developer relations team does, or what it is that the community team does.
And therefore, laying the team off when budget becomes an issue or things like that, because there's no internal awareness of, here's what we're doing, here's how we can be of help to you. Write that internal enablement of your co-workers to say, "Hey, I actually know a lot about that project that someone's asking about, a prospect is asking about, do you want me to hop on the call with you and try and walk through the code on that side of things?" Or working with the product team and saying, "Hey, for the roadmap, here's the feedback that I'm getting, I can give you additional insights into these pieces of feedback that we're hearing and considering for the next roadmap." And so, the more that we're spending time internally at the company, talking to people and making them aware of what projects we are involved in, making them aware of what the community is saying.
While at the same time being outside talking to the community members and getting additional feedback and spending time with them and being authentic with them, we really have to have both of those pieces in mind at all times. Because if we don't, we're either going to be shortchanging the community and not giving them the time and attention that they deserve. Or not putting ourselves in a position of value internally in the company. And also, again, shortchanging the community, because we're not spending time in the company explaining here's the pieces that we need to advocate for on behalf of the community members.
When it comes to community platforms, you stress the importance of meeting your community where they are, rather than “build it and they will come.” Why is that and what’s your recommended approach to identify your primary audience to focus on?
That's a great question. So there's not a magic answer to say ask this question and you'll know exactly who your audience is. But I will say that the thing that I always have people start with is who are the people who are most successful with your product, right? Are they front end engineers? Are they back end engineers? Are they the DevOps team? Is it someone else entirely? But what's your primary current community of users? And then building up those personas. And so then being able to say, great, they are front end developers who use React, who use these other platforms or these other frameworks. And they're trying to answer these questions and hears their pain points. Because once you have a fleshed out persona like that, then you can go, okay, great, where do these people hang out? What types of resources are they looking for?
And if you don't know the answers to those questions, go talk to your community members. And just say, "Hey, I'd love to hop on a 15 minute call with you. I know you tend to use our product to solve these issues, these problems, where are the places that you get more information about process automation? Where are the places you get more information about microservices? Where are the places where you get more information about cloud?" And by listening to them as the people who you're using your products currently, you're then able to kind of go, okay, great, there's four or five different places that they said they tend to hang out. Chances are, if those get repeated by another community member, you're going to find a quorum of community members or potential community members in those places. And then that's where I started experimenting, right?
Where if you have a list of, hey, here's the five top communities that people are really hanging out in that we think our community is going to be a part of, then you start kind of just go hang out in that community. And when I say go hang out, I actually mean, go hang out, set an hour a day aside and go read the latest conversations, find out what people are talking about, look at the topics of conversation that are coming up on a regular basis. And don't hop in there and say, "Hey, I'm here and I'm from this company, and let me know if we can help you solve any problems because we do these awesome things" right? Because that the second that you do that everybody's going to go, okay, I don't want to talk to that person. And that's the best case scenario, the worst case scenario is people go, nope, sorry, that violates our code of conduct or our rules, and you're no longer a part of this community. But by going and looking, observing, keeping an eye on what the conversations are, what's going on, you have an opportunity to learn.
And it might be that you do that for a week with a particular community and you go, actually, this isn't the right place, this isn't a place where our community is likely hanging out, or the right questions aren't being asked here. But if you can establish, hey, this quarter we're going to go research five additional places to go see if that's a viable place for our community to be. Then you can come back at the end of that and go great, yes, we hit all five of those. Three of them have potential for next quarter. And then you can start building up a little bit more of a plan to be more intentional about your involvement, right? Start answering questions, start pointing people back to the resources that you have, or start creating resources so that you can actually have those resources to reference later, or delegate those resources to other people in your company if you need to.
What are some practical techniques to begin to improve and build a community without wholesale "hiring a DevRel" team? How do you encourage and structure creating and incentivizing good DevRel content in that "gap?"
I love this question. Because I see a lot of companies asking this and it's, I understand why they're asking this question, but it's also I will say one of the more controversial questions. Because, and I don't want to put words in the person's mouth who asked this. But the way that I normally see this being asked is, from decision makers and budget holders at companies who go, I really don't want to have to pay someone to do all of this until we understand that there's value there. So let's just, you do a little bit, you do a little bit, you do a little bit, but it's no one's real priority and we'll just see what works. And more often than not when I see that happening, because it's not a priority for any one person. And because those people that that work is kind of farmed off to, they don't usually understand how to do it, or what it is or what the purpose is behind it, or why it's valuable, it just doesn't happen.
And so then the decision maker goes, well, nothing really worked, it's not worth it investing in, we aren't actually going to hire a DevRel team, that's not going to work for our company, we don't need a community we're good, let's move on. Which might not be the case, right? And so I think if you aren't able to make the business case right now for hiring someone to focus on Developer Relations, finding someone at your company who cares about that topic, who is passionate about that topic, is something that you have to start with. Because if you can find someone, maybe it's one of your engineers who is already talking to the community, already attending conferences, already very interested in getting feedback from people who were actively using the product. Maybe it's a product manager who wants that product feedback, right?
But if you can find someone like that who intrinsically understands or instinctively understands the intrinsic value there, then they'll be more motivated to help out with that. I would say start with creating content if you have an excellent writer on your team, and you have engineers who don't want to write but have great stories to tell, go straight some of those stories, right? Hop on to a 30 minute Zoom call with them, record the Zoom call, have the person transcribe it afterward, make it a little more storytelling, spice it up a little bit with more information and kind of get the flow right. And then send it back to the engineer and go great, do we have your permission to publish this? Does this work?
Cool, and start creating content in those types of ways where it's not taking someone's full time or taking their attention away, but you're using the talents of the people that you have to kind of fill those gaps along the way. So it's controversial, but I think if you can do it in a way where you know, hey, this would be a good investment I just need to prove it. Finding those little allies in different companies or in different departments excuse me, to be able to say, hey, [00:33:00] you really want to get product feedback from our customers? Can I get your help to help with phrasing this, or help with having one-on-one calls more often or things like that. That you really want to get out and attend a conference and speak at a conference, but you're a little unsure about your speaking ability.
Let me give you some speaking coaching and let's submit a couple CFPs and see what happens, right? So finding those people who are invested in that and passionate about it, I think is the best way to get started if you weren't able to get budget yet. But if you can get budget, I highly recommend getting budget and having one person actually connected to that mission.
You talk about how being successful in DevRel requires a large amount of trust from the developer community - trust, or social capital, that’s hard to earn and easy to lose. Can you share any best practices or tips to maintain a high level of trust with your community? How about ways to recover after a blunder?
So I think there's a couple of things here, the ability to gain or maintain that trust, I think is not something that only the DevRel team can do. It's something that has to be a commitment from the company. And so, I've seen companies, I've worked with DevRel teams, where the DevRel team is fantastic about soliciting feedback, or making sure that they've taken note of the issues that people are having. They're great at scouring the forums for patterns and identifying those patterns and what could be done to fix it and all of these types of things. And then the product team goes, "Cool, I don't have time for any of that, thanks for passing it along. But none of that is on the roadmap, none of that is going to happen. The earliest any of that might be taken into account is like a year and a half from now."
And so there's situations like that where the community starts to learn, "Okay, well, they're not listening anyway so why should I take the time to attend a product feedback session? Why should I reach out to the developer relations person or the community person and give my feedback because nothing's going to happen with it anyway?" So if I run into problems or there's bugs that need to be fixed, or I can't use the product because I need this feature and they don't have it on the roadmap, I'm out of luck, and there's no real point, am I continuing to invest in the community when they're not willing to invest in me. So I think making sure that you have buy in from products, right? Maybe it's, "Hey, for every release that we have, we have one community piece of feedback that's integrated into the roadmap."
Something that I've seen be very effective for DevRel teams in communicating that feedback is, for every product that you're representing, you have a list of five pieces of key feedback from the community. And those are our top five, it's only the top five, that top five might change on a weekly basis. But the product manager always knows, look, if you're looking for something that will really, really, really help the community and make people really happy, here's what you should do. But you have to have that commitment from product which means you also have to have the commitment from engineering, which means you also have to have the commitment from senior leadership who says, "Yeah, that's the direction that we want to go in." And it really boils down to, is community actually valued by the company? Or is it just hey, we just want to put out a product and get enterprise customers.
And the interesting thing to me is when companies go well, I mean, the community is important but really we care about the money, right? And what people often aren't stopping to think about is that, if you're taking care of the people who are using your product, and making them feel good about giving feedback, and acting on that feedback and showing that you're listening, those customers aren't going to leave. They are going to stick around, they are not going to go anywhere, they are going to tell everybody about you. And at the end of the day, you're going to wind up with more paying customers because the community now knows, we can trust you and you have our best interests in mind. And you're actually working toward making this a far more effective product for all of us. And I think when it comes to earning that trust back, being honest about the mistakes that you've made.
When you approach the community the next time for product feedback openly saying, "Hey, we know the last three times that we've come to you with this request, we haven't been able to follow through on it. As a team, here's what we're working on, here's how we're trying to make that a better experience for you. Here's the responses that we have. And look, we are committing upfront, without even having this conversation, we are committing upfront to applying at least one of these suggestions to our next roadmap for our next release." And so being able to make that commitment, and you might still have people that are very hesitant to step up and give that feedback and offer that information and take their own time for that. But if you're upfront about "Hey, we screwed up, and we know it, and here's what we're doing to fix it." It's a step in the right direction at least to say, we're listening and we know that we need to do better in the future.
There is a lot of great information in the book. What are three concrete actions you suggest people take after reading it? Are there a few high impact actions or questions that can make a good starting point?
So I think the first one is really know who your audience is. We talked about this a little bit before but making sure that you actually know here's the people that were talking to, here's their needs, and never losing sight of the fact that you're working essentially for the community, right? The company is paying your paycheck, but the work that you're doing is for the community. And so you need to know here's their common needs, here's their pain points. Here's the things that we need to solve for them in order to make this effective. We talked about this a little bit earlier, always tying your efforts back to company goals. Always making sure that if someone goes, "Hey, why are you doing this particular program or writing this material, this series of blog posts or trying these experiments?" You're able to say, "Oh, well, these blog posts have to do with our basic industry as a whole, not vendor specific, but how best practices in this area which then leads to greater awareness of that topic which then points people back to our company."
Because if people know about process automation, they know about CUDA, right? And so drawing that line back so that you're always ready to answer those questions is a huge part of that, and really helps solidify your relationship with the community stakeholders, or the company stakeholders excuse me. Because if they see that you're able to provide those quick answers, then they start to learn to trust like, "Oh okay, they know what they're talking about, they're an expert in their field." And they'll likely start coming back to you when they have needs or things that they could use advice for, or help on or any of those things where they go, "Okay, hang on, I don't know the community as well. Steven does, let me go back and talk to him about what's going on and what topics I should touch on for this piece of content because he's far more aware of what's going on there."
And the last thing I would say is, don't be afraid to speak up and really insist that your voice is heard. I think so often, it goes hand in hand with we tend to be people who say yes to everything. We also have a tendency to say, "Okay, well, I said my piece, and I did what I could, but it's not getting through." And so I think remembering that sometimes just because it makes sense to you doesn't mean it necessarily makes sense to other people at the company. Making sure that you're speaking their language and really translating to a certain extent the communication from the community back into the company, so that your voice is heard because you are the voice of the community member. And so you're representing like we talked about being, right? You're representing the community back to the company and it's important that that is heard.
And so, making choices about which times you need to say actually not and put my foot down, this needs to be said, this is not going in a good direction. I need you to listen to me because this is what I know, this is what I do, right? And making sure that you're speaking up loud enough and in a way that people are going to understand that they can actually hear you advocate for the community in a way that makes sense to them.
