Team-based communities are about change, commitment and tasks
This is a follow up from my post, Team-based communities.
In that post I briefly described the dynamics in Teams using CoPs; basically same dynamics (just different space), the obstacles in participation, and how the lead is to be a role model for adoption and facilitation of the CoP.
This post is more of a prequel to my past post on team-based CoPs, as I want to share some of the questions I’m now beginning to ask Team leads who want to set up a CoP space for their team.
| Online communities provide a new way of working; and are more about the people than the tools. They are a catalyst to changing behaviour, routines and habits in order to improve social productivity |
But first here are some general questions I ask any type of new community.
Broad questions to consider for new communities (both team and shared interest)
When requesting a community there are a few things to be considered prior to set up:
- Is the community about shared learning, or to help a team coordinate and communicate?
- Is the community a public face for the rest of the firm to be aware and interact with that team?
- Will the community content be for a private or public audience?
- Will the community content be contributed by members only, and be visible to read by non-
members? - Who will be leading, and running the community?
- What are the existing community indicators? Eg. Email groups, telecon groups
- Will your community be used more if it’s regional or topic based?
Key questions for team-based communities
- Do you have a communication, coordination, and awareness issue, both within your team and with the organisation at large?
- Do you want to really do something about it by dedicating time and passion to changing behaviours?
- Are you prepared to change routines, facilitate, and role model this effort?
- In the end our communities tools are a catalyst or an excuse to improve team dynamics, productivity, and a new way of working.
What we are used to hearing about in CoPs are: learning, sharing, social productivity, ask a question…
This too can happen in Team-based CoPs, but a good idea is to focus on solving a problem, coordinating an issue, communicating a message, which is what teams do.
It’s not about social computing (hopefully these tools will soon become boring), it’s deeper than this, it’s about a better way of working eg. using blogs and wikis in a CoP space to coordinate and communicate a task rather than scattered emails and attachments.
I’m finding that when I now workshop with teams I’m not just the web 2.0 guy, I’m feeling more like a change consultant in the way of getting deep into the existing information flows, and offering new ways to do it more effective.
Communication example
I did a workshop with some team leads the other day asking the above questions.
It turned out the team lead wanted to use the CoP to communicate a message down the hierarchy.
This was a good start, as I knew what they wanted to achieve.
Next I asked what typical email distribution emails she sends out.
She listed all the groups on the whiteboard.
Then I asked what is the frequency of emails you send to all these groups.
Once we had a visual of this we could identify what tools and how many of them we were going to use.
Most of her communication emails needed to go 4 levels deep in the hierarchy.
Her second most frequent type of communication is only 2 levels deep.
The answer was two blogs.
One is a more admin blog, and the other to reach ground zero.
We also worked out that people up to 2 levels directly below her could also author in the ground zero blog (so to speak), as well as the admin blog
This CoP will also have a forum for any of the sub-team groups to use.
Coordination example
This next example actually isn’t a team, but is still about solving a coordination issue that happens across teams (This CoP is made up of leads from different teams.)
We have several applications under the one suite and every month a coordination person that represents all these teams to the rest of the business, emails each of the 6 or 7 application leads to email her their monthly release document.
She then compiles them into one big monthly release document, and then emails the company.
Throughout this process she often gets requests for the latest before she sends out her broadcast email.
She also may get subsequent emails from each application lead to add bits that they forgot to include in their original email to her.
During this process she may be emailing back and forth with each lead to clarify.
Also during this process each lead doesn’t know the conversations she’s having with the other leads.
This is what I suggested:
- the coordination person to use an admin blog to post an announcement to the leads to prepare their monthly release note
- leads get an email as they are subscribed to the blog
- at any stage they can reply to this email, which will leave a comment on that blog post (this is cross awareness and common discussion)
- this blog post has a link to a wikipage for that month
- the leads go to their respective wikipage and enter their notes
- each lead or anyone else can visit the wiki at any time…maybe??…as long as they know it’s not official as of yet
(or they can ask a question in the forum representing that application) - each lead can keep updating it at any time up to the deadline
(then the coordinator can lock off those wikipages even to those leads…she can perhaps continue to make PDF versions as well) - she may then use another blog, or email to announce to the company at large
Intended result:
- This process involves no original emails
- The coordinator is no longer a bottleneck
- The wiki process also becomes the end product
- The coordinator is still coordinating the process, but it’s simply more streamlined and actually less work for her
- All conversations are documented in the open, so more people can be aware, and quick to act
- The release wiki can seem like a database compared to a heap of folders for each month each containing PDF’s
(getting away from the filing cabinet, and moving to a more friendly interface)
[ADDED 10/03/09: Team-based communities : Transparency and Crowdsourcing for a more cohesive workplace]
![email.png](http://services.nexodyne.com/email/icon/GxbiQvgbwBgCnw%3D%3D/oIp%2BJMQ%3D/R01haWw%3D/0/image.png"){kind=icon}
In 2006 as part of a team with responsibilities including Tech Infrastructure, I tried to advocate the use of team based wikis for many of the reasons you have mentioned, including enabling team reporting & facilitation of internal transparency. Some wikis were to be open to the (progressive large corporate) organisation and others limited to relevant players. Use of RSS type feeds were to be a key feature.
One of the significant aims was also to migrate valuable data off the tangled corporate filesystem and into a wiki where the users could define & refine the structure as required. Perhaps most importantly, responsibility for data could be allocated via a hierachy thus hopefully avoiding the “save & forget” mentality that had clogged the existing corporate filesystem.
Reluctance was significant from local management for a number of reasons (including focus elsewhere, lack of recognised outsourcing partner to hold responsible), though several global forums were sponsored by global head office. Even as an advocate for wikis & social networking within the organisation, I admit the forums seemed to fit poorly with local needs, suffered latency issues and lead to a blanding of local product, though increased consistency with the global product. Costs were high and even local project sponsors had to admit they were getting poor value for money. User satisfaction was declining.
Understanding or appreciating the scope of use is important. Wikis represent a grass-roots/bottom-up type approach, so perhaps the global organisations mandatory top-down driven implementation was not suited.
I suspect we early-adopters need to bear in mind that much (or perhaps most) effective communication takes place verbally and many team members within organisations seem likely to take a stance along the lines of “I’m here to serve the clients of the organisation, not be a slave to a piece of technology”.
Perhaps 3 years later buy-in would be easier to obtain.
Comment by jon — March 9, 2009 @ 11:02 am
Thx for that lengthy comment on your adoption experience. As I said in my first post on team-based communities, it’s definitely all about leads being a role-model for successful adoption.
It’s not something you try half-assed with a team, it’s actually serious, as it’s about changing behaviours, so it should be treated both as a program and a process.
In my post I guess I’m talking about teams making the most of software designed for communities to share and learn, rather than doing tasks.
If the teams were really serious they would look into a more suitable package like Basecamp, Traction or the hundreds of others…as these more deal with projects/tasks.
A great example is the Traction case study with the ShoreBank
http://public.tractionsoft.com/traction/permalink/Public1146
http://www.fastforwardblog.com/2007/08/15/another-enterprise-blog-and-wiki-success-story-from-traction-%E2%80%93-shore-bank/
And another example
http://www.fastforwardblog.com/2007/01/16/an-enterprise-20-poster-child-in-the-it-department/
Comment by John Tropea — March 9, 2009 @ 10:32 pm