Using service design tools to facilitate communities of practice

Ronan (00:06):

You can’t force a community of practice. You can only just set up the environment that you have. You can sort of plow the field, you water everything down, but you can’t be sure what’s gonna grow. So, there’s that philosophy and then there’s this question of do you try and force a particular community? You say okay, look, we know that test automation is important for us. We have to have a community about test automation. How do I force that issue? And that’s another slightly different topic we’d have to think about, whether companies can force a particular community onto its own members.

Lauri (00:44):

Hello and welcome to DevOps Sauna. A community of practice, or practice community is a group of people who share a concern or passion for something they do and learn how to do it better as they interact regularly. Many companies have embraced communities of practice one way or another. But unfortunately, not all of them thrive. Why is that the case? And what could help companies instill practice communities better in their culture? We invited Ronan Mac Laverty from Varian. Ronan is a director in platform development. And in his recent MBA thesis, he investigated how service-designed tools can be used to facilitate communities of practice in software development organizations. Ronan is joined by Tuomas Leppilampi, who is a digital transformer and a DevOps team lead at Eficode.

Lauri (01:38):

I’m happy to have you in the DevOps Sauna podcast Ronan and Tuomas, welcome!

Ronan (01:44):

Thank you.

Tuomas (01:45):

Thank you.

Lauri (01:46):

Glad to have you here. Oftentimes we have discussed about tools. We have discussed a little bit about processes like test automation or continuous quality assurance. I feel today, we are discussing more about culture, shall I say. So talking about a community of practice. And with us we have Ronan who has written a thesis that goes with the title “Using Service-Designed Tools To Facilitate Communities of Practice in Software Development Organizations”. And we have Tuomas who is a team lead at Eficode, who has been basically setting up our communities of practice and leading a sort of meta-project of communities of practice at Eficode, and also has extensive visibility into communities of practices in other organizations. So, before we go to our first question, maybe just a word for a listener. What is a community of practice or practice community? And I’m shamelessly quoting Wikipedia here. It’s a group of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly. And I was surprised at how new this term was, only from 1991 and then expanded in 1998. So, not that old of a concept. How do you see the state of nation with practice communities? And what’s the adoption, what are the outcomes, what are the challenges?

Ronan (03:07):

So, I mean, it’s a very interesting topic about the state of nation, and it’s a very difficult one to capture because the definition of the community of practice, as you already pointed out, it’s rather fluid. And one of the problems that we would have is you take two concepts, like community and practice together, and people intuitively know what it means. But, it’s a very technical term in the area of, let’s say, organizational design and things like that. So, it’s very difficult to capture a state of the art of a community of practice. I can speak from my own experience about the fact that I’ve been involved in multiple software development organizations. And it varies from place to place, so I can’t really. Maybe I’m gonna kick this over to Tuomas who might have a bit more experience of multiple organizations, as my thesis was mainly focused on my organization as opposed to others. 

Tuomas (03:57):

Yeah, actually, I’d also like to widen the scope of this answer to not just practice communities or communities of practice within IT or within R&D, and companies, organizations like that. But I also what I do is I work with communities outside of this kind of, a bit of purely cultural area, and arts and music and these kinds of things. And I’d like to think that the practice communities are a bit the same in that there as well. What I’ve noticed is that the digitalization leap that we have, and have had in the last couple years have had a significant impact on the state of the nation in practice communities. We actually in Eficode, we started our practice communities on February 2020, and this was just before the pandemic started in practice and it’s been very interesting how it’s impacted the practice community’s activities in the work world. Because in work, it’s easy to be remote. But, when it comes to art and music and culture and these kind of things, there’s been a drastic change in the way that in the past, you know, very few people did large events for a lot of people. And now, it’s gone to thirty people doing events and activities for a hundred people. So, I’m really taking a lot of examples to my practice community work in the company, in the corporation from my cultural area. So, yeah, we’ve gone remote very quickly. And I guess that really defines a lot of the practice community state of the nation from my point of view.

Ronan (05:45):

It’s actually interesting that you state this because when you talk about the fact that look outside the work for your communities. I mean external sources of community are actually a good example, if you talk about a sports club or any sort of club you have. You notice that, for example, there are some certain inherent weaknesses if you have a whole entire club that hangs on one person. Then, for example that person gets sick or leaves the area, then the club essentially dies. So, you know that to have a sustainable club you have to have three or four leaders or potential leaders who are gonna participate in it. And then the other thing that you also find that is also quite similar is the fact that there’s different levels of participation. There’re those core members that form the hub of the actual area, and then you got an increasing level of participation, or decreasing levels of participation to those that are fringes. So, people who just pop in every so often and are on the bench watching, like more spectators than actual active participants.

Ronan (06:39):

And that’s actually a very good thing, that’s a very good model of what a community of practice can be inside an organization. And then when you think about, again about, you talked about this, digitalization has changed how these communities work and the different ways of organizing and everything else like that has an impact. My work has been, I mainly worked on the face-to-face action because I love my work on the communities of practice before Covid, and then I focused on one particular side of the company rather than a larger company so... These larger communities will probably be interesting. They used to say something around, once you get to number fifty then it starts to splinter into sub-communities. But I don’t know how that will work in the virtual world where we used to be part of large virtual teams. It’s an interesting one. 

Lauri (07:24):

What distinguishes a community of practice from a select channel where people join and they just exchange the ideas and initiatives concretely. For instance, we have a blogging channel with maybe a hundred people. And invariably people come in and basically share drafts of the blogs that they have written, like these are subject matter experts. Say: “Here’s a blog I’ve written!” Then marketing team members will take initiative to polish it off and create illustrations and make it published and everything else. And maybe, in some respect, it is a community of practice.  Then, the community is “how do distill and distribute valuable information to people out there. Like, how do you distinguish a random bunch of people with shared interests, and community of practice?

Ronan (08:11):

That’s actually a very good one because there’s this thought that communities are, for example when Wenger wrote his book “Communities of Practice”, he actually talked about a community of practice that happened by itself. So quite often communities actually self-emerge from the actual social interactions of people. So, for example, if we all work in the same office, we’ll have a community around that office that might actually develop and refine what we actually do and how we behave and how we improve our skills and how we improve how the office functions. But generally, the way it works, when you look for a community of practice you look for three different things. You’re looking for mutual engagement, which means there’s constant interaction between people. Then you also want to have a joint enterprise, which means you always achieve to have a common goal. And then the last thing you need to have is a common repertoire of terms. So, we can actually communicate to each other in this sort of three different things. If you’re missing one of those things you don’t really have a community of practice. There was a very interesting article that sort of like tried to sum it up in that this is very close to what you just described: is that the key aspect of a community of practice is that you have to think together.

Ronan (09:13):

And then there’s a very interesting paper which is even called thinking together is a key element of a community of practice which is done by some researchers I think in the University of Strathclyde. And that’s a very good model that you’re mutually working on a common problem or common practice or common area or common domain to make your life better and everybody else’s lives better. One common thing is that the same practitioners in this case you might actually say that the core group would be the marketing and the communication people and the actual people that would be on the fringes would be the participants. The hard part about this is how to get this regular mutual engagement, that's the hard part. I mean you're going to have a lot of people that will be passive, so how do you get that mutual engagement in there? That's always going to be a problem. 

Tuomas (09:55):

Yeah, it's a good point also from my point of view thinking about starting these communities of practice in February 2020 and first off the way we did it is we, fifteen or twenty of us got together in the Copenhagen University in a big room and all of those people were the to be leaders of these communities. And the idea was that we want to understand what are the areas that are relevant for us? What are we going to start with? There would be an IT world, you know, you have cloud and you have continuous delivery and QA and these kinds of things, but also about culture. You know we didn't want to forget culture. Okay, so now we have that list, now we have that list of things and what we decided to do, we decided to try out with quite a few of those different topics and see how they fly. If they get this try out, if we are to land into channels and pages and output when we are thinking together and putting something out and some of those didn't fly, some of them just didn't fly and we decided that we were maybe to disband them or maybe we would just let them be there to wait until they surface up again, I don't know. It's actually a negative thing to leave these kind of dormant things. If a practice community doesn't fly then how do we go from there? 

Ronan (11:32):

I think the other point about this is a bit like, so, I mean, I've come with these problems, I mean, some practices, some communities will die. I mean, that's the way it works. I mean, some of them will stay in a dormant phase for many different types. I mean, I think there's some very nice work done by researchers IBM, where they have like five different levels of let's say service maturity, and even Wagner himself and his book Cultivating Communities of Practice talks about five different levels of community. And of what, point is at one point, like it can die at the end, but sometimes they just never get off the ground. Sometimes they get off the ground and then die and then they just have to be relaunched. So I think, I can't remember whereabouts in the literature, but it talked about using a relaunch event for a community that's like stalled. So it is quite possible to do that.

Ronan (12:15):

It's interesting that you talked about the challenges and culture, because one of the things that you can see is that, and I think there was one interesting situation where they had challenges of creating a community of practice that was in Canada, which said that you got a very bureaucratic or top down organization where the culture is, "I do what my boss tells me to do." Then it's very difficult for communities of practice to fly in that type of world. And this is the problem. You have the situation where you have like the waterfall culture coming with agile culture and the waterfall culture, you got a very sort like strict sort of like role-based way of doing things, and in the agile culture, that's sort of like gets blown apart. And I think that's one of the challenges if you're making a transition from like say a strong waterfall organization process driven into a, let's say agile world, then you're gonna have that challenge where you expect people to have a bureaucracy and they expect, we have leaders.

Ronan (13:03):

We don't have communities of practice as such, we have virtual teams. And I think this idea of voluntary participation and making sure you get the time to do that, that's the sort of issue that you would find. And when you bring this into the situation that you have, when you talk about areas like cloud development, which is something very interesting, people would be passionate about, that might work in some organizations, but in other organizations, you might be better to talk about it. I've just put all my cloud developers into one virtual community of practice. And you tie the actual community to a specific role already existing inside the organization, because then you can build on existing social networks, which helps the community form faster and that might help alignments because that's what I found in Varian, that we had some communities that started off and then died. And they were the ones that were more like divergent or more innovative in comparison to the waterfall culture, but they had one community that succeeded quite well. And the reason why I could see was the fact that the people involved already had an existing social network because they were part of a testing team that got that split into agile teams. And because they already had the social connection and they sort of got together as a role-based approach to doing things, it worked quite well.

Tuomas (14:13):

It's very interesting that you say that sometimes in the waterfall or kind of top-down led organizations, it's very different, you know, from a cultural standpoint, creating these practice communities might lead into a situation where the expectations, so to say, the key performance indicators of whether a practice community is working or not can boil down to what kind of business objects or artifacts they produce. Whereas a lot of-- because we are at Eficode, we are pretty much a born-agile company. I mean, we live and breathe that thing. Of course, we need to deal with legacy and waterfall and kind of hierarchical organizational structures every day in our life when we are, you know, working with big banks or so. But when we are actually creating something internally, it's quite interesting how some of the people were expecting something to be produced all the time for us to be successful, so to say, whereas the community themselves thought, if we go into that way, then we are no longer a community of practice, but we are more of, as you said, a virtual team or something that has a, you know, responsibility to produce something. And that was the kind of conundrum we had there, you know. Are we a practice community if we produce something, so?

Ronan (15:37):

I mean, that was one of the things when I sort of like analyzed what-- I actually did sort of like some research on my organization, I analyzed under sort like three sort of like problems that we came across. One was the fact that the nature of a community of practice people had a very fuzzy idea of what it was, then the other one was this alignment of expectations. So if you've got a hierarchical sort of like efficiency driven organization, as opposed to effectiveness, then you're trying to maximize your output. Then you say to your developer, why spend half a day on a community of practice? You should be doing code or you should be doing testing or you should be doing something. And then they see communities of practices as: I see this as a training area where I send my person, he goes to community of practice, he gets his skills, he comes back, and then I use him as to help efficiency. So it's more like a training sort of team, right?

Ronan (16:23):

That's one sort of issue. And then the other one is because you have that, then you sort of like changes the working model of how a community works. So you generally have it very top-done, driven, it's got a leader, you've got a team, and it's driven in that perspective. And then it breaks the idea that communities are supposed to be, how you say, a bit fuzzy because if you can define what a community does, you probably need to set up a team for it. I mean, you'd rather be better to set up a team than to actually have a community. A community is supposed to be fuzzy because if you knew what it was gonna generate, then what's the point. I mean, you've already got the requirements, you've always followed the own tower waterfall process at the end. The fact is you don't know what it's gonna generate because you don't know what they're gonna find or how they're gonna evolve. And that's where the surprise comes, and that's where the innovation comes in. And that's the hard part about this one. And this is where I talked about this concept of knowledge generating companies, which was quite popular in the nineties, is that communities can be a very key part of generating knowledge, especially since it goes to the cycle from tacit to explicit and tacit to explicit, and communities are a place where tacit knowledge can really be shared. So that I think is also interesting point that we would have here. Because the unwritten tacit part of it is something that we had; it's difficult to capture and this is also ties into how you do your knowledge management strategy.

Ronan (17:39):

But I mean, this also ties into this question like for example, when you talked about working in hierarchical organizations, when you talk about this reification or making these abstract concepts concrete, that's an example where you could actually go to a hierarchical organization, say my community generated thousand pages of documentation or guidelines for my developers and stuff like that, then you could use that as a metric, but this is just one technique of capturing what a knowledge of what a community does. And the thing about reification is also allows communities to share documents between each other. They act as boundary objects, which also allows sort of another way of community interaction, the other one being people. But that's another point.

Tuomas (18:18):

Yeah, the idea really for me, has always been that the practice community should-- the most concrete things it should do by nature is to define terminology and define the playground where we play, not so much the output, not so much the rules of the game, but really the playground. And the rules are maybe the, as you said, something that comes from the tacit kind of discussion and banter. And then what we did is once we got too serious, once the play got too serious in a practice community, we started calling that the working group. So that went for a working group, and then we produced some output through the working group, not to confuse these two activities. But now, we have a new challenge. Now we see over time when the practice communities have, in these last couple of years, have they lost their kind of the new value, the value of, okay, it's something new, something fun. Then it becomes somewhat of a commodity in the company. Now, I see some dwindling down because I don't know, the discussion maybe has gone somewhere else or we should inject somewhat of an activity, you know, to keep them alive. I don't know. We're in a kind of a turning point at the moment. That's quite challenging.

Ronan (19:42):

It's interesting because I mean, one of the things that you talk about is the fact that you can merge and divide and split. But I mean, if you think about going back to one of the very early works in communities of practice, by Wagner and Love, they talked about one of the key things about a community is a community has to regenerate itself. So kind of this constant sense of renewal and that brings in a certain constant sense of evolution. So the thing here is to try to get a constant flow of new members going in and older members essentially moving out. So you have to have that constant sense of renewal as part of so like a community life cycle if you have. It's good to have some old-timers there that keep everything, but they have to give space for other people to move in. And I mean, I think that's the other thing that can be used is that that's one of the key things that you have to drive. And that's got to do with this working model as a topic of what a community should be. You should have this constant attraction of new people. And I think hunting down new people to bring them in.

Ronan (20:39):

And so like having work, how to increase their levels of engagement slowly. So they come from the periphery into the core group and then maybe dance in and out of the core group for a while, and then maybe leave the core group and go back to this constant sense of renewal and then try to get people to work with multiple different communities, because then they might play off one another and sort of like generate, this worked well for that community that worked well for that community and even have joint community meetings. I think that was one of the things that we find.

Tuomas (21:06):

Our joint community meetings. That's very interesting. We haven't really tried that and I think the separation that we did in the very first meeting. I'm thinking it was a bit too granular. We should have done something wider. Some the focus should have been something wider and then let those things become smaller over time rather than the other way around, because it's hard to bring those together, to be honest.

Ronan (21:33):

Yeah. So, I mean, I think that's probably one of the challenges of the community is trying to work out how broad and how narrow it is. If it's too narrow, then you might have this problem is that it becomes constraind. If it's too broad, then it's too nebulous and people can't identify with the community itself and there's no sense of community at all. But one of the things that we did see is that for example, Varian being a medical company, we have a very strong regulatory aspect to our work. And what they did is this community just brought in some people from that sort of, it was actually that business unit, which in a way it's its own sort of like separate community, pulled that into the testing group so they could see how testing and regulatory interact and that could spawn an area of innovation and ideas of how to go further than that one. So there was that one.

Lauri (22:17):

Did that happen between the organizers of the practices or did that happen between the members and core group of the practices?

Ronan (22:25):

So in this case, it was just a suggestion from the core group. I mean the core group are the people that do a lot of the legwork and networking. So I mean, I think that's one of the things about communities of practice is people say, okay, we're gonna block an hour on Wednesdays and everything's gonna turn up on Wednesday and we have a community of practice. That's not how it works. There has to be a significant amount of what are you gonna present? What are you gonna talk about? Who's gonna capture this information, how you're gonna store this, how do you progress and how do you sort of like evolve as a community as well? And that generally falls down to three or four people, ideally. I mean, quite commonly it's one person. And they're the one who spends all their time networking between the different members of the community and trying to attract more members to that community.

Ronan (23:07):

And I mean, that's part of the, how do you say it? Again, this working model topic about how you sort of like-- who organizes the events, who makes sure that there's a regular Wednesday meeting who fills in the gap when one person can't do it, this is the sort of topic that you'd have to think about, so that goes in there. In this case, it was like the idea that somebody thought it was a good idea to bring these people in, set it up, did it, and then they had a really fruitful discussion so that the community can see what we are working on has impact to some other parts of the business. And if they structure their work differently, it makes somebody else's work easier. And that's one of these things where a community can actually help develop such a broader perspective for a particular group.

Tuomas (23:50):

That's very interesting, this kind of output of what is considered useful, what is considered beneficial for the company. I think it also kind of very much boils down into the situation where the company is. Like, for our company, for an example, we are, I guess, as a consultancy company it's always in a state of productizing its services, kind of renewing the idea of what is productized services. So that's really a kind of a very natural outcome for some of our practice communitie's work to productize the services. Not so much come up with best practices lists or, you know, which tools do we like the best or, you know, retros and learning and these kind of things. But it slides down into the productization work, which I think is quite-- it's kind of killing the other stuff. And I'm trying to kind of push this productization work out or getting it ready to a certain degree so we could concentrate back on those best practices and these things. Which again, from the company point of view, I don't think some people in the, so to say, top, well, you can talk more about that as being one of the C-level in a company, but considered as useful as beneficial for the company as these productized services. So that's a challenge for us as well.

Ronan (25:11):

It is a challenge. I mean, if you look at this, what is your knowledge management strategy? I think that's a question for a Harvard business review article. And they said there's basically two versions, there's qualification and then there's personalization. And that actually is very closely aligned with communities of practice. Communities of practice are very sort of like this social interaction, which is this mutual interaction. Part of it, which is very much a personalization strategy. And then you got the qualification, which is reification part of it. Now, no strategy, knowledge management strategy is a hundred percent personalization or a hundred percent codification, but when personalization's all about knowing who to talk to, whereas codification is all everything's written down. So there's always this gonna be this two different approaches. One of them is very good.

Ronan (25:55):

I think the example they had in the business review article was something along the lines of, you've got a professional services company where you actually sell highly personalized and highly sort of like services versus let's say, I think it was an Arthur Andersen company or something like that that was basically, we have a certain sort of projects, we have certain methods of doing things, you go through the binder and you go bam, bam, bam, bam, bam, that's it. So your codification's a high repetitive services type of thing that goes very much towards a codification strategy. So you probably have to have this balance between work out which ones which, so. It's difficult, but I always thought that community practice are very close to then it's like social learning where you model other people's behaviors. So you have the junior testers modeling the senior testers in order to get ahead.

Ronan (26:38):

These are the skills you have to have. So there's a nice touch there about that one, but it's a very, very personal thing, which is nice for agile because agile was the first line, it was the agile manifesto interaction and over processing tools. I mean, this is how it is, you have to constantly talk to people.

Tuomas (26:56):

Yeah, individuals and interactions, yeah.

Ronan (26:59):

Exactly over. And I think that I think is very close to the community of I'd say practice model, as opposed to write everything down, you have to have a work instruction, you have to have a procedure, there has to be a process, it has to be documented, you all have to be trained on it, and you have to be signed off on that training. So that's very much a different approach.

Lauri (27:22):

It's Lauri again. We earlier published a DevOps trends report where community building came up as one of the trends in the DevOps world. Sometime ago, Marc Dillon and Kalle Mäkelä made a retrospective on this report we produced where they elaborate on community building and much more. I'll leave a link to both the DevOps trends report, as well as the podcast episode in the show notes. Now let's get back to our show.

Lauri (27:51):

In one period of my life, I managed to participate in Toastmasters speaking club for like two or three years, and now when I listen to your conversation, I realized that the way how Toastmasters clubs are organized are very much like community of practices in the sense that it's the umbrella organization who provides them the workbook, who provides them the portal, who provides them the agenda, who provides them with the roles for each meeting. Like basically the infrastructure of making it as easy as possible to come together every two weeks to practice talking, it has been made ridiculously easy, but then what happens in every meeting is like: we shall see, because every time, the chairman is a different person and the person who keeps time is different and the topics are different, and the table topics may take a different turn this time than last time. But everyone walks away enlightened and informed and have learned something. Although in that Toastmasters meeting itself, there was no real concrete artifacts produced.

Tuomas (29:07):

I think that the topics, at least from again, coming from Eficode point of view, which is like, I guess quite a wide point of view, because we do have aside from all these cloud and technical parts and all that, we also have researchers and designers and people who are really looking at human behaviour beyond the technical solutions that we provide. And my number one activity at the moment is to bring those people together who have historically been very far apart, to be honest. We really had organizational structure in place that made it even easier for people to be very, and feel very, very far apart from each other. So currently what we're wanting to do or what I'm actually wanting to as a facilitator is to bring service design and continuous delivery of software services closer together because there's an infinite amount of things that we could learn from each other. And we are in the first steps of that. We are still running parallel. Some moments in the months in the future I'm gonna cross those wires and see what's gonna happen.

Ronan (30:18):

Yeah, it's actually interesting because, I mean, when you talked about the Toastmasters, I mean, when you talked about communities of practices, generally, most people are participating in a community of practice, be it a sports club, a music club, a social club, or something like that. So they generally have some type of model that they could build on as an example of how to go forward. And then you talked about Toastmasters being sort of like an umbrella organization. And the one thing that you emphasize is the fact that the umbrella organization makes it easy for a Toastmaster event to pop up. They facilitate it and they make space for it. And I think that was one of the original ideas behind communities of practices. You can't force a community of practice, you can only just set up the environment that you have. So you like sort of what you would say is you'd plow the field, you'd water everything down, but you can't be sure what's gonna grow.

Ronan (31:06):

So there is that philosophy, and then there's this question of, do you try to force a particular community say, okay, look, we know that test automation is important for us, we have to have a community about test automation. How do I force that issue? And that's another slightly different topic. We'd have to think about whether companies can force a particular community onto its own members, or should they have it so there's a sort of like, how would you say again, this fuzziness and this, like, there's a spectrum of top down versus bottom up versus homegrown versus directed. And I mean, those are all interesting issues as to where's the sweet spot in any particular organization as to what you can and cannot do.

Tuomas (31:52):

Could it be so that if you are missing an area in your organization, then if you start creating communities of practice, those are starting to kind of want to, or move to cover that area. Like we are, I feel that we are in Eficode, kind of not missing, but, product management in a consultancy company is not very clear. So when it's not that clear, then when we spin up communities of practice, they start to take that organization's place. I don't know, it's just an idea that occurred to me just now.

Ronan (32:31):

I mean generally, if people are very goal-driven, they will fill in the gaps. And one of the ways to fill in the gaps is to share knowledge with the community, if they can find enough people to network with, because you need to have that mutual engagement in order to make sure that they can all link up. So one of, I think one of the first parts, I think in the models of maturity of communities practice is identifying the users. And I think from the perspective of software developers, I mean, of all the tools that we have, I mean, as agile software developmers, we have a lot of things like for example, personas and user stories and things like that. And as part of my MBA thesis, I talked about what sort of software tools we could use, at least one software tool that we could use to capture these needs would be to user stories.

Ronan (33:17):

I mean, as a member of the community, I do this so that I can do something else. And if you write a user story from the perspective of a community member and then of a company, as a member of the, let's say a management of the company, I get this from the community, then you can sort of like try to define the interest parts for the community. And by building on those stories, you can sort like try to capture what the shape of the community's gonna be, and then decide whether it's got critical mass or not to actually go forward with a next stage, which would be probably to come up with a more elaborate way of expressing the value or creating what I described as a community pitch, which is another service design tool that's quite common and that everybody knows how to do the elevator pitch. But it's the same sort of thing is that I wanted as a member of the community, I get this so that I can do something else.

Ronan (34:02):

You just create a community pitch so that when you recruit you have something ready-made. So this is the sort of thing you have. And then, well, well, since I've gone on the topic of service design tools, another one I can talk about is the service blueprint, which is like a way of how to capture, let's say, community member's journey going from I'm on the edge of the community and I get certain things and then I become a core member of the community, and then maybe even to the point where I actually start to step back and let other people come in. And you can work out what sort of processes people behind the scenes have to do? What does the core group have to do? What other people are expected and what you can even expect from the company? I mean, that would be another way to crystallize those things. And if you build a few of those things, then you end up with something you can work with and it covers so the three issues of: you understand what the community nature is, you'd understand what the alignment would be with individual interests and community company interests, and then you'd have like a working model of how people should transfer through the community.

Tuomas (35:01):

So essentially, you'd be using service design tools and kind of agile tools, such as user stories and so on to improve the communities in a way or to work with the communities.

Ronan (35:12):

Yeah. I mean, there's two ways of looking at it. One is that you have facilitators that facilitate the construction, the communities, the other one is you give tools to the community to organize things themselves to help them create the communities and the idea behind my thesis, so to use service design tools for community organizers. If they already know how to use the tools, then they're halfway there. It's basically using what I said before is like, for example, Toastmasters would give a set of tools of how to organize regular events, and then you say, okay, well, I've got the Toastmasters model, I just start replicating it with my, instead of calling it a Toastmaster, it's DevOps and or something like that, then you just choose the topic and then you still have the same tools in your specific roles in every meeting you'd have this like rotating like topics and whatever.

Ronan (36:01):

So you'd have to do this one. And then of, course, you'd have to have recruitment drives and things like that, but you'd have a whole of that model of how this would work. And then your metal model should be sort of, and the tools that you used to be familiar to you, if you can. I mean, if you've got familiar tools, then you should use them. So, one example would be that if you've got a community and you're trying to capture what the community's generating, create a backlog. I mean, just track everything with backlogs. And then, well, a software developer, we all know what a backlog looks like, we all know what a software backlog would be, and they say, I'm gonna have a backlog for my meetings. And next week's meeting is this item and this item and this item, we think this item is important and the core group could possibly work on these high priority items and report back to the community.

Ronan (36:41):

This is what we think is important, what do you as a community prioritize? So, I mean, this is the one thing that you can have when you talk about communities of practice in any organization is you should try to reuse the tools because you're gonna do it anyway, either explicitly or implicitly. So, I mean, the classic example I talk about in a, let's say a hierarchical culture of an organization, it's very common to have leader team model for everything that you do. There has to be a leader and has to be a team. And that's the model that people have and that's the model that people use instinctively. When they do a community, they say we have a community leader, we have a team. And then you sort of say, that's when you shouldn't break if you want to have a core group of multiple leaders, and then you have the team. That's the sort of thing you have. So you have to define the model in order to break it.

Tuomas (37:27):

Yeah, exactly. And then this was the leading, leading idea when we started this activity is that there should be at least two leaders for every practice community, because we didn't want to go, you know, get into the situation where there was a bottleneck of somebody landing a hundred percent hardcore customer project, and then because in a consultancy, well, I mean we're at work, right? So sometimes the customer projects does take over and the biggest challenge for us was to have, you know, who's gonna lead if the leaders are not there. And people did not feel like they could make decisions and take over while the leaders were gone. So empowering people to do decisions and take things forward has always been a challenge. But I think, you know, the way we are going, you know, going to do it in the future is to really start to understand this kind of, I think the backlog was nice. You can just grab anything from there and start working on that without anybody giving you a permission or some kind of a kickoff or anything.

Ronan (38:35):

There is that, I think, then the leadership comes more in terms in term of backlog grooming. But I mean, the fundamental question with that if you're struggling to find members of people that are passionate about a topic, you probably shouldn't have a community practice in the first place. If you're struggling to find people who are interested to drive this forward, then it's probably not the topic that you'd to want have.

Tuomas (38:56):

But then we go back to what you said earlier about when is it okay for the company or for the kind of top management to push on a certain practice community? Like for us, it will be a cloud, you know. We need to understand more about cloud every day and it changes every day. So it's a perfect area for us, for a practice community. But sometimes it's very hard to find people to drive it because maybe it's a lack of clarity on the goals and mission of the practice community so that people have a hard time taking the helm because they don't know where they're steering. It should be more clear to, I don't know, maybe.

Ronan (39:34):

So, I think this goes back to the user story as a member of the community, what do I get from the community? As a company, what am I gonna get from the community? There's always gonna be those two stakeholders, the members, and the company that organizes, that's a host to the community. They're gonna have two different things and they're gonna have different needs and different tribes. So, I mean, the hard part for this one is this expectation. I mean, if you're, let's say you're an individual and you're part of a community, but your manager sort of says, I expect you to go there, learn what you need to learn, bring it back to the team, and stop. Now that's where the expectations of the management and the expectations of the community members might be different. If you go there, I expect you to go there and discuss, and learn and develop and clarify these different techniques and learn from each other rather than, like, learn as an individual, then that's a different thing. So your expectations of the individual-- like if you expect that I go there and I'm just gonna be a passive person, somebody reads the meetings, and then I walk away every Wednesday, that's passive participation. You're not even thinking together. You're more like just sitting, I sit there and listen to somebody else thinking. Well, right, as common sort of interaction and mutual engagement on a particular venture. That's the trick you have.

Tuomas (40:48):

So yeah, I guess it's also to when some practice communities have very charismatic leaders, it's difficult to race to that level of you know, gift of gab or something like that, you know, to really kind of structure your thoughts in such a way. Whereas I think there should be a level of psychological safety in the practice communities where you can just try out ideas and try out your voice without being embarrassed.

Ronan (41:19):

But that would be, how would you describe it? That psychological safety is probably one of the reasons why they sort of say that the community hierarchy is a separate hierarchy than corporate hierarchy. So for example, if I was attending a community of practice related to testing, I'd be probably the most junior member of the team, even though inside the organization, I might be quite high up. Whereas for example, the person who's at the lowest level of the team might be the expert on the robot framework that no one else knows about, he is the guy. And there's this, you can invert the, how would I say, the organizational hierarchies and not supposed to be a key role. The other part of it that never really comes out an awful lot, but I mean, if you're a manager and you're trying to develop leadership skills, I mean, you've got two choices.

Ronan (42:03):

I mean, the company can take a bet on a person and make them a leader, or they can have organized community of practice and see who actually has natural leadership skills. And they can actually use this place that I prioritize backlogs, I organize work, I take ownership, I have agency, I'm proactive. And then you be able to say, okay, who are the people that are involved in these communities and how are they behaving? And then you say, well, these guys are obviously the leaders of the future, and this is one way for actually spotting them earlier. But that's another human resource development. That's a sort of a side effect of the community of practice and not necessarily a key thing.

Tuomas (42:38):

Yeah, there's an endless amount of possibilities the way I see it. And sometimes, you know, on Friday afternoon, Friday evenings, we sit in the office with some guys and we just talk about the capabilities of what practice communities could give us. And something that always comes up is the engagement time, you know, how can I find more time to engage? Because if I don't, I just rather not do it at all. So, how do you see it, Ronan, should we really actually allocate time? You know, should we actually earmark some time and budget for this activity so that we can really get them off the ground? Or is that detrimental in some way?

Ronan (43:25):

No, it's not detrimental at all, but I think it's got to do with the expectations of managers. So, again, if you're in this world where you're trying to drive everything to a hundred percent resource efficiency, then you're probably not gonna head that direction. But I mean, the point about this is you are looking for a place where these people can socially interact and learn from each other and develop other things, then I think that's a, a different story. It's interesting because when I first started communities of practice, the first thing I said is that people have to allocate certain amount of time. But again, I think this is probably a situation where the managers would have to negotiate about what the purpose of the community is and what the role is in development of their individuals and things like that. So, but for example, this mutual engagement and how frequently the actual events occur.

Ronan (44:09):

I mean, it doesn't have to be on a weekly basis. It could be on a monthly basis, biweekly basis, it could be one hour or whatever, you could choose a different levels of participation, depending on how much bandwidth you do actually have for that particular community. And then if it becomes a very, very hot topic, a more important topic, then you can start trying to do an internal evangelism with your own manager, saying this is important because of X, Y and Z. Ideally, yes, it should be sort of like pre-negotiated with your managers, that you should have a certain amount of time for personal development. And I mean, I don't know how people have been doing it in other companies, but some companies have their sort of Friday afternoons are just for you and personal development. You can go off and do whatever course you want and we'll support you, and you allocate that time. And whether that time is spent in a community of practice or watching some, let's say, Azure training videos online, it's up to you. And then of course, the community of practice is the job to sell itself to potential members and hopefully try and drive them to participate more and more and get deeper into the community because of its importance for them.

Lauri (45:15):

Yeah, maybe from a manager's perspective, the question is which one is easier and which one is more rewarding for everybody in the game, increase the utilization of an individual consultant in the case of serving our customers by 10 percentage points or helping them develop themselves to a point where they can deliver value to the company by 10%, more than before. If you are in the game of the former, then maybe community of practice isn't a good thing. If you're a game of the latter where we want to help our people thrive, we want to help our people to become better, collect better more wisdom, create more value for the customers, so the customers are willing to pay more in exchange of more value, then I believe community of practice is a marvelous thing.

Tuomas (46:00):

I think it also boils down to what type of company you are in terms of, I don't wanna say maturity, but I guess from the experience level of people, I think it's easier to form communities of practice with people who have a long track record in a lot of, you know, the work that we do, but when people are younger and they're still searching their voice and searching their place in the hierarchical structure, that's more difficult to start another line of self-identification in these communities of practice. Whereas again, going back to that psychological safety, I would like that growth to be parallel.

Ronan (46:41):

The other thing that I would like spot is that in agile organizations, there is this whole, say, this push versus pull culture where tasks get pushed to individuals or where individuals pull the task from the backlog. And everybody used to to say that in an agile world, the team itself should pull the highest priority item, work on it first. That's the theory that they should have agency. They decide what they do next. And then so essentially the company is trusting, everybody's trusting the team to know the highest priority item and to work on it and not sort of skip the things I consider to be important. And the push culture where people are sort of much more passive. It's a difficult sort of-- like it's much more difficult to drive a community of practice because the people themselves, the community itself have to drive the community.

Ronan (47:26):

If it's like driven by the organization, well, then you might as well have it go back to the formal structures that they would have. So the community itself, I mean, when you talk about formal structures and communities and relationship to formal structures, they say that the higher levels of community, like for example, you might start off with a community related to DevOps or something like that, then it grows and grows and grows and becomes more and more strategically important. And then it can either be-- it could be absorbed into the actual host organization by having its own organizational structure built around it. And some communities were to go that route as well, that they become formalized as part of the day-to-day work, or they get formalized as part of the actual hosting organization. So there is that aspect about it as well.

Ronan (48:09):

But that's an interesting idea. And I think that when I talked about service design and use of communities of practice, there was one paper by Grenville that talked about using service design tools to build a community of practice that was very successful, had thousands of people. And then it's sort of like, okay, well this is so important, we have to put a team behind managing it, and then it became more of a formalized process instead of success at the community part of it, because then it became not so much a community practice, but more of a formally organized event.

Tuomas (48:36):

Yeah, that's also kind of brings me back, thinking about that brings me back to in the beginning, we discussed about I said, blogging channel for an example, very popular and works really well, people are very excited about doing blogs. Is that a practice community? Cause I kind of feel it is. It has a very specific, or like a clear template and clear process on how do you do the blogs. It just helps you do whatever kind of blogs, you know, it just helps you to structure your thoughts in a better way, and be able to become that what I call the dolphin consultants. So dolphin workers that, you know, they go below the water and then they pump up back up and share their information, and again, they go below the water. And blogging is just one way of, you know, enabling that dolphin-like movement.

Ronan (49:29):

It could be, I mean, could you define the objective of this community? What would the vague objective would be if you could define that, and then how you mutually engaged, then I can say that you're pretty close there. But as I said before, with all communities, I always look for the three things. What's your joint enterprise, what's your mutual interaction, and what is your common repertoire? What is the language that you use? If you have those three things and you can sort of say, oh, we have this, this, and this, chances are, you're pretty close to community of practice.

Lauri (49:59):

Thank you for listening. Both Tuomas and Ronan can be found in social media, and I'm sure they're eagerly continuing the conversation around the subject. We leave their profiles in the show notes, alongside the materials that we've referred in the show. If you haven't already, please subscribe to our podcast and give us a rating on our platform. It means the world to us. Also check out our other episodes for interesting and exciting talks. Finally, before we sign off, let's give Ronan and Tuomas an opportunity to introduce themselves. I say, now take care of yourselves, and remember, if you have familiar tools to build communities, use them.

Tuomas (50:36):

Hello, Tuomas Leppilampi, DevOps team Lead Transformation Consultant, and all round community specialists in Eficode. My love for communities stems from also outside of workplace. I do festivals and art community activities and these kind of things. And for the last couple years, I've been helping spin up the practice communities in Eficode which is a very diverse set of disciplines and individuals. And it's been a challenging route, and I'm always looking to learn more about building communities. And today, the discussion with Ronan and Lauri has been very eyeopening.

Ronan (51:21):

Hello, I'm Ronan Mac Laverty. I'm a director of platform development in Varian, a Siemens health care company. We make radiotherapy equipment and a lot of other software for cancer care. My participation in this community of practice discussion is driven by my MBA thesis, where I use service design tools to help communities of organizers to create communities of practice.

Music (51:44)