 Good morning. I hope everybody got to see that keynote. That was an excellent, excellent talk and actually a pretty decent segue into what I'm gonna be talking about. My name as exhaustively described is Adam Kaufman. I'm a DevOps practitioner at Veracode QA, a CA. Forgive me, that's a recent development. And I'm here today to talk about community building in a development organization. Why is it important? Some techniques that we have found to be useful at Veracode and some outcomes that we have observed both in and outside the box. So I'm gonna start with the problem space. I imagine everybody here has seen this picture or something very much like it. I actually had to recreate it so you haven't seen this exact picture but the whole idea of DevOps, Dev QA and Ops together bringing all the expertise onto the team has been taking over the industry and for good reason. There's no hand-offs, there's no silos. You are empowered to do everything that you need to bring your work from ideation to operation. And it's really a great workflow for a team, for an organization with one or two teams but as you scale it out, across an organization you might get a picture that looks a little bit more like this. And when I look at that picture, I see silos. Each team can do their own thing extremely well and unfettered and that's great but at an organizational level there can still be quite a bit of waste here. There can be lack of consistency across teams. There can be difficulty in knowledge sharing, any kind of common solutions. Each team has to ramp up on these things on an individual level and that can be pretty challenging. So the question is how do you improve consistency and knowledge sharing in a situation like this? Well invariably you need some kind of a central authority to administer shared services, to come up with and maintain consistency standards, that sort of thing. It's probably a small group of people might only be one or two people and they're tasked with doing this across the organization which is challenging. So how can you help that task? Well, this is the missing piece. It's a communication layer that binds the entities together and that communication layer is email. No, no it's not email. What kind of communication are we talking about here? Development organizations care about sharing standards and technologies and procedures and methods and best practices across their teams. You don't want to reinvent the wheel every time, right? These things are important. And what we're talking about here is how an organization might communicate these things. There are different ways this goes and people are gonna be familiar with these. There's top-down communication which certainly has some advantages. It can be clear and controlled, single message. It's easy for the organization to know what people are hearing, control what people are hearing, but it also has some disadvantages. It's inflexible. There can be considerable overhead that is associated with crafting and pushing that message around the organization, making sure that everybody understands it to be the same thing. And if it's done tightly, then it can really stifle innovation because you're limiting what people are able to work on. So what's the opposite to that? Well, it's bottom-up communication. And similarly, bottom-up communication has some advantages. It's low overhead. You have a lot of individual contributors which are able to come up with their own message and communicate it out to whoever's willing to listen. It's very empowering. I mean, that feels great as an individual contributor. And with a system like this, you can enable, there's that term again, outside the box, solutions, which is potentially a very good thing for the organization. There's also some disadvantages. It's totally scattershot. There's no way to ensure consistency of messaging across an organization. And it can be very low visibility. When you have a lot of people that are talking to whoever's directly around them, that message, how far is that message gonna go to get around the organization? So that's a question, that's a challenge. So what we want might look something a little bit more like this. You get a little top down, you get a little bottom-up and you get a radiator, an information radiator to spread those messages around the organization. And this is the promise of a well-built community. You end up with a flattened organization. You end up with more engaged contributors. And every time I do this, this word sounds a little bit more ridiculous. But crowdsourced innovation, right? You have the ability to bring innovative ideas in from across the organization, right? And that's really what we're going for. So as I was developing this talk, I realized that the word community, and this actually goes back to the keynote we just heard, that could mean a lot of different things to a lot of different people. So with all of this context, we might define the word community, thusly. A group of contributors with a shared set of goals and processes who are connected by a common mode of communication. And that is what we're trying to build, all right? So how? In this section, I will talk about how you might go about building such a community. The basic building blocks you're gonna need some theoretical and applied concepts and some anecdotes to hopefully assist in driving the various points home. And with that, I will offer a disclaimer. I will be calling out some specific products in this section. I have not been paid by the developers of these products and I'm using them purely as a mode of practical specifics, not advertisement. I don't presuppose to know what the best thing is. These just worked for us. So when you're building anything, you need a seed. You need to start with something to build around. People need something to coalesce around when you're forming a group. Some kind of a common goal. A specific technology can be a good choice or a process. But very importantly, it needs to be something that contributors have to interact with on a daily basis. That daily interaction is gonna be very important and without it, without the continuous relevance, you would find that people will lose interest in the community discourse. Because they'll get pulled off on other things, this is not a value judgment. We all have busy lives, we all have lots of work to do and other things take precedence. So continuous relevance is very important because you don't want your community to lose value. So some time ago, about a year ago at Veracode, we had the opportunity to revamp our continuous delivery infrastructure. And after some research, we landed upon the product GitLab. I don't know if you're familiar with it. I see some nodding heads. It was perfect for us for this situation because it combined source control management and CI CD pipelining in one useful package. And we were able to host it ourselves, which is very important for a lot of organizations. And as luck would have it, it was also the perfect seed for this kind of community building. Because it's central to any DEB team's mission. Everybody needs to build and test and deploy and all those things. So it had that daily relevance we were talking about. There was also a need to learn a new paradigm, learn a new way of doing things, which and learning is also central to this idea of community. And thankfully, they had pretty good documentation so we were able to do it in a fairly self-service way. So the next thing that you need, really the only other thing you need is you need a platform. You need some place where the community can coalesce. This should be a public forum. I can't stress enough how important it is that it is a public forum. It should allow for both synchronous and asynchronous communication. They're both very important. If you ask a question, sometimes you need an answer immediately. Sometimes you don't. And if you have the answer to a question, you might not always be on hand. So it's important to have at least the possibility of being able to answer that question later on. And along those lines, notifications are very important. For asynchronous communication, if you just have a thread of messages and then there's a message, there's a question that went out and then that message just disappears into the thread and you don't have any way to refer back to it, that can be challenging. So notifications are also important. Notifications, of course, without being spammy. Spam is trouble when you're talking about communicating with a lot of people. You want to try to avoid it, so. Another key element is opt-in, opt-out. So what do I mean by that? It's important for contributors to be able to come and go from the community as they please, as it is relevant to them. When you force somebody to be in a certain place or to engage with a certain thing, you're not actually going to make them any more engaged. I mean, it might work. It might be a good fit and it might work, but there's no guarantee there. A much better indicator is whether they're there of their own volition, right? And so if you allow that, it gives people agency and that sort of thing is important. And also, it provides a nice trailing indicator. If you're gaining users, then your content is good. People are finding value in it. And if you're losing users, well, that's something you probably want to think about. So the platform that we ended up with, we actually backed into, it was something that we were already using. I imagine most of the people in this room are probably familiar at this point with Slack. Slack is basically, for those who haven't used it before, it is IRC with a coat of paint. It's a nice coat of paint and they have some higher level functionality that they've built on top of it, but essentially at its core, it's just an enjoyable chat app where people can call less. And it worked out perfectly for us. There are some, and there's some high level functionality, as I mentioned, which I'll actually get into a little bit later. So I want to talk a little bit about guiding principles. Now that you have the things that you need, how are you going to go about using them? Good groups have founding documents and this is kind of like that. So the first guiding principle I want to talk about is teaching to fish. It's a phrase that everybody has probably heard already. I guess I'm using a bunch of those today. You have a central authority, which is responsible for setting this whole system up as we noted as we were building that background image. And the central authority and the subject matter experts that come into this situation should definitely be helping teams get ramped up and that sort of thing. But you want to avoid in as much as is possible doing things for teams. You want teams to be able to do things for themselves because the learning is really a big part of why this is important, right? And the more people you teach, the more teachers you have and you want that snowball or flywheel effect to take hold here, right? So the analogy that we like to use is the tackle box, right? You want to make the right way to do something, the easiest way to do something. And we're talking documentation and tutorials and FAQs and reference implementations and of course, you know, a helping hand when necessary. But you want this to be as self-service as possible, right? You want the static materials that you have developed to you want to be able to hand those to somebody and have them get going on whatever it is that you're building this community around. And it's actually funny that I chose the word static there because these materials should be anything but static. As you give them to people, as people start to use them, you should be soliciting feedback from your users. And moreover, you should be incorporating that feedback as soon as you get it and building this documentation base, building this tackle box as you go. Because the first time you do it, you're not gonna get it right. And plus the system is probably gonna be changing as you go. So you wanna make sure that it stays up to date. If this sounds like a wiki, well, it certainly could be a wiki. It could absolutely be a wiki, but it has to be a very well and carefully maintained wiki. I think we've all been in a situation where we've been directed to some documentation that is just a mile of plain text, which takes forever to read through, your eyes glaze over halfway through. And by the time you get to the end, you're not even sure whether you read, whether you actually found what you were looking for. Moreover, wikis tend to drift over time. And actually, time scale is very short, wikis tend to drift very quickly. And so you have to maintain it. You have to make sure that the information is relevant and is concise, well organized, and engaging in as much as that's possible. One way to think of this principle as a whole is scaling subject matter experts, right? You come into a situation where there's a new technology and the organization, you're trying to share it across teams, that sort of thing. You have some subject matter experts and you want more of them. That is how you grow value in a community. And if you're not able to scale subject matter experts, it's not gonna work. The next principle I wanna talk about is keep it public. I said earlier that it's difficult to overstress how important it is that the discourse be public. One rule of thumb is every private conversation is a lost opportunity for somebody to learn. Every time you direct message somebody, then somebody else who had that question isn't gonna get the information. So you want to be funneling all of the relevant questions and discussions to the public forum as much as you possibly can, which does go against the natural inclinations of a lot of people. We all have individual experts that we rely on when we have a question about any number of things. It's just the natural way. You know somebody who you think's gonna know the answer, you're gonna ask that person because it's the fastest form of communication just person to person, right? But let me tell you something about that person. You know the guy who knows all the things? He's been at your company for forever and he's touched all the different products and he knows how everything fits together. And if you ask him the question, it almost doesn't matter what the question is. If you ask him, he's probably gonna know the answer. And if he doesn't, he's such a nice guy that he's gonna drop whatever he's doing and he's going to help you puzzle out the answer, right? You know that guy, you know what I'm talking about? Yeah, let me tell you a little something about that guy. He is totally overwhelmed and he is probably not doing his day job very effectively because context switching is incredibly expensive and dropping everything just to talk to whoever is screaming the loudest at the moment is not a good way to do any kind of plan for work. So it is really helpful for the organization and helpful for this guy's sanity. If you have a place that you can ask your questions to a wider audience and hopefully get the answer there before you go, before you go to the private message, right? And I'd offer one more anti-pattern here. The slowly growing email chain. So person A has a question and I think person B is gonna know the answer, right? So they email person B directly. And person B says, well, I'm not sure actually but I think C or D are possibly likely to know here. So they CC C or D and here's the question. Well, C doesn't even respond because they're out of the office but D says, oh man, that sounds really familiar. That sounds like something that I heard maybe like a year ago when I was doing this project with EF and G let me put them on the email too, right? And before long you have an email thread that's about some back and forth between 25 people and you're talking about something that's not even related to the original question. This is not an efficient way to communicate. This is not an efficient way to get the answers. And this kind of a community is the one way to avoid that sort of situation. Keep it public. Don't start private and co-public, start public, go private. So the last guiding principle that I would offer is to be engaging. The title of this talk was crayons, glue and scissors, stickers and well, scissors or stickers, whatever you need at the time. You want to be able to be engaging. UX is important. I mentioned that the UX and Slack is good. That's a helpful tool but it's more than that, right? You want to find excuses to add flavor to dry business interactions, right? You want to be able to elicit creative inputs from people whenever possible. You want to bring up day job adjacent topics if they seem relevant, right? Or if people bring up day job adjacent topics, just your contributors bring up whatever is on their minds then you're probably doing something right. Keep it clean, of course. You don't want to get out of control and also you don't want to go too far down the rabbit hole but this is, it's a sign that people are engaged. If people are just talking and people are engaged and I think it's a very good sign. One thing that we've done with our community at Veracode, the one that inspired the talk, is as we, as I mentioned, it was a continuous delivery infrastructure and as we were revving that infrastructure, we decided we didn't want to use numbers. We wanted to use names and that quickly settled into the pattern of hurricane naming, so alphabetical, boy girl, boy girl. And a few names in, we started asking people, well, we're sort of banging these names around, what does everybody think? Can we get a couple of answers and we'd settle on a name and that was fine. That grew into a situation where now we will side thread. I was talking about some of Slack's features or one of their neat features is threading, right? So you can open up a little mini-channel within the channel. We will side thread an ideation session about names and whatever letter we're on, right? And come up with 20 names or whatever, we'll winnow them down and then we will create a poll in the channel to vote on those names and we'll get maybe one, two dozen responses and then we'll have a name. And not only will we have a name, but we will have a group of core contributors who have some ownership over, not just the community that they're a part of, but the seed, the technology that that community was built up around, which is pretty cool. It definitely helps people to be engaged. I keep using that word engage, but that's what this is about. This is about engagement. So with that, I wanna talk about some of the outcomes. Just go over a few of the outcomes that we've seen, both positive and negative. So some of the benefits that we've seen here, as I've alluded to, you reduce single points of failure, which is a big deal. When things go wrong or when there are questions that the answers to questions are known by a wider group of people, right? You have more subject matter experts, you have fewer single points of failure. The idea of crowdsourced support, right? Another way to think about this is the bus factor. Everybody knows about the bus factor? Well, if the bus factor goes up, that's awesome. And B, the mean time to resolve simple issues comes down, which is really nice. If you have a lot of people that can answer the question and you have a place that you can ask it and a lot of those people will be listening, then you're probably gonna get an answer pretty quick. And it doesn't matter whether someone's on vacation or not because somebody else can answer the question, right? So the mean time to resolve simple issues definitely comes down. Because of the emphasis on learning, contributors really end up learning the system. And teams get the knowledge within that tight knit group within that tight knit group of how to interface with and how to build around the central seed that you're working with. And the quality of questions goes up and the quality of implementations goes up. People are able to do more nuanced things because they understand the base of what they're working with as opposed to just being handed something. I mean something like a continuous delivery pipeline. There are organizations where there's a guy who's responsible for just setting up the continuous delivery pipeline for all the teams. This team needs a pipeline. Okay, what does that mean? It's very specific from team to team and this is a good way to solve that problem. The idea of internal open source. I'm a big fan of open source generally and this whole community idea is actually similar to the idea of an open source community, right? You have opt in opt out, you have people are there cause they wanna be, people are engaged because they're interested. Well, unsurprisingly if you foster that kind of a community, you end up with a system of internal open source where people are building tools to solve the problems that their team is facing but because they're part of this community they might be building them with a slightly more generic bent. So they could possibly be used by a wider variety of teams and then they share them around and you know what, people do use them and I think that's a real positive step. And possibly my favorite thing about it is it's a forum for motivated people to hone their leadership skills. If you have people that are really interested in the topic at hand and have strong ideas about how things should be done or some new way of going through things, this is an opportunity for them to speak up and maybe provide some direction for their team and others and start conversations and lead conversations and it's really, it's pretty great to see. It gives you the best chance at arriving at the right solution for the most people as an agreed upon standard. I like that, that's good. It's of course not all peaches and cream. Yesterday's keynote, they were talking about bimodal IT and the whole mode one, mode two, you have the data center and you have the innovation off to the corner thing. In mode one, this isn't really gonna work very well. It's all about momentum and it's all about empowerment, it's all about self-service. So if people have a forum where they can ask questions and they can get answers and those answers are, go put a ticket in IT's queue, that's probably not gonna be, that's gonna slow things down, right? And that's not what you want. So it's definitely better if you're talking about a situation, if you're building a community around a place where or a thing where teams are empowered to do things for themselves, self-service. It's like a generalist playground. Generalists will absolutely thrive here because it's all about learning, it's all about take this thing which isn't maybe your core competency but learn about it and find out how it can work for you. That's great for a generalist. Specialists may end up keeping a little bit more to the periphery because that may not be their bent and you just have to be honest about that, right? If there are only one or two teams, as I said before, this is about when DevOps teams scale out, right? That's when this is useful. If there are only one or two teams, it's probably a bit of a misplaced effort to spend too much time on this because you don't get as much value from sharing the information around when there are not as many entities to share the information between. And also the last thing I'll say is the goal here is to increase self-sufficiency, right? Each team, you want them to be able to do what they can do. It's like automating yourself out of a job, right? When teams are fully ramped up, there might be, they might have a few questions or a few conversations they want to have, like the sounding board thing where there's some really complex and nuanced implementation that's interesting and has anybody tried this, is this something? You'll get those kinds of questions but you won't get nearly the volume. The volume will go down over time as teams are fully ramped up and it won't be as fun and exciting as it was when right in the middle, when half the organization was getting in there all at the same time. And that can feel a little bit like a downer but honestly calling it a bad thing is a little misleading because what you did worked. You succeeded. And I have succeeded in going through all of my content and I'm having trouble. Are there any questions? I was wondering if you could talk about working across, like outside your organization, like if you have vendors onshore, offshore, outsource who are being expected to take a big role in what you're trying to accomplish but maybe have separate systems for, you know, tasking some of the tools that you mentioned earlier. Sure. Well, I think that as far as the specific framework that I've laid out here, it's more something that's internal to an organization. If you're trying to integrate external entities, I suppose there's no reason that you couldn't do essentially the same thing. It would just have to be an externally facing communication platform, right? Whatever the seed is that you're building around, that can be maybe integrations with your core product, right? In which case you would be very interested in engaging the outside community. You just need a communication platform where you can invite them in and you can say, hey, come here, ask your questions, talk about things once they're on there. Again, you know, if they stay, then I think it's probably gonna be pretty successful. So don't have a ton of time to respond to this but I'm worried about there being a really tight Goldilocks zone here and a lot of ways to get it wrong and you being up there saying this work for us could just be survivorship bias. Can you respond to that in any meaningful way? Well, just like anything that is built on people, it's going to be subjective, it's going to be different from situation to situation. I think that the core ideas here are going to be pretty flexible and should be applicable to a lot of situations. But you're right, it probably wouldn't look exactly the same and if you... Well, yeah, it probably wouldn't look exactly the same but I suspect that if you spend some time thinking about it and you try to keep to the basic set of principles, assuming what you're trying to do is to build cross-team competency around some shared goal or technology or process or what have you, you probably, I think it would be successful. Do you have any more specific... Maybe we should talk about it afterwards. With transitioning from private to public forums, how have you addressed getting the extra noise from just day-to-day banter that kind of drowns out the main point of the discussion when opening up to a larger group of people? Do you mean like introducing day-to-day banter or do you mean... Yeah, say I go to ask a question and pose it to a larger group and with a normal casual conversation among a big group, you might have side conversations spawned from that and the conversation kind of goes off the rails. How do you avoid that when getting into discussing in a larger forum versus a one-on-one? Sure, I think the key there is to use your intuition about when the inflection point is because you want to encourage that. You want to encourage people to have a free-flowing conversation that goes in whatever direction because frankly you don't know what good things could possibly come out of it either related to the original question or not. But at the same time, if you go too far down the rabbit hole or off the rails, you want to be able to, as a moderator or what have you, you want to be able to say, hey, maybe you should continue this elsewhere or if you're using something like slack and there's threading, then maybe encourage people to start a thread and say, hey, just take it off to the side, right? Because I really think, yeah, the key is in, it's a matter of degrees, right? You definitely want to encourage it, but you also don't want to let it go too far and that's going to be a subjective thing, a subjective call you're going to have to make. And on that note, thank you very much. Thank you, sir. Thank you.