Communities Are Made Of People with Jono Bacon

Jono: [00:00:00] What’s the best way of reducing risk? Doing nothing.

Matty: It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matt Stratton. The worst thing about the Arrested DevOps podcast is when it ends. You’re left wondering what to do next. What are you going to listen to on your commute home? How do you occupy your time when walking the dog? What are you going to listen to during the quarterly all-hands meeting? But fear not, dear listener, there is a solution. You need to subscribe to Software Defined Talk right now. It’s a weekly podcast that recaps all the news in cloud computing, DevOps, and enterprise software. The hosts, Cote, Matt Ray, and Brandon Wichard, will keep you up to date on all things cloud while offering tips on how to optimize your Costco haul, and how to PowerPoint. It’s a fun, free-flowing conversation that will keep you entertained and informed. What are you waiting for? Subscribe to the podcast today by visiting softwaredefinedtalk.com or by searching for Software Defined Talk in your favorite podcast app.

[00:01:14] My guest today is Jono Bacon, the author of a new book, People Powered. Jono is a well-known consultant, author, advisor, and speaker on the topics of community and collaboration. And an all-around rad human being. And as I also just discovered, a fan of heavy metal. So that’s awesome too. So, Jono, can you tell our listeners just a little bit about yourself, kind of to set the stage? You don’t have to give your whole life story, maybe like a quarter of it.

Jono: Well, Matt, first of all, thank you for having me on. I really appreciate it. Yeah, I mean, in a nutshell, I’m really passionate about communities. I’m pretty I’m pretty firmly of the view that when we get people together into healthy communities, I think it improves the human condition. I think we can create things that we’ve never been able to create before. I think we can have more of an impact than we’ve ever had before. The tricky thing is that figuring out the recipe for how you build out a community is a complicated mix. It involves technology, workflow, psychology, all of these different pieces, incentives. So I’ve spent my career really focused on that. I used to— I started out in the open source world. I got into Linux in 1998, and that’s where I discovered communities. Worked at Canonical, GitHub, XPRIZE, and these days I’m a consultant. I work with a pretty broad variety of companies around how they build communities both inside of a company as well as outside. A pretty reasonable chunk of those tend to be tech firms because that’s my heritage, and especially in open source. So yeah, I just think there’s enormous amounts of potential. And I think this is going to be the future of how companies tend to engage with their customers and their users. I think people don’t want the newsletter anymore. I think people don’t want to be spoken to. I think they want to have a relationship with the people they follow, with the companies they follow, and the projects that they follow.

Matty: [00:03:03] I’ve been listening to the audiobook version of People Powered. I’m not all the way through it, but I have been listening to it. I love audiobooks. And I’ve been very much looking forward to when this one was coming out. I was watching my Audible preorder queue with, you know, a lot of anticipation. Wonderful. Yeah. Thank you. So, but you begin the book by telling the story of an Ubuntu contributor in Africa and how that was kind of a catalyst for you or an inspiration around your ideas of what a tech community really could be. Can you share with us a little bit of that story? I mean, we don’t want to give away the whole book. Everybody needs to go buy the book, but, you know, maybe to kind of get things started.

Jono: Yeah, so this was, um, a pretty formative moment in my, I would say, career, but really in my life, to be honest with you. Um, I’d been working at Canonical, which is the company that primarily funds Ubuntu, um, for about, I think about 6 months. And I got this email from this kid who was based, I forget where it was, but it was based somewhere in, in kind of rural Africa. Um, and he basically said that he, he’d spend his week doing chores around his village He didn’t have a computer at home. And then he basically earned money from those chores. And then what he’d do is he’d walk around, I think it was about 2 hours to his local town, where he’d then use that money to buy about an hour’s worth of internet access at a cafe, an internet cafe, and then he’d contribute to Ubuntu. And then he’d walk 2 hours back. And I was blown away for a couple of reasons. One is that that’s a remarkable amount of commitment. You wouldn’t get me walking 2 hours anywhere to do something. But it also demonstrated to me just what’s possible when someone feels part of a bigger mission and a bigger machine. And clearly, he felt like— I mean, his email was just gushing with excitement about Ubuntu. And obviously Ubuntu’s got a very special meaning in Africa because Ubuntu is an ancient African word meaning humanity towards others. But, you know, he was a kid in rural Africa, but when he was part of the project and part of the community, he was playing one piece in a much bigger, in a much bigger mission and ethos. I think that’s what motivated him to do that. We see those examples all over the world. We’ve seen it in Firefox, like, for example, with Firefox people in that community doing enormous amounts of advocacy work, organizing crop circles back in the day. We see it in gaming communities, across open source and DevOps and beyond. It’s pretty impressive.

Matty: [00:05:30] That’s the thing when we think about community. That’s a big word. It can be a big word and it can mean a lot of different things to lots of different people. And I wanted to start by thinking about the different kinds of communities because we all, besides just, you know, the community that we engage with on a personal level, you know, we have our local community, we have organizational communities and things. But in the context of what we’re talking about, uh, there’s kind of a couple of the ones that come to mind and I think we can kind of dig into it, but I want to see about how you slice and dice this. So there’s communities of users. Right? People who might use your product or your project, you know, you’re— then they can be communities unto themselves.

Jono: Yeah.

Matty: I think about an employee community, right? Like, and, you know, at PagerDuty where I work, there’s a big— I don’t want to say focus, but we take a lot of pride in our community of being what we call Deutonians, people who work at PagerDuty, right? Like, that’s a community of coworkers all over the world, right? And we talked about contributors to a project. That’s a different kind of community maybe than users. Maybe there’s— I think there’s a lot of overlap with these.

Jono: [00:06:37] Right.

Matty: Yeah. And then, and those kind of— those were just some that I started with, but I’m sure there’s a lot more of different lenses by which you might see a community. Yeah. What are some of the interesting ones you’ve seen or some of the different ways you might kind of categorize types of community?

Jono: Yeah, I mean, I think your intuition, Matt, on this is spot on. Like there’s— Community, like you said, the term community is a very broad definition. And I think people have different views of what it is. I mean, for example, I went and did an interview on The Triangulation Show, which is a show that Leo Laporte does on Twitch. And one of the comments that he made was, well, communities are basically like social media is a community, right? And I don’t really slice and dice it that way. As an example, I see a community as a group of people who are interconnected around a mission or an ethos. And social media can play one role of that, but it’s not that in itself, in my mind, very specifically. So to me, I basically break communities down into 3 models. And this, I kind of walk through this in People Powered. One is, is what I refer to as consumers. So these are people who get together because they share a common interest, such as they’re Star Trek fans, or they’re users of, you know, Kubernetes, or whatever it might be. And they come together, they don’t really have that much of an influence on the core thing that brings them together. They’re just enthusiastic users, and they may provide support and help and whatever else. The second type is what I refer to as champions. These are people who kind of go the extra mile. They generate content, they produce videos, they create blog posts, they do social media, they organize events, they do all of these different pieces. This material is typically added to kind of like a stockpile. And people— it’s like an additive stockpile. So the more content people produce, the more valuable the community tends to become. And then And then the third type is what I refer to as the collaborator community, which is where people come together to build something. And this kind of subdivides into 2 areas. I refer to one as inner collaborators, which is people who work on exactly the same project. So a good example of that is open source, right? If anyone who’s run an open source project, particularly where there’s a company attached to it, knows that you will be more successful if the community feel part of the same team. Because they see themselves as part of the same team. So therefore, if they, they get the sense that they’re kind of unpaid labor, then they’re going to get pretty frustrated. So those are complicated communities to build, because you need to make sure that there’s equality of opportunity and collaboration there. But the other type of collaborative community is what I refer to as outer, which is where people come together to build things that sit on top of your community platform. So that could be, for example, people building plugins for WordPress, or it could be building apps for a particular app store, it could be people building npm modules. And there’s a very different relationship in how you build those kinds of communities. But what slices through all of that are also these different types of persona. So you mentioned, for example, users, employees, contributors, these all different personas have very different needs and cultural norms. So for example, one company that I’m working with right now, we’re building a community that’s focused on kind of business decision makers. And those people are never going to go to a forum. They’re never going to go and hang out online. They’re generally pretty busy people, and they primarily communicate via phone and email. So email is going to be a primary way to bring those folks in. But then we’re also in the same company building out a community of kind of technical implementers, people who are deploying the software that they’ve bought. And those are going to be more from an engineering background, and those folks are very used to going into online settings such as forums or Slack channels or Stack Exchange and places like that. I think it’s important to determine the type of community that you’re going to build and then you define those personas. That will help to shine a light on what strategy you need to put together.

Matty: [00:10:36] You talked about the different personas have different ways that they’ll consume or interact. I feel like I’ve had this conversation a lot over the last decade in various ways in different roles I’ve had about finding people, meeting people where they are. And I see this a lot just when I think about it, when I think even about communication inside an organization. So we always would talk about like, how do we let people know about if we’re going to have a new release or have some new program or something like that happening in our company. And it was kind of like, well, we have this email announcement we sent. I was like, but not everybody consumes email. Sometimes people want RSS feeds, sometimes people want chat channels. And, and I feel like that part of the challenge is the more channels you add of communication or interaction, the overhead of managing and using them, right, increases exponentially. So I think that’s why people tend to wanna say like, well, I have this one way I tell people in my community this information. But I always think about, this is kind of a silly example, but I worked for this company where, and we were very not remote, like this story wouldn’t work in a remote story. And a remote company, but one of the ways that communicate— that information was disseminated to employees was signs in the restroom.

Jono: [00:11:56] Oh yeah.

Matty: And so, and what was interesting is the floor that I worked in, we had a shared restroom with another company that was like outside of our, you know, like of our part of the floor. So we were— so our company couldn’t post anything in there. And there were many times I would be literally out of— I would be out of the loop on what was happening in the company because I didn’t use— the communication channel was one, one method, which was signs in a restroom, and it didn’t apply to all the employees. And I don’t think it occurred to anybody that there had to be, you know, so sometimes it’s about your preference and sometimes it’s about— and especially when we think about remote employees or, and again, I know I’m talking like of the community inside of an organization, but it still goes to different people have different ways of being able to consume it. How do we, what are some of the ways to kind of, and then how do you bring all that stuff together too? Because this is, it’s one way to say like, send information through one channel or send it through multiple channels. Okay, fine. So I need to send an email, I need to post in Slack, I need to put up a README or whatever, but we’re talking, when we’re talking about communities and collaboration, it’s not this like half duplex one-way communication. So if we wanna say, if we kind of buy into this idea that we have to reach people where they are according to their preference, what are some of the ways that we can kind of get some eventual consistency around that, right? Like maybe you have, you gave an example of having different communities with different personas, but what about when we kind of slice those levels where there’s different personas and they’re not all necessarily working in the same ideas? I don’t know if there’s a good way to solve for this. I’m curious to hear what you have to say.

Jono: [00:13:41] It’s a great question, Matt. I mean, and it’s tricky. One of the trickiest elements of building communities is you have, in many cases, a really diverse range of constituents, right? Your members that you want to attract. And you basically have to make a series of hard decisions around what are the platforms and the methods that we’re going to use to bring those people together, right? So there’s a couple of things I think that are relevant to this question. One is, is part of the value of defining those personas is that it gives you a sense of— you can crisply articulate what are the kind of places these people are going to hang out, and also, where do they consume information? What motivates them? What rewards do they like? What are their fears? What are their motivators? And when you can define that crisply, and you can say, okay, these are the target personas that I’ve got, then it makes these other decisions much easier. So for example, one of the things I walk through in People Powered is different types of personas, such as, you know, in the, you know, kind of in the, in like the DevOps world, for example, you would have, you know, for example, people consuming technology, people doing software engineering, people working on operations, you would have people producing documentation, people organizing events, people doing, you know, providing translations and things such as that. You can’t possibly attract all of these people at the same time, you have to make some difficult decisions with the community, who are the most critical people that we want to focus on. And then the way I was recommended is the first thing to decide is what are our communication channels going to be. And this is in itself a complicated subject, but I’ll distill it in a few sentences, like I’ll try to at least. One is, I basically believe that there’s, there’s 2 types of communication out there. I refer to it as structured and unstructured communication. So structured communication is where you have a very specific discussion about a very specific outcome. So for example, that could be a bug report or an issue in GitHub, or GitLab, right? When you go into an issue in GitHub or GitLab, there’s no, hey, how was your weekend? It’s, how do we fix this specific thing? Or how do we implement this specific feature? The same kind of thing happens in Stack Exchange, Stack Overflow. Someone asks a question, and then you get a very specific answer. So you don’t get a lot of human— you don’t tend to get a lot of kind of social kind of collaboration or social exchange in these kinds of mediums. They’re very functional in nature, but they’re very high value in nature. So the first thing is to decide what are the things that are relevant to your community there. So for example, for a typical open source project, you would have— I would recommend, Issues go into your issue tracker, such as GitHub, or Jira, or GitLab. And then you may have, for example, a specific place where people can ask questions. Now, unstructured communication is everything else. It’s where people talk about the overall project, talk about the work that they’re doing, have broader conversations. This is where we get into areas such as Discourse and forums, or we get into Slack and Mattermost, or IRC, or Rocket Chat, or Discord, or all these different different platforms. You can basically divide those kinds of unstructured platforms into both short-term and long-term memory. And this is a term that I’ve stolen from Jeff Atwood, who created Discourse and Stack Exchange. And the challenge with platforms like Slack and Mattermost is that it’s almost impossible to go and find previous discussions, right? Anyone who claims that they can do this is lying to you. They claim that they can try and— Slack claim, for example, that their search is really good. It’s better But it’s still very difficult to use in that regard. So the challenge with that is that while real-time chat is very high, it’s very gratifying because you can go and have a conversation right now with somebody. The problem is that it’s, A, transient, it depends on who’s online at that time, and B, it’s very costly because if I, for example, go into a channel and say, hey, Matt, I want to ask you a question about this, you provide the answer, it’s almost on it’s almost impossible for somebody else to go and find that previous discussion if somebody’s got the same question that I’ve got, and to be able to read your response. So that means that Matt then needs to answer the question a second time. And that can be a real problem. So the benefit of structured communication, such as— sorry, unstructured communication channels with long-term memory, such as Discourse and forums, is that it’s much easier to reuse previous discussions and collaboration. You can go and find it much more easily in the same way that you can go into GitHub and you can go and find previous issues. You need that, I think, for your structured communication, for your unstructured communication.

Matty: [00:18:27] And I think even, even more like it was interesting, like you said, you’re having this, you know, I think we’ve all had that experience of answering the same question over and over again in something like Slack or Mattermost because people don’t, you know, it’s so hard to find it. But even if it was, even if they, the answer to the question is not all of the value. Right? So, like, we could have had this long conversation with multiple people with lots of different input on how this— how we kind of arrived at that. And that particular encapsulation of the, quote, answer to that question has intrinsic value by itself. And the next time you ask that, so, like, it could be that you ask me a question and I answer it, and then 5 or 6 different people will chime in on it, and there’s a whole conversation and there’s a lot of value. 6 months later, somebody else asked me the question, I answer it, And they just got the answer. So I’ve been seeing that a lot in a lot of Slack communities I’m in, where again, I find myself— actually, I find myself going back and trying to find the old threads for when I answer the question again to say, oh, go look back at this whole conversation. And it’s very cumbersome to your point, right? Like, it’s a lot easier if you can go back and then someone can participate and kind of bring that thread up again even. If it’s in that long-term memory kind of model.

Jono: [00:19:42] It’s one of the reasons why— exactly, it’s one of the reasons why I’m a big fan of, for example, one of the things I love about Discourse is that you can use a plugin called Solved where someone can go and ask a question and then you can have a discussion thread that happens. And then maybe the answer is the 16th post down there and you can mark that as the answer. So that means that somebody who just wants the utilitarian, I want to find the response to my question, they can go and what happens is that the answer is placed immediately under the question on the topic. So it’s very useful in that regard. And then you get all of the Google juice so people can go and find it on Google. People don’t go to websites now to look for questions. They type into Google or DuckDuckGo. That’s where they find things. But the thing I like about it is because it’s more of a discussion, people can have conversations and get the extra value that you’re talking about. They can explore what’s going on around that question. As opposed to one of the challenges with platforms like Stack Exchange, or Askbot, which is an open source equivalent, is it gets very utilitarian. You provide the answer, and that’s it. You don’t really build community. You build value, but you don’t build community. That’s one of the reasons why I think Slack has been so successful is you can actually have nice, interesting conversations with people. You can actually get to know each other. You can say, how are the kids? How was your weekend? And I think Discourse and platforms like that are a nice middle ground between those.

Matty: [00:21:12] I have a lot of other questions about that, but I’m going to put a pin in them for a second because otherwise this is going to be 45 minutes of let’s talk about Slack community management. This could be a whole other show. But so I want to spin off on something you talked about, different personas, and you talked about the idea of communities having champions, right? And I know this is something when we think about organizations who are built— trying to build community, this is something they really want, right? This is a good measure. This is a good— this is— we like having an advocate, having a champion. So if we want to— and it doesn’t necessarily have to be for a company, it could be for a project, for whatever. But if for some reason I have a desire to have more of these or elevate them or kind of discover them and help promote that behavior. What are some things to keep in mind when we’re saying this is important to us to have these advocates or these champions? I don’t want to say how do you create them, because I don’t know that you can create, like it’s, you know, but how do you enhance? How do you kind of discover the champions that are already there? Maybe would be a way to think about it.

Jono: [00:22:24] Yeah, there’s a few, I think, interesting things wrapped up in that question. So I think you’re 100% right, Matt, that you can’t create these people. Advocates, they spring up because they’re excited, because they’re interested, and because they’re passionate about whatever your community is focused on. What I think we can do, and what projects can do, is to facilitate those advocates more effectively. The way in which I think we get advocates to manifest themselves is, first of all, you’ve got to— whatever your community is focused on, let’s say you’re focused on an open source project, right? Your project’s got to be interesting. It’s got to be relevant. You can’t build a community around something that people fundamentally don’t have an interest in. So you’ve got to make a project, a product, a service, a mission that is fundamentally interesting is step one. But the second thing I think is getting people to dream big around what you can do with your community. So we are, as a species, very motivated around doing meaningful work. It’s one of the reasons why people get behind their political candidates. It’s one of the reasons why people join big, ambitious projects such as SpaceX or Hyperloop or various open source projects. Because they’re dreaming big. They have— I mean, the term moonshot is kind of overused these days, but they’re shooting for something that’s much bigger. So building a mission around what you’re trying to do here. So let’s say you have an open source project that’s focused on continuous integration. Saying, we are going to build the most powerful, effective, collaborative continuous integration community we can, in itself will get people excited than, yeah, we just kind of talk about continuous integration, right? So that’s one piece. The second piece, I think, is when— the way communities typically work, and I walk through this in People Powered, is I think of them as a journey, right? So what happens is, very briefly, is you define your personas, you onboard them to help them to do something really interesting as quickly and as easily as possible. And then they enter into like a 3-phase journey. First of all, they start out as casual members. So they kind of show up from time to time, they maybe answer a question, they do something, but they’re pretty spotty in terms of how they participate. And they don’t really know anyone, they’re a bit nervous, they have some levels of imposter syndrome. They don’t really— they show up when they— it kind of jumps into their mind. Then what happens is the more value that they experience in the community, they then become regulars, they’re showing up most days, They’ve probably got a browser tab open with your community most of the time. They’re participating more and more. They’re getting to know people. It’s feeling more like home. And then a small number of people will become what I refer to as core members who are super passionate about everything that you’re doing in the community and want it to be successful. So first of all, I think what you want to do is generally encourage people to go through that journey, which incentivization is the best thing to basically get people to continue through that journey, incentivization and mentoring. But then when people are poking their head above the surface and they’re clearly interested in what you’re doing, they’re spending time in the community and you just recognize their name more and more, is ask them to do things.

Matty: [00:25:43] Right?

Jono: It’s amazing if you just ask somebody, you don’t pressure them, you don’t bully them. But you say, hey, would you be interested in helping out with this? It’s amazing what people will do. Because so many of us just want to be helpful. So I’ll give you a concrete example that I use with so many different communities is content is a really fabulous way to pull people into new communities, right? You put it out on your blog, you put it on social media, and people read it, they find it interesting, and they come into your community. Um, but content is expensive to produce if you’re a company. You gotta get your staff to build it. So one of the things I often do is, is sit down, create a plan of things you would love to talk about with content. It could be tutorials, it could be demos, it could be events. And then just reach out to your community members and say, hey, would you be interested in writing something about this? We’ll Do some editing. We’ll give you some guidance. We’ll, we’ll help. We’ll, and we’ll promote on our social media networks. We’ll recognize you. You’ll be the author. We’ll use your Twitter handle and we’ll go from there. It’s amazing how many people will do that. You just got to ask.

Matty: [00:26:47] I think that’s, that’s really interesting. I was, I was just sort of doing a little bit of some mental notes around that, that idea of inviting people outside of your organization to contribute that content. And I think it doesn’t occur to us that that’s a thing you can do. And then it makes total— then you vocalize that, and I was like, that makes total sense to me, right? That if somebody asked me to do that, I would probably do that, you know? But, and I wonder if part of that is maybe it doesn’t occur to us because, number one, maybe like you said, we don’t think people would do that because we’re basically asking them to work for free, you know? Even though that’s not— I know there’s more nuance to it than that, but that might be what’s in our head is like, well, we pay people to do that, so why Why would somebody do it for free? Well, we pay people to be software engineers, but they still contribute to open source. And then on the other side, it could also be like, I wonder how you kind of— and I don’t want to go too much down this rabbit hole, but go down the path of like, within your legal and PR of your organization, like if you’re like, if those are things that sometimes make people get concerned about having outside folks, folks who are not employees, contributing. I know to me, logically, it makes no sense to be worried about that, but I’m not a lawyer at a company, or anywhere for that matter. Is that something, though, that you see actually being a challenge, or is it maybe just perceived, oh my God, this is going to be this legal nightmare?

Jono: [00:28:21] Yeah, definitely. It varies from company to company. Startups usually have much less anxiety around this because there’s a bit of a, all right, everyone, roll your sleeves up, let’s dig in and see what we can do. But when you start getting into bigger companies, and especially ones that are— that have a strong level of legal influence, right, this can be a problem. We need to get away in our industry from putting lawyers in decision-making roles. Like, this drives me potty, where you work on something, it could be a piece of content, it could be an event, and then basically lawyers take a look at it and they say, well, yeah, we probably shouldn’t do this, or we shouldn’t publish this, because there is legal risk attached. And I’m not going to bore your listeners with a 15-minute rant without breathing about this. But to summarize it, lawyers are not incentivized to let things through. They’re incentivized to reduce risk. And what’s the best way of reducing risk? Doing nothing. So it can be a real problem. I think there is a fear in some organizations of— companies are very— most companies, even like very modern Silicon Valley companies, with very modern remote working, and unlimited PTO, and all those different programs, there are still fundamentally structures of humans, right? It’s a hierarchy. You’ve got an executive team. You’ve got a senior management team. You’ve got these people who have direct reporting. People have got a contract. They’ve got expectations around the work that they’re doing. So when you start bringing a community into the mix, and you start saying, the way in which we build a great community is that our community has access to our teams, and the community can can provide— they can be a stakeholder, they can provide a level of influence. That can weird people out. And I think the key thing I would say to companies is, you’re not giving any control to your community. What you’re saying is, we’re going to treat you more like equals. We’re not going to treat you as this subservient group of people out there who chew on the gruel that we give them. We’re going to open up opportunities for dialogue and for participation. And when you do that, when you create a more collaborative environment, Shock, horror, people want to be more collaborative, like they’re willing to do things like this. If you have a very one-way environment where you have, you know, the company and your customers, and they get what you give them, they’re going to be less likely to play a role in this unless they can get something out of it. Like, people will often produce content for companies if they feel like they’re going to get a lot of exposure. Like, if Microsoft comes to you and says, you know, if you write something, we’ll post it on our social media networks, most people would do it because they’d love the exposure. But all of these problems can be gotten over. A lot of this, I think, is about setting very clear expectations about where does the line get drawn between what the community can and can’t do.

Matty: [00:31:32] That goes right into something else I wanted to talk about, where we think about— and this, I think, has been coming up a lot more lately, especially with the folks using open source as a business model. And that’s a whole other conversation about whether or not it really is one or not. Oh, yeah. That’s always—

Jono: Always fun, isn’t it? Right.

Matty: But if we think about that, we think about, uh, there’s a lot of stories, a lot of examples of, yes, um, an open source— something that starts out as an open source project and then it becomes, uh, a company. And that’s great, maybe. I don’t know. I’m not going to make a judgment about that. Um, I’ve worked for some of them, so I shouldn’t, you know, say anything too bad. Um, but, but then it becomes kind of— you could have this really strong community around the open source project. And then now it becomes Project Inc., right? And then you start to have all the things you just were talking about, about now, you know, folks who felt like they had a voice in what this thing was maybe have less of one. You’ve got lawyers saying what you can and can’t do and sounding like the chief no officer. So, when we think about that, if we want to— putting aside for a moment whether or not you should turn your great open source project into Project Inc. If you’re going to, what are some of the things to kind of keep in mind? And we already touched on that. And maybe let’s talk about some folks who maybe have done that well. Like, I don’t want to talk about people that did it poorly. But, you know, let’s talk about maybe some good examples that we can not necessarily copy, but learn from.

Jono: [00:33:04] Yeah, it’s a great question. I think so much of this, as well as many other things in life, are just about setting very clear expectations. One of the mistakes that I think some organizations make when they go down this path is that they’re worried about pissing off their community. So what they do is they tacitly agree to everything. And I think it’s okay to say, this is where we’re drawing the line on these different things. And if you don’t like that, that’s completely fine. Reasonable people can have reasonable disagreements. But it’s better to set those expectations upfront. And then people are all on the same page. I often say this with people who I work with. Part of being a consultant is I end up working with senior people in the company, I end up working with the people who are on the ground doing the work. And sometimes difficult feedback needs to be transmitted between these 2 different groups, or difficult commentary of what’s going on. As a consultant, I have an opportunity to do that, where other people would feel uncomfortable doing that internally. I’ll often say to people, I’d rather piss you off now than piss you off in 6 months. Let’s have a conversation about this. Let’s deal with it. Let’s rectify it. Let’s find an outcome and go from there. The first step in my mind is it’s really important to set very clear expectations around the codification of how the community is going to operate. So particularly if you’re going from an open source project to having a company that’s wrapped around it, typically what that means is a company is now going to be formed that’s going to be the primary investor in that. We’ve seen many examples of this, right? Red Hat, Canonical, HashiCorp are all good examples of this. So setting very clear expectations up front is one piece. And I think regularly, building a dialogue with your community, and being explicit about saying, we want to hear the things that aren’t going well. One of the things I try to do, not just again, with communities, but just in my career in general, is to say to people, I don’t just want to hear about when I’m doing things well. People will often heap praise on someone, but to say, don’t tell me that I suck, but tell me where can I improve? Give me constructive feedback. Often, what happens is companies don’t do that. They don’t say, either in a public setting or in a private setting, what can we do to improve? So what happens is frustration builds up in the community, the company doesn’t see it. And then it results in a giant kind of, you know, seismic event, someone writes a letter, someone produces— puts out a video or something along those lines. So the companies that I think do the best job here, what they do is they build that in the same way that I mentioned with a collaborator model with the inner type, they build a very inclusive collaborative environment. So they have open issue tracking, they have open code, they have regular meetings with community members. It’s not just the community member— community manager being an ambassador to the community. Like engineers are feeding in, product people are feeding in, the CEO of the company is a member of that community too. And they’re proactive about communication and about setting expectations around what the company is working on, what the company is not working on. And I think— I mean, I mentioned a few examples earlier on. I think HashiCorp are a fantastic example of doing this really well. I think in many cases, Docker have done a good job with this. I think Microsoft are increasingly good at this. Red Hat’s done a phenomenal job of this. I think Mattermost do a great job of this as well. And it— but it’s, it’s a delicate balance. And in small companies, it tends to be easier, particularly when people come from an open source background, because they’ve seen good and bad examples of this. Where it gets more difficult is when a company grows and you start hiring people outside of open source, such as salespeople, product people, support people. You need to make sure you set those expectations very clearly upfront. And I think one of the best companies for doing that has been Red Hat. They’ve done an amazing job in training non-open source people in helping them to understand the open source nuance.

Matty: [00:37:15] I was thinking about when you talked about setting the expectations up front, and like you said, I’d rather disappoint you now than later. It brought to mind, you know, Solomon Haik’s great comment that he was, you know, the first rule of open source is that, you know, no is temporary, yes is forever, right? So if we’re— so if in the beginning we’re saying, hey, you don’t have a seat at this particular table, we can always give you the seat later, but if we give you the seat now, it’s a lot harder to take it away, so to speak, right? Like, so it might be something that like, hey, while we’re figuring this out, we’re going to be a little more restrictive if that’s the case, but wherever it might be, right? Because it’s a lot easier and people are much more pleased with getting a surprise yes than a surprise no, right? Like, later on if I’m like, hey, guess what? Turns out, you’re like, oh, that’s great, other than, hey, guess what? Turns out, strangely, that doesn’t go over so well. Yeah. I wanna take a couple minutes too to think about the idea around measurement because we, you know, we love us some data, you know, in this world. And also the reason I kind of want to think about like how we measure effectiveness and impact of the community is that I’m a big believer that, right, I’m kind of leading with the giveaway, right? Incentives drive behavior, which drives culture, right? But also, people will work to the metrics you give them. I’m fond of saying, when people say, what’s the most important DevOps book to read? I say, go read Freakonomics and go learn about incentives and economics, and that will tell you everything you need to know about culture change. So thinking about that, measurement mattering, what are some practical and useful measurements that will affect the behavior of our community, but then also affect the behavior of our organization in a way to help build community, right? And then maybe what are some ones to avoid that are maybe common, that people think are rational and good, but actually might not be so fantastic?

Jono: [00:39:25] Yeah, that’s a great question. So I think we need to slice this, first of all, via the persona. Because the way in which you measure, for example, software engineering, it’s very different to the way in which you’d measure, let’s say, design contributions to a community. So the first thing we do is we identify the personas that we’re targeting, and then identify what are the most relevant metrics that we choose for each. Now, from a strategic approach, the thing that people should absolutely avoid is this current data fetishism trend that’s happening, where people are setting up metric— like dashboards with hundreds of graphs that track every conceivable notion. That’s a complete waste of time. Like, focus on what are the things that you want to discover about your community, and then track the things that are most relevant to that discovery. So for example, let’s look at software engineering, people contributing code to an open source project. There’s basically within that, there’s 2 types of data that we can track. There is intangible value, and there’s tangible value. So tangible value is the things that people do that you can measure with computers. So for software engineering, I would be tracking, for example, the number of pull requests that have been submitted, the average time for a pull request to be reviewed and merged in. I’d be tracking time to the first response on a pull request. I’d be doing similar things for issues, like number of issues submitted, time to first response for an issue, average lifespan of an issue. I’d be tracking the different issue types, um, like with labels, and, um, you know, how many, for example, wishlist pieces are coming in, how many confirmed bugs are coming in and then getting, and getting fixed. Um, so those are very tangible things that we can track in places like GitHub and GitLab and elsewhere. But what that does is that basically, within that persona of software engineering, that gives us a sense of being able to track software engineering and community participation among that. The intangible value of communities are the things that you can’t track very easily with computers, such as, are people happy? Are they having fun? Are they learning? Are they meeting new people? And generally, the best way to track these, frankly, is through good community managers who can observe behavior, and to be able to track it in a somewhat manual way. And it’s difficult, because there basically is no perfect way to track intangible behavior, not yet. When the Borg eventually gets built, maybe that can help with it. The thing is, with each metric, I think what you want to track is— there’s 2 types of way of looking at, I think, a metric. One is, an action, which is doing something, so such as submitting a pull request, we can track how many pull requests are submitted. And that gives us a sense of how many people are contributing. But that doesn’t tell us anything about quality, because someone may submit a pull request that’s crap. So the validation for the action, within the context of a pull request, for example, would be it being reviewed and merged in. So I think it’s always good to actually track the action, and then to track the validation of the action as well. So again, break it down into the personas that you look at, that you’re looking at. The thing I would recommend people don’t track is tracking repetition of the same thing over and over again. So for example, in, you know, days of old, people would often have, you know, if you hit this many posts on the forum, 500 posts, then you get added to this, you know, special ranking. Because what that does, to your point, Matt, it incentivizes people to then post lots of stuff. And if that stuff is crap, then people get to the ranking, and they appear to be smart people, but they’re actually not. They’re just, you know, very repetitious people. So that’s how I would approach it. But very much like pick 5 things. The key thing with metrics is that I found that works very, very well is the way in which communities evolve and grow and where we should make them better. Is you pick your 5 metrics or 10 metrics, for example. And then on a regular cadence, let’s say once a week, once a month, go and look at those metrics and try to look at the patterns that you’re seeing in them, right? So for example, if you see the time to first request with pull requests— the time to first response with pull requests is gradually getting slower since a particular date, look at what’s changed in your community around that time. Like, could it be summer? Is it summertime and that’s the reason why it’s slowing down? Could it be that there’s a lot of work going on on a new release that’s slowing people down? So look for those patterns because that will tell you then what changes you need to make in your community.

Matty: [00:44:11] I wanted to think about when we’re building a community or enhancing a community or just being focused on a community, if we’re in some kind of role where we’re community-focused, I wanted to think about some of the ways that we can think about personas that aren’t us. So I know there’s— if you’re a professional and this is what you do all the time, then this probably should be something you know how to do, but maybe not everybody is a professional community manager or something. And I think about instances in different communities I’ve been a part of or different tools we’ve built that have a community aspect. And for example, it might be like, hey, we’re building this thing, it should have a share it on Facebook button. Right? And then the engineer said, well, I don’t use Facebook. Facebook is stupid. So, like, I don’t think we need to integrate with Facebook, right? Like, and so how do we kind of— there’s so many different possible ways when that comes in. So if we’re— if again, we’re not Microsoft, we’re not a very large— or Red Hat, we’re not this large organization that has focused people, but maybe we’re trying to build a community around a smaller organization, not necessarily a project, could be a project, or could even be like you gave the example, like DevOps, right? A way of similarly minded practitioners, and we’re trying to do that. How do we keep on top of all the different ways personas might work because they’re different than we are?

Jono: [00:45:32] Yeah, it’s a great— it’s another great question. You’re full of them today, Matt. So I think there’s a, there’s a few of these elements that play into this. One of the big challenges with building communities is it can seem a little bit overwhelming. There’s a lot to do. There’s lots to think about here. And without wishing to just shill my book, that’s one of the reasons why I wrote People Powered, is to provide a relatively straightforward blueprint and recipe for how people can take all of this and organize it in their brains and organize it in their lives. I think the most important thing to do is is to getting to a workflow of how you organize this. So, um, for example, I was chatting to someone last week who is a community director at a company that I’m working with, um, and she was panicking because there’s just so much to do and she just felt overwhelmed by it all. So what we did is we basically broke it down into like a big list of tactics that she needs to focus on, and then we break it down by quarter. And then what happens is you can basically say, okay, if it’s in Q1, we don’t have to worry about it right now. We’ve thought, we’ve done the thinking, we’ve got it planned, it’s in the plan, but we can focus on what we’re doing in Q4 right now. So I think that’s one element is just being organized. And that’s difficult because it requires discipline to put together a plan. And again, I walk through this in People Powered for how to do that. But the second thing I think is the best way to understand people who are different to us, is to talk to them, is to get their input. But we have to be, again, intentional about that. Intentionality is a core theme throughout all the work that I do and all the writing that I focus on. Let’s say, for example, you’re building a community of translators, and you don’t really know anyone who’s a translator, but you know that people would be interested and could be helpful in translating your project into a whole bunch of different languages. I would put in your calendar a regular meeting with different translators who are in your community just to say, how are things going? Completely open-ended. I’m here to listen. Like, what’s working well for you? What’s not working well for you? To tease that information out, because all of them, all of the answers to how to do this kind of stuff well live in your audience’s brains. They’re all, it’s all there. We just need to figure out ways of teasing it out. And the way to not do that as a general rule is through surveys. Surveys are good. They can give you some data. But I think generally, people are much more willing to give you more valuable content if you basically hop on a call with them and ask them. But again, it requires being— to say like, I want you to tell me where we can improve. Just saying like, can you give me some feedback? They’ll just tell you good stuff. But saying like, I want you to tell me where we can make a better, bigger difference in this. And it takes time. And eventually what happens is you will build those skills and you’ll understand those people better. But that’s one of the reasons why I often say to companies, and one thing I say in People Powered is just start simple. You know, the worst thing you can do is to set up a really big complicated community, just start simple. And then again, track the data, the limited set of metrics for your limited set of personas. And then gradually bit by bit, the picture will just start becoming clearer. It’d be like seeing the sailboat, one of those Magic Eye pictures, it’ll gradually come into view. And then before you know it, you’ll be a pro.

Matty: [00:48:59] Fantastic. Well, I will shill your book. So the book is People Powered: How Communities Can Supercharge Your Business, Brand, and Teams. We’ll put some links in the show notes to where you could grab it. Those will be at arrestedevops.com/communitysmadeofpeople. But, you know, y’all know how to use Google. You know Jono’s name, you know the name of the book. I’m sure you can find it in all the various places. Buy all the different versions. Get the ebook, get the audiobook, get the hardcover.

Jono: All the things.

Matty: Hey, it’s getting to be holiday time. Maybe it’s a great present.

Jono: What I’ll do, Matt, is I’ll send you a link as well that’s got a discount on it as well.

Matty: Fantastic.

Jono: So they can, they can save like $4 or $5 on that.

Matty: So perfect. So go to arrestedevops.com/communitysaremadofpeople. We’ll have the link for you for the good discount. And I would also, again, even if you’re not a community management professional or whatever, I think this is a great read because we are all part of some community. We want to make those communities better. And I think there’s a lot of really interesting stuff in there. So, Jono, where can our listeners catch up with you? You know, you don’t have to give out your personal home address, you know.

Jono: [00:50:06] Buckingham Palace, London.

Matty: Yes, maybe a more practical way, you know, any upcoming speaking or book signings or anything fun like that?

Jono: Yeah, I mean, so probably the best place people can find what I’m doing is my website, which is jonobacon.com. J-O-N-O bacon, like the delicious meat, dot com. And then also, you know, the usual social media networks. I’m pretty much John O’Bacon on everything, with the exception of Instagram. Some— someone stole my name on Instagram, so I’m John O’Bacon Graham on Instagram. And right now I’m just doing, I mean, all kinds of speaking all over the place, like speaking at various meetups, and particularly with the new book that’s out and doing lots of podcast interviews. So social media is generally the the pulse of what’s going on. And People Powered is available in all good bookshops.

Matty: And even some that maybe aren’t so good. Yeah, maybe mediocre bookshops too.

Jono: I hope so. I hope it’s in bookshops that suck.

Matty: [00:51:07] You need to start doing the thing that Neil Gaiman does, like once it starts showing up in bookshops, like he’ll just bop into bookshops and he’ll autograph books, his books that he finds in bookshops, like surreptitiously, you know. And so Oh, that’s cool. Yeah, that’s a great idea. Yeah.

Jono: Yeah.

Matty: I am not doing any book signings either surreptitiously or like publicly, but I will be. I’m coming to the tail end of my work travel for the year, which is fantastic. So I have one more event this year. I’ll be speaking at DevOps Days Tel Aviv, December 18th and 19th.

Jono: So have you, have you been there before?

Matty: I have not. I’m very excited.

Jono: It’s I spoke there last year, and it’s awesome. Um, and they’re a great group who run it. Like, yeah, you’re gonna have a great time.

Matty: So I’ve heard nothing but great things about the event.

Jono: Fabulous.

Matty: Yeah, so it should be super fun. So hopefully I’ll see some of you there. Um, if you would like to give a talk at a DevOps Days, you can go to devopsdays.org/speaking, and you’ll see all the events that have open CFPs. And, uh, again, go over to arrestdevops.com/communityismadeofpeople For this episode’s show notes, we’ll have a bunch of great links, including this awesome discount link to Jonah’s book. If you go to arresteddevops.com/itunes and leave us a review in the iTunes store, that actually does help people find the podcast. So do that if you like or don’t. We also are— we’ve recently found out we’re on Spotify and iHeartRadio. So if you use those things, search for us and check us out there. If you’re already listening to us there, send me a tweet and let me know, because I’m curious if people are doing that. So, Jono, thank you for joining me today. I really appreciate it.

Jono: [00:52:46] A pleasure. Great.

Matty: Uh, I’m Matt at Matt Stratton. This is Arrested DevOps, and remember, there’s always DevOps in the banana stand.