Mandi Walls: Welcome to Page it to the Limit, a podcast where we explore what it takes to run software in production successfully. We cover leading practices used in the software industry to improve the system and liability and the lives of the people supporting those systems. I’m your host, Mandi Walls, find me @lnxchk on Twitter. Hi folks, welcome back to Page it to the Limit, and with me today I have a familiar voice and a new voice. So welcome back to the podcast, Julie, and welcome for the first time Mary.
Mary Thengvall: My name is Mary Thengvall, I am the director of developer relations at Camunda, which is a source available, process automation, process orchestration tool. I have a pleasure of leading the team there and we do everything from community management to making sure that people are having a good experience with our community. The folks who are engaged continue to stay engaged to developer advocacy, where we’re really the bridge between the people using our product and the people building and promoting our product. And then our developer experience team, which is responsible for making sure that they remove any points of friction as people are getting up and running with Camunda for the first time.
Mandi Walls: Awesome. Julie, for folks who haven’t been with us long enough to remember your past episodes.
Julie Gunderson: Well, thanks Mandi, it’s really nice to be back. Yes, I did get to work with you at PagerDuty. Since then, I have now joined Amazon, so I’m with AWS as a senior developer advocate, which is amazing. I specifically focus on building communities as well. So I think Mary and I and you actually have a lot in common with just focusing on developers and what they need.
Mandi Walls: Let’s start there. What are developers looking for? Why is it a different practice to talk to developers?
Mary Thengvall: I can kick us off there. I think one of the things that’s a little bit different is that, typically, in communities that you’re building, the people who are working on bringing those people together share those similar passions. So if you’re creating a photography community, you’re likely a photographer as well. And when it comes to developer relations and developer communities, often, developers aren’t the ones creating those communities, they’re the ones that are creating the products.
And so it’s a little bit different with either finding people who have been developers in the past who are also interested in more of the people side or education side, depending on the angle you’re going for. Or finding people like myself who have not been a developer in past careers, but have the tech savviness to be able to understand how the product works and where the holes might be and what gaps we can have and what we can do to fill some of those gaps.
Julie Gunderson: I agree with all of that. When we talk about developer communities, we’re not talking about communities that love to be marketed to. Because developers, when they’re out there looking for help or when they’re forming relationships or building these communities, they’re really looking for things that are impactful to their day-to-day life. And one of the things that I love about developer communities, is they’re oftentimes self-driven by very passionate people. We see that a lot with different communities involved with AWS, for example. People are very excited about a product and they gather together to talk about how to use tools, how to learn from each other.
And I think when we talk about developer communities or communities that focus on teaching each other, and as a matter of fact, Mary, that’s how I met you, was through community. Going back to when I started in technology, Mary, I met you, I believe we were at SCALE?
Mary Thengvall: Yes.
Julie Gunderson: It was SCALE that I met you with a little tiara and a puppy of yours. And the Chef community was so welcoming that I felt like I could do anything. And then they taught me a lot and I would say ultimately helped shape my career, but I don’t know. What do you think, Mary?
Mary Thengvall: Absolutely. And I think that’s the core thing to community from my side, it’s not just people who are using a product, it’s people who care about the others who are using that product, who want to give back, who want to make other people around them more successful. And then are either creating content or making code contributions or mentoring or doing something within that group of people to make sure that the people around them are having success as well. So it’s that collaboration and contribution side that really turns it from just a group of people who have things in common to a true community.
Mandi Walls: Do you find that it’s different for communities that organize around open source projects versus closed source projects? Or are folks enthusiastic about all that stuff?
Mary Thengvall: I think it can be different, I don’t think it has to be. Open source projects tend to draw in more people who are willing and open to collaborating because that’s what they do. If you’re involved in an open source project, it’s the carry water, chop wood, that’s what you do. You collaborate, you contribute, you’re in this together. And so I think some of that community spirit is intrinsically in that product as a result.
But I think for proprietary products, it can happen as well. It might take a little bit more effort and a little bit more nurturing to have some of those people who are using your software, who are really enthusiastic about it, to encourage them to give back, to encourage them to contribute content, to encourage them to take AVA on other community members and mentor them. So it might take a little more encouragement and planning from your side, but I don’t think there’s any reason why that same community can’t be formed.
Julie Gunderson: Well, and I think one of the keys there too, when you’re looking at different types of communities, whether it’s an open source community or not, taking that feedback from your community and seeking that feedback from your community can make a big difference. Just because, PagerDuty, there’s really no open source component to it.
But when we were at DevOpsDays conferences, when we were at any conference as DevRel, we weren’t there looking for people to market to or to sell to. As a matter of fact, we had a little, we don’t send salespeople to DevOpsDays booths. We were looking to get feedback because we talked about, us being advocates, advocating both to our community, but also advocating and bringing back for our community back into the organization. And that’s something that I think is incredibly important to developers, is that being heard as you were bringing up, Mary.
Mandi Walls: That two way relationship becomes super important. You’re out there as someone talking face to face with the users, which doesn’t scale to send your engineering team absolutely everywhere. So it’s nice to have a proxy that can bring stuff back for folks so they can learn what’s going on with everyone else.
Mary Thengvall: Absolutely. And I think the companies that I’ve seen be most successful with their communities are the ones who repeatedly prove to their community members that they want to hear that feedback. And it’s not only, yes, I’ve written that down, it’s now at our roadmap. It’s also, when something starts happening around that issue, around that ticket, follow back up with that community member and say, by the way, here’s the progress on it, do you have any other thoughts? Are there any other things that have come up as a result of this in the meantime?
And that follow up is a huge piece of that because you might hear the feedback, be willing to implement the feedback, but if you don’t ever close that loop, then there’s nothing to show that community member that it’s their feedback that made a difference for this particular feature or this particular bug.
Julie Gunderson: 100%. And having that mechanism in place is amazing. And even if you don’t, don’t ignore your community, they’re going to reach out. If it’s a bug and they’ve submitted something on GitHub, talk to them, at least acknowledge that you’ve heard them. And even if it’s something that you are not going to … maybe there’s somebody requesting a new feature and maybe it’s not on the roadmap, it’s okay to tell your community that, to be open with your community instead of trying to avoid difficult questions.
Mary Thengvall: And I think there’s a lot of people who are scared of that, like, well, if someone brings something to us and we have to tell them it’s not on the roadmap and it’s not something that we’re going to be considering, they’re going to run in the opposite directions.
No, people appreciate that honesty and that authenticity, and I think that authenticity is what keeps a lot of people coming back. If you can openly say, it’s a great idea, but we’re not pursuing that because it’s not our bread and butter, or it’s not our strong suit, or whatever the reasoning is, then people can understand why you are heading in the direction that you’re heading, and it helps them give you more valuable feedback in the future as well.
Mandi Walls: Definitely. There’s no value to telling someone that, we’ll think about it when you’re not actually going to think about it, where you basically turned it down the first time it was requested seven years ago.
And sometimes as a community member of other pieces, other software products, I’ll go on in the support channel looking for the same question, find all these people asking the same question, and there’s never a definitive answer and the threads go back years. And then finally, there’s a passive aggressive blog post that, this violates our very ethos of our entire belief system for our product. And then it took a hundred posts in their support channels to just be able to say, no, this isn’t what we’re going to do with the product and it drives me bananas.
Julie Gunderson: You’re hitting on something though with support channels, and that’s what I want to say to developers who are out there listening to this right now. That is a huge benefit of being involved in a community. Sometimes it can be difficult to get direct support from an organization. Maybe if you are just learning on your own, it might not be an enterprise product. But there’s this community out there that oftentimes is willing to help you and can help you find solutions to your problems or teach you.
Reach out to your community as well, they’re to be leveraged by you, but it means that you have to find them. And sometimes that can be hard, but there can be a lot of great places just to find community. And I would say some of those would even be, in person, we’ve got meetups and conferences like DevOpsDays, which honestly, the DevOpsDays community is one of the most amazing because they’re so helpful and they just want to teach. But Mary, what do you think? Where are other good places?
Mary Thengvall: I agree. I think it might be if it’s an open source project or source available project, GitHub Issues is always a place that you can go. And if you’re not sure about how to file an issue or whether or not people are actually checking those issues, some projects will actually have templates for how to create an issue. Or you can go back and see how other people have done it in the past and whether or not the team is responsive.
Julie, to your point, people are always wanting to hear feedback or at least usually wanting to hear feedback, hopefully wanting to hear feedback. I know my team very much is, and so if you’re not easily finding a way to contribute that feedback, it could be, put out a public tweet and name the company and say, I’ve got some feedback about your product, who’s the right person for you to pass this along to? And whoever’s responsible for their social media channels will then point you in the right direction.
But I think there’s always opportunities to give feedback, whether or not the company will accept it as their choice. But in my opinion, it’s one of the most valuable points of contact that we have with our community members. You’re the ones who are using our software, and if we’re not listening to you, then we’re not going to be creating the product that you want and need.
Julie Gunderson: 100%. And I’m going to say this with a caveat too, if you’re going to take to Twitter or anything, remember that that is still tied to you as a person. So think through how you want to publicly be perceived when you’re talking to these companies.
I’m not going to lie, I know I have yelled at United on Twitter before. And at this point in my life, I never plan on working for United so I’m not worried about it too much now, but what if someday I wanted to? Can that come back to me or will other people look at that? So I think that it’s important to think about how you come across on social media, that’s not to say not to be authentic or be yourself, it’s just the way I look at it and take that or not.
Mary Thengvall: Well, and I think it’s not only how you’re perceived, but also the fact that there’s real people behind those accounts. So if you’re posting in a forum about a crappy experience you had, that’s fair, that’s your experience. But I think someone, and I’m trying to remember who said this and I’m not going to be able to come up with it, but the idea of not putting blame on a person or an individual, but calling out what the problem is that you’re having. And so making sure that you’re focused on, this wasn’t a great experience, is there something that I can do better? Is there something that you can do better? Rather than, your product is crappy and everyone who wrote it is crappy and this whole thing is crappy.
Again, how do you want to be represented? But then also remembering that there’s people behind those products as well who genuinely are doing what they can to make it a better experience for you and would benefit from your experience and your feedback. But it always goes over better if you’re respectful with that feedback as well.
Mandi Walls: No one opened up their ID this morning with the express purpose of putting something in that’s going to make you mad.
Mary Thengvall: Exactly.
Mandi Walls: It’s just not how development works, it’s just not where we’re headed. We got other things to do than think about your grievance. So we’ve used the word community a whole lot, when you think of your community, who is that? Is it everybody? Is it also the folks who work for your companies? Who actually makes up the community for a particular product space?
Mary Thengvall: I will jump on this right away, only because I’ve literally been having this conversation for the last week and a half internally, which I love. I will have an answer for you and I will also have more questions. So I’ve always viewed the community as a very holistic, inclusive of everybody concept. It’s not only the people who are using our product, it’s the people who are on our community platforms, it’s our partners, it’s our industry analysts, it’s people that we’re interacting with, who are speaking at our conferences. It’s also the people who are creating the product internally, it’s a very large group of people. Essentially, anyone who is interested in or has been interested in or is currently using our product, which is huge.
But when I’m looking at that for the sake of my team and if we’re wanting to grow our community or better engage our community and who are we looking at that level, then I’m looking at people who are engaging on Camunda related community platforms. And those could be ones that we own and operate ourselves. It could also be things like Stack Overflow or Reddit. It could also be people who speak at conferences about Camunda.
And one of the interesting questions that I was talking about with my CEO last week, he was asking me if I felt a need to check in with those community members to see if they self-identify as Camunda community members. A great example, we have a industry analyst who attends a lot of our conferences, speaks at some of our conferences, is very involved in the process automation, process orchestration space. I would very much consider her a part of our community, she blogs about our software, she’s present in our events, but she’s also not someone who’s going to hop on the forums and answer questions. And so our CEO’s point was, well, would she consider herself to be a part of our community?
And I was having that discussion then today with a team member of mine who said, well, does it make a difference if she self identifies as part of our community or not? Or is it more about who we consider to be part of our community and whether or not we think that she’s a part of our community and how does that change how we interact with her? So I’d love to hear both of your responses to that actually, if I’m allowed to ask questions now?
Julie Gunderson: That is a bold question. First of all, Mary, everything you said, I agree with 100%. And when you look at the definition of community, it is a feeling of fellowship with others as a result of sharing common attitudes, interests, and goals. That’s one of the definitions, the other one is people living in the same space or having a characteristic in common.
Now, when we look at having goals and interests and attitudes that are shared, going back to Chef, I never used Chef, not once at all yet I feel like I was a part of the Chef community. And part of that just came from the fact that I was an advocate for Chef. Part of that is because I think that when you’re purchasing a product, a tool, you’re also looking at the community, and how did they behave? What is their support level? That’s something that I always thought about and I loved the Chef community compared to some others that I had run into at the time. Using the product is also a little loosey goosey of a definition because I never used Chef, but I would’ve said that they all incorporated me into their community and I felt very welcomed.
There are different types of community, as Mary was saying, is it a community that’s on your platform or is it a community that’s on Stack Overflow, for example? What I think is important, is to not lose the fact that you shouldn’t always expect your communities to come to you, you should go to where your communities are. And I think that’s a key element for organizations to remember and I know that we’ve all done that. We’ve known each other for quite a bit of time, and I think we’ve all been involved in initiatives where we’ve been where our community members are.
But it’s important to just not discount somebody as a member of the community or be elitist about your community, and that’s super important to me. I remember once going to a conference and not knowing how to do something with a specific product, but they were giving away a really cool shirt and they told me I couldn’t have the shirt because they didn’t know how to do this specific thing, it was a coding challenge. And I’ll tell you what, I had nothing to do with that community from that time forward. So think about how are you accepting people in that maybe you wouldn’t traditionally think are part of your community? Mandi, what do you think?
Mandi Walls: It’s a tough question. Because I think about when I first started Linux, so this is going back to the dark ages like IRC. And my first foray into asking questions about things, I was playing with some Debian stuff and also some Red Hat stuff. And the Debian community was a pack of buttholes, they were jerks and really obnoxious people. And I was like, you know what? I’m done here, I have enough ranty people in my real life, I don’t need your hostility online and I got lots of help other places.
That drove a bunch of decisions that then drove the first part of my career because I ended up being a Linux systems administrator and specializing in Red Hat based systems. So that’s where I headed because two weeks during my undergrad, a bunch of people were really obnoxious on IRC. So I think I turned out okay, it’s fine. But at the same time, like you said, the Chef community, they were very conscientious about, we are your buddies, we are all in this together, we’re all here to learn this, none of us were born knowing any of this, we made up half of this stuff last week.
Julie Gunderson: And like she’s saying, they always acted like that, Mary, you always acted like that. And I think that attitude, Mandi, of we don’t expect you to know this anyhow because we just made it up, is key. Can we hit on something though before this podcast ends?
I think that it’s important to talk to folks about, how do you welcome people into your community? Not maybe us that are representative of our organizations, but as good stewards of our community, how do we give people the proverbial shirt to make sure that they feel welcomed? So you all welcomed me in, what’s your advice?
Mandi Walls: Well, for a while, Chef was more a lifestyle brand than an actual software company so everybody got shirts. But that’s intentional, we don’t know the trajectory of your career. If you get interested in this stuff and become a decision maker somewhere, you’re investing for the future with the way you treat your community. And making sure everyone feels welcome is definitely part of that.
Julie Gunderson: I think one of the things that had a big impact on me was Jason Yee. And granted, I did work for him for a little while when we worked at the same company, but when I met him at Velocity Conference, I think it was like 2015-
Mandi Walls: I miss Velocity, my goodness.
Mary Thengvall: Same.
Julie Gunderson: … Me Too. Jason met me and I didn’t know anybody, and I don’t even honestly know how we met. I think I just randomly said hi to him because that’s who Jason is and he wandered me around and introduced me to people. And I think that’s something, especially when folks are new, is to bring them in and help them feel welcomed, provided that’s what they want. Some people would like to just be left alone, we should not force them into an open space or to talking or anything. But maybe looking for those people that are a little lost looking and helping them make connections, Mary, what do you think?
Mary Thengvall: Absolutely. That’s actually one of my favorite things to do at conferences, is like, cool, someone’s standing at the back of the room by themselves, someone’s standing off to the side of the Expo hall by themselves, pull them into the conversations that you’re having. Someone, ages ago, came up with this Pac-Man analogy for being at conferences where there’s always a little bit of space in the circle, so it’s not a fully closed circle, it’s got an open mouth like a Pac-Man.
And so it’s this idea of, great, there’s always room for someone else to join. You’re always bringing other people into the circle, you’re always welcoming other people into the conversation. And I think that was a lot of what we did at Chef. I think that was a lot of what I’ve tried to do in any company that I’m in. I don’t care if you’ve been a developer before. I don’t care if you can code with our specific software and get it up and running in five seconds flat, doesn’t matter. If you’re interested in what we’re doing, I will tell you what we’re doing and see if there’s a way that you can get involved.
And I think the tech industry in general has opened up to that idea more and more over the last few years with low code, with easier coding platforms, a lot more of the plug and play type of things. And it’s been interesting to talk to people about those because in some cases, sure, it’s to allow for people who don’t have as much coding experience, but it’s also for people who just don’t want to have to sit down and code everything out anymore. It’s easier, let’s do it the easier way, let’s not continue to bang our heads against the wall and frustration of, why isn’t this piece of code working? And so I think that inclusivity of, we’re all tired and we don’t want to have to work as hard anymore, has also opened us up to, more people can do the things now, which is great, I love it.
Mandi Walls: All right. Well, any myths you would like to bust about communities and community building? Things that people often get wrong that you want to set straight?
Julie Gunderson: I think that the myth I would like to bust is, some people get stuck on titles or they think that because they have a certain title means that maybe they aren’t welcome in a group or shouldn’t be talking to a certain community group. And I say, it doesn’t matter what your title is, it doesn’t matter how long you’ve been doing the job, it doesn’t matter if you’re doing the job. As going back to what Mary said, if you’re interested in learning more or practicing or playing or anything, just introduce yourself to the community. It sounds scary, but it isn’t.
Mary Thengvall: I could not agree more, I think that’s fantastic. And the flip side of that also is, making sure that we’re welcoming people into our communities, making sure that people feel welcomed. And I think there’s a lot of what we’ve built up over the years in developer relations and community that’s, we collaborate with a lot of people, we do a lot of things, but we aren’t marketing, we aren’t sales, we aren’t these other departments. And I think there’s some validity to that, we have our own value, we aren’t those teams. But I think at the end of the day, we really are people who have the opportunity to connect all of those teams.
If someone starts out with, I have feedback for the product team, and then it turns into, actually I think your product could be really useful for us, great, make that introduction to sales. Take the feedback to marketing when someone says, this is really interesting and I really like the way this is represented. We’re able to be that bridge to so many other departments and be so helpful and really interface with the whole company on behalf of people who are using our products. And I think that puts us in a unique position and it gives us a lot of power.
Mandi Walls: Awesome. Well, this has been great, it’s been super good to catch back up with you both and have this nice chat. Because we mentioned Velocity earlier, that was how Mary and I first met a million years ago and how we even got hooked up.
Mary Thengvall: Exactly. Lots of coffees in New York.
Mandi Walls: Definitely, yes. 100%, so many, my God. All right. Well, this has been fantastic, thank you both. Where can we find you online? Where are you living right now, are your own Twitter?
Julie Gunderson: I live @Julie_Gund on Twitter.
Mary Thengvall: I’m @Mary_Grace on Twitter, that’s by far the best way to reach me.
Mandi Walls: Excellent. Ladies, thank you so much for joining us. Everyone out there, thank you for listening this week. We will wish you an uneventful day.
That does it for another installment of Page it to the Limit. We’d like to thank our sponsor, PagerDuty for making this podcast possible. Remember to subscribe to this podcast if you’d like what you’ve heard. You can find our show notes @pageittothelimit.com, and you can reach us on Twitter at Pageit2thelimit. Thank you so much for joining us, and remember an eventful days are beautiful days.
Mary Thengvall is a connector of people at heart, 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. Mary is the Director of Developer Relations at Camunda, a developer-friendly source-available process orchestration platform. She’s the author of the book on Developer Relations: The Business Value of Developer Relations.
Julie is a relationship driven Sr. Reliability Advocate who is passionate about helping individuals, teams, and organizations understand how to leverage best practices, and develop amazing cultures. Julie is an international speaker on topics related to reliability, organizational and team culture, chaos engineering, and incident management. Additionally, Julie is the founder of DevOpsDays Boise, which focuses on building a stronger technical community in Idaho.Julie is a relationship driven Sr. Reliability Advocate who is passionate about helping individuals, teams, and organizations understand how to leverage best practices, and develop amazing cultures. Julie is an international speaker on topics related to reliability, organizational and team culture, chaos engineering, and incident management. Additionally, Julie is the founder of DevOpsDays Boise, which focuses on building a stronger technical community in Idaho.
Mandi Walls is a DevOps Advocate at PagerDuty. For PagerDuty, she helps organizations along their IT Modernization journey. Prior to PagerDuty, she worked at Chef Software and AOL. She is an international speaker on DevOps topics and the author of the whitepaper “Building A DevOps Culture”, published by O’Reilly.