I was just reading a report out from Deloitte’s Stan Garfield on Communities of Practice (original post from the Darwin Discovery Engine Blog no longer available. Find KM-related posts form Stan at Medium). Here are some thoughts on Stan’s 10 Principals. My comments are in grey.
One – Communities should be independent of organizational structure. They should be based on the content.
I would contend that communities should be recognized as alternative organizational structures. Is some organization, they take on roles and responsibilities that would have previously been administered by an individual. In the age of networked organizations, I think they are an alternative. Politically, inside of command-and-control structures, they may exist “outside” but that is only because of the dissonance between metaphors. COPs are actually much more reflective of how work gets done today, regardless of the overarching organizational structure.
Two – Communities are different from organizations and teams. People are assigned to a team. Communities are better with self–selection for joining and remaining.
I agree with this but would add the ideas of emergent and adaptive. Communities of Practice can often become as rigid as any other organization. Their ability to thrive over time requires them to be true learning entities. If they are that, then they will be able to adapt. If they are moats around an idea, build to protect it from change rather than adapt to change, then they will be likely short-lived, and not very useful.
Third – Communities are people and not tools. You should not start with tech features. A platform is not a community. Readers of the same blog are not a community but that might be a byproduct.
I absolutely agree with this. Communities of Practice do not need tools. However, in a global, multi-national environment, communities without tools become geographically restricted, because they can’t scale and can’t be inclusive. It is important that communities define themselves before they define their need for technology, and ironically, that may require technology. They should avoid being constrained by the tools they adopt, opting for agility as they move from building to sustaining.
Fourth – Communities should be voluntary. The passion of members should be what drives a community. You should make the community appealing to get members and not assign them to it.
I agree…but this doesn’t mean they shouldn’t be evangelical. If you are passionate, seek out like-minded people and share the value you receive through association. You want to recruit people to increase the diversity of opinion and learning opportunities, so don’t be satisfied with early volunteers, go out and find like-minded souls to join the community.
Fifth – Communities should span boundaries. They should not be for a particular group likes Sales or IT. There is a lot of cross-functional or cross-geography learning that would be missed then. Diverse views help communities.
Yes and no. I think it is completely acceptable to have a community of salespeople who discuss how to be better salespeople. I think it is OK for IT people to include JAVA, HTML or C# communities. If that is the locus of passion, then run with it. That being said, don’t limit membership to IT people. If amateur or departmental experts want to get involved, then they should be welcomed.
Sixth – You should minimize redundancy in communities. Consolidation helps to avoid confusion by potential members. It also reduces the possibility of not getting a critical mass. Reducing redundancy also enables more cross-boundary sharing.
This is very much my point in item one. As alternative structures, they should be emergent, but once they emerge, they will be influenced by organizational forces, including those of design. You want to avoid communities creating factions because the process and the tech support is so easy that those who disagree just splinter off. I often suggest a community of practice on community management, so that rather than having a person responsible for this level of negotiation, community leaders own this responsibility.
Seven – Communities need a critical mass. You need at least 50 and likely 100. Usually, ten percent are very active so you can get a sufficient level of activity with 100 people.
Can’t argue with this one. And as with start-ups, hire slow and fire fast – meaning, that if a community isn’t getting traction, most past it fast. If the community gets adherents and is fumbling, then give it the time to learn.
Eight – Avoid having too narrow of scope for the community. Too much focus can lead to not enough members. Stan advises people to start broad and narrow if necessary—or start as part of a broader community and spin-off if needed.
I think this goes hand-in-hand with numbers 5 and 6. I think it is OK to be narrow, but also necessary to be inclusive. If you are too broad, people may not find the purpose-focused enough for them to find a place to contribute. People need to be able to see themselves as part of the community, be able to see the passion in their peers. If the community gets too broad, it becomes hard to know what it is for, and too hard to care what it does.
Nine – Communities need to be active. Community leaders need to do work, often in the “spare time” at their regular work. This means that the leader needs a passion for the topics so he or she will spend this extra time. There needs to be energy to get things going.
I think we have a critical disagreement here. If we take my first premise, that this is an alternative organizational structure, then COPs should be part of the roles and responsibilities of their members. KM fails when it relies on altruism. Communities of Practice should be part of 360 reviews of members. If you are supposed to be an expert in something and a community exists, and you aren’t contributing or otherwise participating, then you aren’t adding value to the organization and that should be reflected in your performance evaluation. This approach steps a bit over the voluntary line, but it still implies degrees of freedom of movement. If we think learning is important enough to invest in COPs, then we need to put our pay-for-performance where our beliefs are.
Ten – Use TARGETs to manage communities. TARGET stands for: Types, activities, requirements, goals, expectations, and tools. Each of these issues needs to addressed and explained to prospective members. Tools are necessary, but the least important component, so they are placed last.
I’m not big on acronyms because they necessarily simplify things that are probably complex. If something is complex, embrace its complexity. Missing here are issues of governance, responsibilities, accountabilities, facilitation models, nurturing (as in how to deal with the inclusion of people with very different mental orientations), charter, retention, value, branding, knowledge stewardship, innovation, retirement, etc.
I like Stan’s list, but as with all presentations, it is constrained by time. I look forward to the dialog about how these should augment a strategic view of communities of practice, where you agree and disagree, and what else you think is missing.
For more on KM from Serious Insights, click here.
Leave a Reply