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.
About Shawn Callahan
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:
Send this to a friend