Tackling large domains in communities of practice
One of our clients is a large engineering firm (perhaps Australia’s largest) and I’ve been working with them over that last 12 months helping to establish some communities of practice. Our first one focussed on technical draftsmen and is off and running well. Their domain is well defined, they have good participation and have developed a strong rhythm of activity. From the outset I’ve encouraged them to collect their stories of success such as the one about how the members designed and delivered a three-hour course on diagram naming and part number databases (to the uninitiated this sounds prosaic, but part numbers is a massive issue for engineers). They’ve run it three times and it has been a resounding success.
The other community of practice has a sprawling domain: engineering. I tried to advice against such a broad domain because it fails the basic identity test where I ask whether people stand up proudly and say, “I am an engineer.” It turns out they are more specific than that. They are mechanical engineers, print circuit board engineers, or electronic simulation engineers, to name just a few of the possibilities. So this CoP has limped along and today the core team sat down to redesign the approach.
After a good discussion we identified two technical sub-groups in the engineering community that we could focus on: print circuit board designers and another group that uses a particular systems analysis tool. The third group was role based and while we didn’t pinpoint the exact engineering role to focus on we recognised that there were roles like project engineer and engineering manager who might value learning from their colleagues. This role-based community also enables the broader engineering-related issues to emerge while also keeping the conversations lively and relevant to the participants.
This might be obvious to the many CoP experts out there but we learned today that you can overly focus on technical groupings to establish CoPs and forget about role-based groupings. In this case there’s still a strong desire to maintain a broad engineering-wide domain but we will foster the CoP by focussing on specific sub-groups and over time look for ways to connect these groups.
Shawn, author of Putting Stories to Work, is one of the world's leading business storytelling consultants. He helps executive teams find and tell the story of their strategy. When he is not working on strategy communication, Shawn is helping leaders find and tell business stories to engage, to influence and to inspire. Shawn works with Global 1000 companies including Shell, IBM, SAP, Bayer, Microsoft & Danone. Connect with Shawn on:
Comments
Comments are closed.
You’re right about the scope of that CoP being too wide. The members are all involved in engineering in some way, but as you say, members perform different roles and are represented by different groups of interests.
Another way to reorganise a large manufactured CoP when participation from members is waning is to identify common problems and challenges that participants face. Within the engineering CoP for example, some informal CoPs will already be organised around specific topics with different groups of participants working together towards common goals. Identifying those issues might help to identify and promote smaller, naturally organised CoPs and in turn, grow membership and participation in them.
Excellent idea Brad. Nice and simple.