Carl Chesser

Hi everyone. I'm Carl Chesser, and I'm here to talk to you about navigating change with communities of practice. My background extends in the healthcare IT space for the past 17 years, most of that time with Cerner Corporation, which is a large healthcare IT company, and now most recently with Oracle.

In this talk, I'd like to share a lot of my personal experiences and lessons learned that I have observed over time in managing communities of practice. As we start talking about communities of practice, you may see, hey, this isn't really a new idea. The term may be a little bit new to you, but much of my experience when I was first working with this over the years, I just kind of considered around managing technical communities. This will touch on how we're doing things with communities of practice.

So in this talk, we're going to have the flow first talk a little bit around the background about community of practice, some on the terminology, and a little bit about the value of those and how to look at the value in applying those in your organizations. The other part will be around communication flows. This tries to focus on what are some very important things you may want to observe of how you're engaging your teams across your organization. This talks about both different paths of vertical and horizontal communication paths, as well as cognitive load that can come to teams depending on how many inputs are coming into the team and communication that a lot of times can increase when going through change. In the last part around this will be some lessons learned, things that I've observed that have really helped in managing technical communities, where we can get some really good value out of those and how you can really grow a strong network of knowledge within your organization. Lastly, we'll hit on a few summary points through this talk.

So first, what is a community of practice? Wenger-Trayner has this definition: communities of practice are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly. I think this is an important thing that you probably have observed with any technical community, those coming together about honing their craft and improving it. I think an important piece of this I'd highlight is how they interact regularly. In a large company, you're trying to make sure you can foster how they interact regularly to grow ideas as well as externalize challenges they may be observing within your company.

This is important because as you're growing the community of practice, so in a given technology space or a given area of process you might be trying to improve when change is occurring, a lot of times you're trying to get people to share what is not working well and try to come up with a larger, better approach that is powered or sponsored by these different minds as part of your community of practice.

One thing I had when I was thinking through this is, what is it not? I had a few things in here that were examples that came to mind. You can think about someone participating in a community and also having other sets of responsibilities outside that community because of shared interests. But a couple of things I found were important to highlight. One is I would not see it as a central enforcement body of technology choices within your organization. If you had, let's say, a technical community within Java development within your company, they may be helping highlight what are good choices to be following, what's the best applicable things based off your other existing Java dependencies you may be using. The important point is that they may not have good influence of how to actually enforce things. You're focusing on the knowledge, like a central control area within your company. Therefore they're helping influence the knowledge and growing that within your space, but they would not necessarily be the ones that can guarantee how you enforce it centrally. Sometimes that can cause a challenge when they say, let's have the community of practice enforce this. It's more how you can get ideas of a community of practice: what's the best choice we should be following?

Another example of this too is around a team which takes on broad or highly coordinated development work. If you have a community of practice that spans your organization, using the Java example, you say, look, we now need to upgrade some Java library to some newer version based off a vulnerability. That could actually help by having a community of practice inform what you should be doing, what's the best choices, or what works best for their existing code base. However, they generally are a body around knowledge, not necessarily a task, because they're living longer around the knowledge you're trying to grow. They may be part of these activities, but that's not their focus. That's not their primary mission, just taking on a task and doing this. Try to view this that you're not trying to have this body of individuals that then are taking on tasks like this.

With this talk, we're talking about navigating changes. There are a lot of different changes that happen at a large organization. One area I think is important to highlight is organizational change. In any company, you're going to be making changes around the structure within there. You're also going to be making changes around technology, which can also influence organizational change, as well as around process change. How you're going to be using that technology may be changing, how you're trying to streamline or make things different over time. The important part around this is that there are lots of different types of change that come with it. There are a lot of things that are good about having change, but change can be difficult a lot of times because there are different impacts based off change, and that can be different on a local basis within a team, how they experience change versus what it's felt like or viewed globally with your organization. I think it's an important piece to highlight that you're trying to identify and understand that you are having a lot of different types of change happen in your company, and you want to get the perspective at both the local level and the global level of what should we be doing, how should we approach it, and what's the impact teams are experiencing with it.

With this, I felt like a lot of things, especially with COVID, where we became much more virtual or even isolated on working through problems, where we may not be engaging as much just almost accidentally by seeing someone in the office. You'd be talking about more things you might be facing or challenging, because many things are based off a meeting or a session that you're having. What we're trying to do is minimize how people may be feeling isolated with problems. By having a community and trying to make sure you're fostering that, you're saying, look, let's make sure we are that earlier definition of talking about trying to be very intentional about meeting regularly, about discussing these types of things. As change comes up, discuss it, try to rationalize how we're viewing it or how has it impacted us, and then look at how teams are adapting to it. The goal of this is that you're trying to find out really great ideas that many times almost get isolated within a team which could actually help a lot of other teams as well. They're going through the same challenge. This localized experience of the problem, they come up with a great localized solution, but that localized solution actually could be applied very well across our organization. How can you elevate, how can you externalize this to others and make sure it's brought up so that, again, you feel like you're getting better every day when you're dealing with some of these changes?

One of the things I've kind of always loved, a term I had a former colleague who used this often, is paper walls. You think about a paper wall: it's like a barrier that you may encounter within your organization. That barrier can seem like a real barrier, like you have to literally work around it or you can't change it. But when you start bringing others in across different areas to talk about problems, especially the different backgrounds of experiences, you soon find how some of these barriers are actually not that big of a challenge or a barrier to change because they've actually dealt with it before and made a change around it.

The whole point about detecting paper walls is that as you're talking about and rationalizing these challenges or differences through change, you may be identifying, oh, now it's going to be hard to change because of this, which is this paper wall. Then other people outside your teams that are part of this community can help identify, no, we've changed something like that before. That's actually something we've done; we've had experience with it. Help connect you with someone to actually work through it. It's again connecting knowledge, actually bringing a better solution. I like this thought of detecting paper walls. If you can help detect it, you actually change it much easier than what may feel like a larger and harder change to make with it.

Another one is around interfaces in a network. We'll talk about this a little bit when we get to communication topics, which hits on trying to actually communicate with your organization. In this very simplified organizational structure view, where you have different groups across there, you're trying to intentionally build an interface into other teams. With a community of practice, it really helps by having a point person into different types of product development areas that you may have, and they can help actually speak to some of the challenges that may be going on, or they're a very good router to people who would know what that experience is. By doing this intentional way of building this interface or a network across your organization really helps. One thing I think is important to highlight is that as you're going through it, looking at your community members, try to overlay that with your organizational structure. Look at, do you have a lot of people that are part of your organization or community only really from one organization, or are you getting a nice, good, diverse mix? That also helps in improving ideas and knowledge sharing as a result.

One thing I like to also call out is that I use this term, which is more of a knowledge network. Having this intentional way of connecting others across there, because you're doing this intentional reaching across different organizational boundaries, I think is a really important piece of this. As you can probably imagine, you get well-isolated ideas that may emerge or something that may come up in one area. If you're not intentionally trying to foster communication across these different groups, again, you may only get a localized solution to a problem, and you'd like to actually get that to be much better across your organization. You're trying to find ways to improve ideas that go across it. The other part around this is making sure you get those diverse perspectives. Looking at that knowledge network is important, and that's hitting on that point of trying to overlay your community with your organizational structure. Make sure you may be trying to recruit other people in different areas because you want to find out how are they applying this, what are they working through, what challenges they have, and is it different or is it the same?

An important piece around this I think is really highlighted in the book Team Topologies, around communication challenges and cognitive load. When you start having lots of change going on, often there are different forms of communication, and sometimes those forms of communication come out differently based off the source of the change or the group that's trying to communicate that change. That can be overwhelming to teams as you're going through different changes. You're trying to simplify what things are going on and actually rationalize it locally within the team. Something comes in, they may say, you know what, this is about this newer change, that Java dependency change we're looking at doing. However, that really isn't applicable to our group because we are doing something different. Therefore they can help simplify some of the noise coming into groups if you intentionally try to control that communication versus a broadcast method, as something like all team members get this notification, then they all look through it and try to understand it. You're trying to be pretty intentional and saying, how can we minimize cognitive load input channels coming into the team, and make sure those that get it can actually help simplify it and give a good local perspective on it to their teams as well? I think this is really important because as change comes on, that's a burden that comes onto teams as well as working through all the things that are going on already, as well as taking on change.

With that, when we talked earlier about that knowledge network connection up through there, there are two things I think are important. I usually just talk about these two different paths of communication with vertical and horizontal. What I've liked about this is that when you're trying to really help improve communication, you're also looking at when you share within this knowledge network, they can also help share things up through their organization too. They already have existing types of meetings with their product development group. Talking through it, they can say, here are some things that have been coming up in this community of practice, here are some important things I think are really of our group. They help advertise what those things are, but they're the ones seeding that information as part of an existing session with the teams. I think that's really helpful because it goes back to there are things that they want to highlight and things that they can say, you know what, that isn't that big of an issue coming into our area. With that vertical communication, make sure they're helping hit a different span of communication levels within their group, and again, they can bring that localized context.

Another thing goes back to the horizontal communication. This comes back to the point that I brought earlier around coming up with an idea in one group and it actually could really help a lot of others in different groups, but you have to intentionally try to make sure others are communicating these ideas. You get to talk through and you get to see what's going on as a result of it. If you don't, sometimes you miss out on what those could be happening. You're trying to look at the horizontal, and the point I brought earlier as well is making sure that your organizational structure, you're overlaying that with your community to find out, hey, do I have a good horizontal path of communication? Can I have an idea that comes up in one area that could feed to another really well as they talk through it, so that way you're not getting redundant things or approaches?

To that point, you're trying to also recognize Conway's Law, which really highlights how a lot of the things that we build in terms of software usually mimic the communication structures that we have. That pathway of communication a lot of times can result in when you have the same solution being solved in three different areas, because the three different areas had the agency of what they wanted to change or control and manage. You're trying to say, hey, how can we try to minimize how many times we have redundancies in the way we're trying to solve problems? Also, how can we make sure we're uniting our development, making sure they feel like they can share ideas across their space, knowing that not all areas are common? But it really can help by making sure you're intentional about it, because naturally you'll get where you have similar solutions that come up redundantly across your organization just because of those organizational boundaries.

Now we're going to hit a little bit more, moving from the communication side to some lessons learned. One of them is around meeting consistently. This might seem like a very obvious or simple point, but from years past, when I tried to manage other technical communities, an example could be around if you're trying the large Ruby ecosystem within your company or a Java community, you might say, look, we're going to meet every month to talk through topics. That could be really valuable, to say this is when we're going to meet and people can plan on when they want to share those ideas. However, if you start having a struggle where it takes too much time to help plan talks or get enough talks scheduled, you get to where you have an inconsistent schedule. Once it becomes inconsistent, that's when people start feeling that they don't really have a known time to share ideas. Therefore, they don't plan to share ideas. When you start making it a very reliable time period that you know you can support, it becomes a much more reliable time period where you connect people back up to expect to be meeting. Then, is it this week or this month we meet, or two more months we don't meet? Try to find an actual consistent schedule that works for you and stick to it, because I think that really has helped seeing communities grow, when they know there's this routine schedule we'll work through and what things are being shared.

Another thing around this is making it easy to follow. As you can probably imagine, with the community, you're trying to make sure it's really easy for everyone to participate in it. That's trying to highlight all the things we talk about, knowledge sharing or ideas or challenges or what things are trying to work through, towards very open. You're trying to use whatever within your company are good discussion forums or things you want to share with it, but you're trying to make sure it's easy for anyone to participate even if they don't feel like they're part of the community. Therefore, they just want to follow along or watch what may be occurring within there. You want to make sure it's very easy for them to do that.

The issue with it is that if you have a bunch of closed notes and you have to join some group to follow anything, it can make it harder. Anyone who wants to say, look, we already made this decision from this community; we'd like to make sure we just share it across all of our engineering groups. You want to make sure that it doesn't require people to say, well, I need to join something else just to follow along. Make sure it's easy. It's really important to say, how can you make a consistent way of capturing information like this, keeping it in an open forum, and making it digestible? That's one point I have on here where I called it the changelog. I love how changelogs help prepare you. When you look in a software release, you have an expectation of what you want to see in a changelog, which is what are some of the bug fixes within your features? Is there major change coming with this major release? You may be aware of it. It's a simple, concise way of a listing of changes, and you do not expect a lot of content, but in each one of those changes you may want to dig in further.

This is highlighting content roundup. I have found this to be really effective if you're trying to communicate things on this routine schedule. Every week you're trying to share, hey, what communities have met, what content has been shared? It helps people catch up if they missed out on something over a week. This changelog is a simple digest of changes that people can look through. It's not meant to have a lot of repeated content that you're already trying to build within your communities. It's trying to highlight it and make it easy. Again, it's easier for people to follow along because it's a lightweight reference point.

Another important part about this with a large organization is trying to foster small group discussions. I think this is really important because as you grow, it's difficult when you start getting larger groups meeting and you start minimizing who is speaking or sharing ideas, where you can also minimize what knowledge is being shared or getting newer ideas seeded within your groups. You try to look at ways of how you can make sure you have small groups still that can make it easy to discuss things. You may still have technical talks where someone shares something to a larger group and then there's a way for feedback. But you may also look at having what I like to call a breakout session, where you intentionally have a list of topics, you make sure people can elect into those topics of interest, so they say, oh, I'd like to be in this small group discussion. You have some type of time dedicated to break out in these sessions and have small group discussions to get a lot of feedback. You point people in each one of those groups to take notes and ideas and try to walk through the topic at hand. Then when they come back, you try to share the ideas and what was discussed with the larger group.

This is really helpful once you start scaling with a large organization. You're trying to make still sure that you're getting these really unique or good points or ideas shared from that localized context. You do not want to have it where it's only the same group of people sharing ideas. You're trying to make sure you're getting others to share ideas along the way. Think about how you can have breakout sessions or something like that to achieve that.

The other part on this is really celebrating the efforts. I think this is an important one where you can highlight how important it is to your organization to have these. What I found as a very simple way of doing it is saying, I really value having these things in our organization. When someone gives and joins a community or shares a talk on something which requires doing some upfront work or planning around it, you want to make sure you're highlighting that back to their managers or other parts in their existing organization. One thing I always tell people is write a thank you email and then highlight why it was very valuable, why they shared this topic in this community, what did people value from it. It also helps people whose manager may not know they've joined this session to talk on it. It also highlights these individual contributor efforts that you want to make sure are obvious or coming up and you really appreciate, because that is also a means of helping foster and grow it within your organizations.

We're hitting now on the summary. We talked on several things that felt pretty quick. One was around communication flows. When we start talking about community of practice, I think it's really good to look at these different horizontal and vertical communication pathways. You want to make sure you're optimizing things that are occurring, both enabling horizontal communication, making sure people are talking across organizational boundaries, but also optimizing vertical communication, which can be how they filter or make it a little bit easier to understand about a bigger change: what does it mean within their group?

Another part around this is making sure it's very easy for anyone to follow along without naturally building barriers to content or communities, because what you're trying to do is have a lot of organic growth. It's hard for that to occur if you put, we have to join this group, or only those who've been allowed to join can actually follow along. You want to make sure it's very easy for other people to follow. That's how you get more ideas and more things shared, and the more you can actually make it digestible for people to follow, the better it works.

The other part around it is realizing there's a continual need of managing energy and keeping a community going. If you're trying to manage a routine time to meet, you might say, what kind of topics do we have to cover? Who should be part of those groups? Who should be giving a talk on this? It takes effort. While in my past a lot of times this can come up from a grassroots effort within your company, you want to recognize it takes time to do that. You want to make sure you have point people who can help drive it, and you recognize it. That point at the end here is really highlighting and thanking them for it because this kind of responsibility that you'll have team members take on to do this adds a lot of value. We start getting better ideas that come out of your organization as a result.

All right, so that is my talk. I hope you enjoyed this and learning about navigating change with communities of practice. Thanks for joining.