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. In addition to her work, she's known for being "the one with the dog," thanks to her ever-present medical alert service dog Ember. She's the author of the first book on Developer Relations: The Business Value of Developer Relations (© 2018, Apress).

Mary is founder and co-host of Community Pulse, a podcast for Developer Relations professionals. She curates DevRel Weekly, a weekly newsletter that brings you a curated list of articles, job postings, and events every Thursday. She's also a founding member and "Benevolent Queen" of the DevRel Collective Slack team.

Mary is also a member of Prompt, a non-profit that encourages people to openly talk about mental illness in tech. She speaks at various conferences and events about building and fostering technical communities as well as how to prevent burnout in yourself and your team.

Mike: This is the Real World DevOps Podcast, and I'm your host, Mike Julian. I'm setting out to meet the most interesting people doing awesome work in the world of DevOps. From the creators of your favorite tools, to the organizers of amazing conferences. From the authors of great books to fantastic public speakers, I want to introduce you to the most interesting people I can find.

This episode is sponsored by the lovely folks at InfluxData. If you're listening to this podcast, you're probably also interested in better monitoring tools, and that's where Influx comes in. Personally, I'm a huge fan of their products, and I often recommend them to my own clients. You're probably familiar with their time series database, InfluxDB, but you may not be as familiar with their other tools, Telegraf for metrics collection from systems, Chronograf for visualization, and Kapacitor for real-time streaming. All of these are available as open-source, and as a hosted SaaS solution. You can check all of it out at Influxdata.com. My thanks to InfluxData for helping make this podcast possible.

Hi, folks, I'm Mike Julian your host of Real World DevOps Podcast. My guest this week is Mary Thengvall, she's a long-time builder of communities for companies like O'Reilly Media, and Chef. And author of the book on developer relations, The Business Value of Developer Relations, and runs a podcast, and newsletter of her own. Now she's helping companies create community-building strategy through a new consulting firm, Persea Consulting. Welcome to the show.

Mary: Thanks for having me, Mike, I appreciate it.

Mike: So, I want to start off with a really foundational topic.

Mary: Sure.

Mike: What is community in this context?

Mary: Absolutely. You start there, and I start there, they're most of my talks as well, just because I like to make sure that people have a shared definition. The definition that I always go back to with community is, and it relates to developer relations as well. But community for me is a group of people, who not only share common principles, but also develop and share practices that help individuals in the group thrive. So it's not just, "Hey, we're all on this platform." It's, "We're all on this platform, we have a specific goal in mind, and we're all helping each other."

Mike: Okay. A lot of us are pretty familiar with like the Python community, the Ruby community, or the Chef community, and then there's kind of the non-tech stuff. Like people that go to church, have a church community. Or we have the community of our neighborhoods. Are these the same community?

Mary: They have similarities.

Mike: Okay.

Mary: And it's that idea of, if you're in the Python community and someone reaches out on Twitter, or in a Slack team, or at PyCon for instance, which just happened. And they say, "Hey, I need help with these things." You'll likely find other people around you who go, "Oh, I know how to do that. Let me help. I'm more than willing to." In neighborhoods, you have things like next door, where someone will post, "Hey, I lost my cat." Or, "I need help with my garden." Or, "Help me out in these other areas." And people will jump in and say, "Oh, yeah, I'm more than willing to help out."

In those ways they can be very similar. There's obviously nuances with really just communities with technical communities, with neighborhood communities. And in some cases, they come together easier than others. Neighborhoods have the advantage of being in the same physical location, which is always really nice. Technical communities usually have forums around a particular product, or we use Twitter hashtags to kind of see what other people are talking about. And there's a big difference to me between communities of people, and community platforms.

And I know we have a lot to cover today, so I won't spend too much time on this, but just kind of a TLDR. The platforms are usually ways to bring people together to accomplish a specific purpose. A Python community platform for instance, you could have one for new Python developers, you could have one for experienced Python developers. You could have one for people who are willing to mentor folks, or people who are into Django, or whatever this specific piece of Python lore that you're interested in.

Mike: When you're talking about these platforms, are you talking about the medium on which they operate, or are you talking about kind of segmentations of that community?

Mary: A little bit of both, and those tend to go hand-in-hand. As you kind of see communities, larger communities, people who are interested in the same topics segmenting off, you'll often find software platforms that spring up that, you know, cool, the newbie Python people are hanging out on Twitter. The experienced Python people have a back channel slack team. The people, who are willing to mentor are on LinkedIn. So they're using already existing platforms to facilitate conversations around particular topics.

Mike: That seems like a bad thing.

Mary: It can be. The hard thing about that is, if there's not a specific person that's really taking the time to lead those groups or manage those groups, or build those groups of communities, that things can devolve fairly quickly with Twitter as we've seen. Or with Reddit or places like that where it's just not... It's hard to control when you don't own the platform, or when you don't own the conversations. But at the same time if you're not, owning the conversation as a company, then you aren't necessarily limiting people to what your viewpoint is. You're allowing people to talk and explore, and see what's going on elsewhere.

Mike: Yeah. I can't tell you how many communities I've been a part of where the platform we were on disappeared, and the result was there was no more community.

Mary: Right, right

Mike: It also disappeared.

Mary: Right, and that's difficult, because-

Mike: Oh yeah.

Mary: People become so used to a particular platform and so accustomed to how that platform works, and then suddenly even if it's not the whole platform disappears, but some companies will move a community elsewhere and only half the community moves. And then that community might die off, because, "Well I was really only here because Mike was here, and Mike didn't move to the new platform." But Mike was only there because Jony was there and Jony didn't move to the new platform either. And so, you can have this cascading effect of losing people, because the people who influence them decided not to move over to that new community place.

Mike: I love all this, because it starts to get into the topic of community management. And we're not just talking about how to manage technical communities, but we're really talking about management, maintenance and leadership of more community.

Mary: Right.

Mike: One of the things that's always been interesting to me is, communities are self-forming, but they're not really self-governing.

Mary: Yes, I love that phrase.

Mike: And yeah, and this is something that I think a lot of people take for granted. A community needs leaders.

Mary: Right.

Mike: With my social circle, there are certain people in the group that kind of take the lead on setting things up. And if they don't do it, then no one hangs out.

Mary: Right.

Mike: And it's not that we don't like each other, we do. It's just someone has to be a lead in a community whether it's formally, or not.

Mary: Right, right. You need someone to take that initiative to brings things together.

Mike: Yeah. So on that note, one of the most interesting bits about community is not... I mean, while the management is difficult, and it is a very interesting problem, how do you build a community? How do you start from scratch?

Mary: That's a question that I hear often, and the thing that I usually tell people is, "Don't start from scratch, because the people that you're looking for, the community that you're looking for is already out there somewhere. So, you might feel like you're starting from scratch, because you're having to go find those people, but don't just create a "Community Platform" on your website and expect people to show up, because they won't. This is not a "build it and they will come" situation in any way whatsoever. But if you think about it, if you can really figure out who your core audience is? Who are you looking for to contribute to this community? Who's insights are you going to see? Who's talking about Chef? Who's talking about DevOps? Which is what I was handling at O'Reilly a lot.

These different topics, if you go find those influencers, and figure out where they're hanging out? What websites they frequent? Which blog posts they follow? Which Twitter accounts they look to for their information, then you can kind of start gathering this list of influencers. Gathering this list of people, who are saying interesting things and keep an eye out for where they are, and then go to those same places. And once you go to that place, just sit back and observe for a while. Don't show up and go "Hi, my name's Mary and I have this great information from you, and I want to sell you one of these things", because everyone's just going to go, "who are you? And why do I care that you're here? And why should I even listen to anything that you're saying because I have no idea who you are?" But if you observe, and you get to know people and you become a part of the communities that those people are already in, then you can start saying, "Hey, I heard you talking about this issue the other week, and we actually have a solution of that." Or, "I'd love to get more feedback, because we're talking about possibly working on a feature that does that, and we want to make sure that it fits your needs."

And so as you're observing, as you're learning about this group and getting their input on things, then you can start to say, "Cool, thank you so much for your input. Thank you so much for your help. Also, we're building this community over here, would you like to be involved? Would you like to help us start this group of people talking about these particular topics?" And by that time, you should've been able to build up some trusts. You'll have been able to build up some authenticity. The people there know that you care far more about their needs than you do about just selling them on your product.

Mike: You probably don't want to go to a community on a very... On the same niche topic that you're trying to build a community on.

Mary: Right.

Mike: Like, if you're building an internet management platform, you want to have that sort of community there. Going to the Page Duty Committee is probably a bad place to do it.

Mary: Right, right.

Mike: You should be there, but-

Mary: Absolutely.

Mike: It's it going to go well, if you start trying to convince people to leave that community.

Mary: Right, you don't want to go in and poach people.

Mike: Right.

Mary: And this was interesting thing where we ran into at Chef, where we actually actively encourage people to not start a Chef meetup. We encouraged them to start a DevOps meetup.

Mike: Okay, why did you do that?

Mary: And the difference was... A couple of reasons one, starting meetups is hard. Getting people on a regular basis to attend, getting people to speak on a monthly basis is difficult as well. Getting people to sponsor is difficult too. And so, by opening it up to you know, don't just talk about Chef, talk about DevOps A) It widens the group of people that we're able to reach through our sponsorship, because we would sponsor the meetups. We would pay for the meetup fees, which were a thing at the time. We would provide food. We would provide speakers, if we had speakers in the area. We'd help out a lot, but by making it a DevOps meetup instead of a Chef meetup, it allowed the organizers to have a broader community of people that they brought together. It also allowed them to bring a variety of speakers, which made their jobs a lot easier.

It allowed them to seek other companies who were willing to sponsor, because otherwise, if it's a Chef meetup like well, "Chef will host." No big deal, why do you need someone else to host it at their building? Chef should provide that right, because you're doing it on their behalf?

Mike: Mm-hmm (affirmative).

Mary: So it made the jobs a lot easier for the meet up organizers, but it also allowed us as Chef employees, and as Chef community members to engage with a broader community sense and just the people that we already knew. So it let us get to know other people, who might have been using Puppet or Ansible or Assault, or any of those, where sure there are competitors, but we're all trying to solve the same problems for our community. And so if we could work together, we are able to solve those problems that much better, and learn and get to know from each other, what the best solutions might be.

Mike: There's something you said there caught my attention.

Mary: Mm-hmm (affirmative).

Mike: I have often found a failure mode in communities that I've been in, where you can kind of focus a community on two different ways. You can focus it inward of "I am here to serve the people that are part of my group." Or you can focus it outward of, "I am attracting new people to the community." And you can do both, but it's pretty hard. And doing just inward like that's not a bad thing per se. You could totally do that, but if you focus outward then you're going to like, that's also a good thing, but it's also not a bad thing. And it changes how you approach your community itself.

Mary: Right.

Mike: And the kinds of people that are in your community.

Mary: Right, and like you said, "Neither of those things are a bad thing in and of themselves." But I think without having both directions, you're going to wind up missing something along the way, because if you're only focused outward, then you're going to miss what's going on internally and not be able to communicate properly to your audience. If you're only focused inward then you're not bringing anything from the company back to the community. There's a mantra that I really like that's, "To the community I represent the company. To the company, I represent the community, and I must have both of their interests in mind at all times."

Mike: That's hard.

Mary: Right, it's a really, really hard balance, but without being able to have that balance, I can go talk to the community all I want, but I'm going to talking at them, not with them, because I'm representing the company. And if I turn around and I'm talking to the company about the community, I can be advocating really super had for the community members internally to the company, but I'm not going to be as equipped to turn around and go back to the community and say, "Okay, here's what the company had to say, here's what we're doing as a result. Here's the direction that we're going in, let me know, collect your feedback on those things and go back to the company again."

And so you have to be able to balance both of those things. And this is a lot of where the business side, the business skills of DevOps come into play, because you need to be able to have technical conversations with the community members. You also need to be able to go back inward and talk to your stakeholders about "Here's where the community's at. Here's what they're saying. Here's what they're thinking. Let me translate those things into business speak for you, if you aren't a technical leader. Let me help you understand the context around that, and all of those different things." You need to be able to have all of those conversations, and be able to communicate in both directions.

Mike: I think it's interesting that we talk about how we're building these communities from scratch isn't really building communities, communities already exist. I'm thinking back to the communities that I've been a part of, and one of my best friend, and my room mate when I lived in San Francisco, we've known each other for 19 years. We only met in person a few years ago, and this entire time we met in online community that had just been around for fricking ever. Which you talk to people that even older than we are about their times on the BBS's of the '80s and '90s, and you start to realize that communities have been around for fricking ever. So there's this criticism that I've seen rolling around about developer relations, and developer advocacy that it's this brand new thing and like, "Well, how are we going to mature this thing?" You were mentioning before we started recording that, that's not really true at all. So tell me more about that.

Mary: Sure. It's interesting, it's you know developer relations, DevRel, is a term that's really, really picked up in the last probably two years now. And gotten more popular, and developer advocates have been springing up all other the place, and you know, just people are becoming more aware of these terms. And so there's a lot more people asking, "Well, what is developer relations? What is a developer advocate, what does that mean?" And to me, developer relations is the industry term, it's the umbrella term for developer advocates for technical community managers. For technical writers in some cases. For all of these people, who are working to make the technical audience to build the community with the technical audience, and to make the developers experience better. But like you said you know, we've had communities for... We've had technical communities for decades now. We've had community as far as religious communities, as far as local communities, as far as knitting and sewing and-

Mike: The beginning of time.

Mary: Exactly like, community building is not new. It is not new in any way whatsoever, and IRU to even developer relations isn't new. The term is new, we now have and official name for this industry, but I mean we've had open source community managers since open source was around in the 60s. This is nothing new and so there's so many people, who are sitting here going, oh, well but this is... It's a brand new industry and it's brand new thing. And the titles are new, the roles are relatively new, and it's definitely growing in popularity, but when you boil it down-

Mike: The formalization is new.

Mary: Yeah, yeah. And I mean when you boil it down, I mean developer relations is community building for technical audiences. So, it's frustrating to have so many people going, "Well, but it's this brand new thing and we need brand new ideas around how to control it, and how to manage it." When in reality, we don't need brand new ideas, we just need to standardize these new titles and honestly be looking back at how community managers in the past have generated success. How they've defined success, what the metrics are that they're looking for, because we can learn so, so much from people who have come from before us. And instead of just looking ahead and going, "Okay, new industry. We need new information around all of these things." Like, "No, no, it's actually learned from the history."

Mike: Right, like this is... I won't say this solved problem.

Mary: No.

Mike: Because we're never going to really solve the problem of community, but there's a lot of expertise floating around that is just not inside in tech.

Mary: Right, right.

Mike: I mean there is a ton of expertise inside of tech, but it seems to me that a lot of the gains to be made are not coming from inside of the technical world.

Mary: Right, and the biggest thing, the one thing that I will say that gives people the little bit of credibility when they say, "I's brand new, and it's super difficult." Is that when you throw technology in the mix, people don't know what to do with it, because community management like, "Oh, okay, cool." We've got ambassador programs and influencer programs and all of that, that always live under marketing. And you throw a technical concepts in the mix, and suddenly people are sitting there going, "Oh well, but I'm an engineer, I'm not going to report to marketing. What I do is not marketing." And there are elements of marketing to what they now do, but they don't want marketing metrics. They don't want marketing goals, they want developer relations goals. And so there is, I will say there is a lot of nuance around, What department do we report into? Do we go to marketing? Do we go to product? Do we go to engineering? Do we go to customer success?

Mary: And I don't think that there's necessarily a wrong answer to that unless you try, and tell me that a developer relations team will go into sales. And that is a hill I will die on every single day. We should not be in sales, it's one of the very few metrics we absolutely should not have.

Mike: Yeah.

Mary: But that being said, there's a lot that we can learn from other people, who have been doing this for longer. There's a lot that we can take and read, and then apply that to... Okay, add a technical element to that. And we don't just need community managers, and people who can improve the experience on the website. We need technical people right. We need developer advocates, because we need people that the community can relate to and that can speak to those direct problems.

Mike: Let's also get into the value of this community of like, why?... I know why my neighborhood community is valuable to me.

Mary: Right.

Mike: I know why having a social circle of friends is valuable to me, why should my company want a community?

Mary: Right. Well, if you think about it, there's a lot of similarities between why the neighborhood community is valuable and why the knitting community is valuable. And why the photography community is valuable, as well as why it's valuable to the company. Like neighborhoods, if you have a community in your neighborhood, you're less likely to leave. If you have a community of people that you are heavily involved in photography with, you're more likely to continue your photography skills. And same with companies, there's a lot of companies who, one of their main goals behind building a community is to reduce churn. And it's not necessarily a sales metric, but it's more really like lets keep the people that we currently have on the platform, because the more you can reduce churn, the more you can keep people from leaving, the easier it is to keep growing instead of just replacing the people that you had yesterday.

So that's a big one for companies is, we want to make sure that our customers, who are here stay. Part of that comes with creating a better experience for the customers that you have. Part of that is making sure that your communications are solid with the customers you're trying to gain, so they understand the value that they're going to be getting from your product. And the big part that developer relations plays in that is, getting that feedback from the community back to the company. And that feedback could be not necessarily even feedback on the product, but just knowledge and awareness of, "Here's the issues that people are facing. Here's the things that I'm hearing from the greater DevOps community. Here's the new hot software that people are using and the problem that, that's solving right? And so, communicating those generic things about back to the company allows the company to go, "Okay, cool we have a very broad overview of what the greater technical community is doing in DevOps, and we can now use that information to make our product better to better fit their needs."

And you'll see that in people beta testing software, or being an early user of a particular product. Or things like that, as well as just figuring out based on the feedback we get from customers, what are the topics that we should be talking about at conferences? What are the relevant podcasts that we can be putting out? All of those types of information that the companies can use to build a better product to reduce churn, but also to be more relevant to the community that they're serving.

And ideally, you'd be a thought leader in these communities. One example that I always use is HubSpot, back in the day when I was doing PR and technical writing and some marketing stuff on the side, HubSpot was one of the super early like CMS type platforms, customer management platforms, but also did contact marketing and things like that. And so you'd have the product that you could buy into, which I have used occasionally, but have never been like an official customer of. But they had this fantastic blog that ran all of these super relevant blog articles about content management and customer retention, and social media and all of these various things, 90% of which never actually mentioned the HubSpot product. But that was the go to place where I need to know about this new social media thing that popped up. I know HubSpot's going to have something about it, let me go over there.

So there's a lot of companies these days in tech that are starting to be like, Okay, we are the incident management company. We are publishing about you know, here's not only interesting information, but relevant information principles that you'd should be following in the space. Knowing that if they can become the HubSpot of internet management, or API, or whatever it is choose your topic, then as someone starts to learn more and more about that product and needs a company or a product to fill a particular need, your company's going to be the first one that they go too.

Mike: Yeah, you're absolutely right. What about the value of the second point communities to the members?

Mary: Sure.

Mike: We've talked a lot about the companies.

Mary: Yeah, yeah, yeah. So, there's a lot of value there, and I think a lot of times people miss the value that they get out of it as a community member, because they're so focused on, well is just DevRel are sales, or DevRel is marketing, and I don't want to be a part of communities that are just going to sell to me. Which, note to companies, don't sell to this communities.

But there's a huge amount of value back to the community members, you've got people that you get to know, who are facing the same problems as you are. You've got now a fairly direct line of feedback to the company to say, "Hey, this thing isn't working." Or, "I would love to see this have this additional feature." Or, "It would be so much better for me in my day-to-day work, if I could do this other things alongside your product." With a community that's built around a particular product, a community manager or a developer advocate, who is invested in that community is also usually excellent at connecting you to other people within those communities. My friend Amy Hermes, who has led communities for years, calls it, "Being a technical cruise director." And it's this idea of you know, we kind of stand at the back of the room metaphorically and make sure that people are having a good time right. Everyone has someone to talk to. Everyone's involved in a conversation they're interested in, and when you see someone new enter the room, you get to know them and understand their needs as well as their interest.

And then I can go, "Mike introduce you to Corrie, who might also be interested in the Platypus," or whatever your relevant interests are. So that you can go back and then have a good interesting insightful conversation with that person, get plugged into the community and the community manager steps back and goes, "Cool, they're now connected, and I'll follow up with Mike later next week to make sure that he still feels connected." And see how his conversation with Corrie was, and see if there's anyone else I can introduce him to." And continue that conversation right? So the community manager benefits because again, they're getting feedback from the community member. They're able to pass that onto their company, but the community member benefits, because they now are connected, and getting more connected within that community, and have people that they can rely on. Have people that they can talk to, have people that they can relate to, who are facing similar issues as they are.

Mike: We've touched on some of this a bit already, but what's hard to you about community? What are the unsolved challenges or as yet unsolved?

Mary: Right, right. So one of the biggest ones that you always hear about when this question is asked, is metrics. And it's more than just, "What metrics do I track right?" 'Cause there's hundreds of metrics that we could track if we really wanted to. And we can automate a lot of them these days, but more important it's which metrics do I track that will show I've been successful? And how do I know what success means? So it's not just, "you know, well I gained a 100 more followers on Twitter today." It's like, "Well, that's great, how many of them are Bot? How many of them are people that actually care about what you're doing? How many of they actually engaging with you? And is your team actually responsible for social media, or not?" So it's more than just metrics and whether, or not you've been successful, it's defining what that success means internally to your business. And that's a problem that's an issue with developer relations. That's and issue with community building. Like that's one of the few unsolved things that we're all still kind of trying to figure out, how do we do this?

Mike: Do you have any suggestions there, like what might make a good definition of success for this?

Mary: Absolutely. So, I can't give you a good definition of success that will fit for every business, 'cause it depends on the business goals.

Mike: Sure.

Mary: What I will say is making sure that your goals for your team always point back to the overarching company goals, is key. Because if a stakeholder, if a VP or a C-suite individual comes to me and says, "Hey, what does your team do this quarter?" They aren't going to care about, "Well you know, we published 12 blog posts, and we spoke at five conferences. And we attended 20 meet ups, and we met this many people." Like, "Okay fine, but tell me what that means? What does that relate to? How do I know that, that's success in your book rather than just your daily to do list?" And it's the difference between giving them that list of work output and saying, We got feedback from community members. We were able to help with brand awareness metrics. We were able to help drive the products forward by communicating this feedback to the product team, and engineering team."

And so figuring out maybe your company goal for that quarter is, getting more customers on board. And like I said earlier, DevRel should never have a sales metric. But you can increase the broader developer awareness of your product by speaking, by talking to folks on Twitter. By engaging in conversations on Reddit, or HackerNews, or wherever you tend to be. At Stack Overflow, whatever your platform is that you choose to be on, but you can help out in those various places. And if your goals always can match up to the overarching company goals, then there's far less of a risk of your team being dissolved, or someone saying, "I don't understand the value that you're providing, you shouldn't be here."

Mike: Yeah, I remember when O'Reilly stopped their community efforts.

Mary: Yeah.

Mike: I was like, man, that's a real shame, because I was able to start writing my book, because of one of those community people. So it all seems to me that, any definition of success that you have cannot be short-term, it has to be long-term.

Mary: Right, yeah. And that's one of the biggest, biggest, hardest issues with developer relations especially right now, particularly when it comes to start ups, because as we all know startups are usually funded by VCs, and VCs want to see their return on investment now.

Mike: Right.

Mary: They don't care about what's the ROI for a year from now, they care about, "Am I going to see my money? Am I going to get a good return on my money, now?" And so figuring out ways that you can show not only long-term value, but the short-term value is key. And so focusing on, "Great, we're increasing developer awareness." And those people might later become customers of ours is fantastic, but making sure that you keep track of all those points in between you know, "Hey, I met this person at a conference and had a great conversation with them, they passed the conversation off to their manager, who passed it off to their manager, who moved to a completely different company, who is now a customer of ours, because of that one conversation at a conference." It's convoluted, but being able to draw those lines for the longer term things. And then also be able to have return on the short-term things, whether they're quick wins, or demonstrating the value of the connections that you've made. I've started using... This could be a whole other podcast topic, but I've started using the term DevRel qualified leads.

Mike: Okay.

Mary: Because it's familiar to people in the business realm, because they're used to marketing qualified leads. And the easiest way to explain that term is, if you've ever attended a conference, and you've gotten your badge scanned, you are officially a marketing qualified lead at a particular company. And it's this idea of they met you at a particular location, or you signed up for a white paper for their website, or you signed up for a trial offer on their website, and you are now in their system. And they track your progress, they track what websites you visit. They track which links you click on, all of these things to see where you land on the sales spectrum whether they should you up to sales yet, or not. And I'm using this DevRel qualified leads now to illustrate you know, you just said you were able to start writing your book with O'Reilly because of the community team. So that is a success metric for the community team, right? They were introducing authors, introducing potential authors.

When I worked there it was a lot of talking to people, who might be good speakers at our conferences. As well as finding people who might be potential authors, as well as finding people who might be interested in talking about what we're doing at various other events around the world, but these DevRel qualified leads could be... I mean a developer when I'm out at a conference, and they might be a perfect fit for an open hire that we have, an open job record that we have. And I can pass them off to recruiting, and I'm not responsible for whether, or not they get the job, because I'm not the hiring manager. I'm not sitting in on all their conversations with the interviews, but I can make that connection. I can pass off that lead to recruiting and then recruiting is responsible for it from then on. Just like when marketing passes a lead to sales, its sales responsibility whether, or not that actually becomes a customer.

Mike: There's something interesting that you did, or so.

Mary: Mm-hmm (affirmative).

Mike: You went through Seth Godin's altMBA program

Mary: Yes, yes I did.

Mike: I think this is interesting because we were just talking about this, definitions of success, which are really business orientated. And now, here you have this altMBA certificate, what led to that?

Mary: So I started my business in November of 2017, and had a lot of imposter syndrome as a lot of people do.

Mike: Hey sure.

Mary: And my biggest form of imposter syndrome was suddenly, I'm going to have to be writing business proposals and selling myself up the chain of command at various companies, talking to VPs and C-suites and things like that. Not that I had never had conversations with them before, 'cause I had, but this idea of making myself come across as professional and businesslike on paper was something that I struggled with.

Mike: Yeah.

Mary: You know, put me to-

Mike: Someone to be taken seriously.

Mary: Exactly, exactly. Especially with people who didn't know me. Like put me in a room with folks, and we can talk for 20 minutes and more often than not, people will go, "Oh, okay, you know what you're talking about, and let's continue and see how you can help the company." But just pitching myself on paper was difficult. And so that was one of my primary reasons for getting involved in altMBA, and for those of you who aren't familiar it's this accelerated online MBA program and that call it altMBA, because it's an alternative MBA. And it's not accredited very intentionally, because what they aim to do is take the tangible, tactical skills that you need to level up yourself, your career without all of the sit down for two years in classroom, and pay 20 grands to get an official MBA that on paper is great, but you haven't really applied in your day-today life.

Mike: Yeah, as it turns out an MBA is financially just one of the worst decisions you could possibly make.

Mary: It really is, it really is, but knowledge that I got from this altMBA program was huge.

Mike: Right.

Mary: And the confidence boost. And the biggest thing was just, they incorporate a lot of peer learning. And so, you're learning from other people, who are in completely different industries, right? I had, on my cohort one week, was another girl, who owns her own business and does professional business coaching. And there was someone, who had just been promoted to the CEO of a chain of auto repair shops. There was someone else, who is a project manager for a non-profit like completely different skill sets, completely different roles across the board, but just learning from each other, and learning from the different perspectives was huge.

And the other reason why I was really invested in this was that, one of the patterns that I've noticed in my 10 plus years of doing developer relations and community building, is that we so often, especially in developer relations so many of us don't come from a business background. People are coming from a technical, or developer background, or a product background, which has some more business related skills. But we're coming into this with varied ideas of what it means to define success, and how we do that. And it's difficult to sit down with a stakeholder in the company, and say. "Here's how what my team did with success. We're the company, and here's how we're driving the company goals forward and things like that, if you've never had to do that. So we've got, especially in this past year, developers who are coming in brand new to these developer advocacy roles and are being asked, "Well, how do you find success?" And I'm generalizing here, so forgive me I'm trying not to make a stereotype, but more often and not I'm seeing folks sit down and go, "Well, we finished our jobs. We checked all the boxes for our okay hours for this quarter, or we were given these work outputs that we had to finish. We were given these tasks that we had to complete by the end of the quarter, and those are done. So it was a successful quarter."

And on an engineering team, that's a perfectly reasonable answer to give, and it's a true answer to give as far as were you successful or not this quarter? But when you come onto a team like developer relations, it's not just what are the boxes that you checked, it's also how did you influence the company? How did you drive the company goals forward? How did your work directly impact the company bottom line? And that's a difficult conversation to have, if you've never been put in that situation.

Mike: Oh yeah.

Mary: And so part of my secondary goal for altMBA was figuring out, how do I pinpoint almost what's the TLDR of an MBA, so that I can help other developer relations professionals have those conversations? And that's some of what I'm doing for clients as well as you know, one-on-one coaching with team members. One-on- one coaching with teams and helping them figure out, "Okay we did these things, how does that translate back to the company goals? How does that translate back to the team goals? How do I communicate that upward through the company? And in some cases, to the board to makes sure that our team still exists next quarter?"

Mike: That sounds like a fantastic idea.

Mary: Mm-hmm (affirmative). It's difficult, but it's rewarding.

Mike: Yes. Yeah, I'm sure. Well, this has been a wonderful conversation. Where can people find out more about you and your work?

Mary: Sure. So I'm fairly active on Twitter, you can find me @Mary_Grace on Twitter. My personal website is marygrace.community. You can also find out more about my business and the things that I partner with companies on at Persea-consulting.com. And Persea is spelt P-E-R-S-E-A.

Mike: And all those will also be in the show notes.

Mary: Perfect.

Mike: Well, thank you so much for coming on, this has been a pleasure.

Mary: Absolutely. Thanks so much for having me, it's always great to chat.

Mike: Thank you for listening to the Real World DevOps podcast. If you want to stay up to date on the latest episodes, you can find us at realworlddevops.com and on iTunes, Google player, or wherever it is you get your podcast. I'll see you in the next episode.