Team Building With Wikis

When our CEO Eugene Lee joined us six months ago in almost every meeting he would remind us that “every time there is a new team member, its a new team.” A key concept from The Five Dysfunctions of a Team by Patrick Lencioni.

As a leadership team, there were a lot of approaches we could have taken for teambuilding — games, exercises, workshops, and other special events. Instead, Eugene led us to learn how to become a team by working together.

Good thing too, as we are a startup, otherwise known as a business that grows without perfect resources, especially time. But for businesses of all shapes and sizes, I see an interesting trend — less side activities and more social interaction while getting work done.

Consider if you will the field of knowledge management systems, a relative failure which I parodied thusly:

Manage Knowledgement is a way of describing KM that’s backwards but works. With KM, users were supposed to fill out forms as a side activity to extract their tacit knowledge. Then some form of artificial intelligence would extract value. Turns out, users resisted and the algorithms didn’t match reality. With MK, through blogs and wikis, the principle activity is sharing, driven by social incentives. Contribution is simple and unstructured, isn’t a side activity and there is permission to participate. Intelligence is provided by participants, both through the act of sharing and simply leaving behind breadcrumbs of attention.

Every organization wants more knowledge and better teams. And yes, some side activities are very effective towards these broad and fairly intangible goals. However, when times get tight, like today’s recession, side activities get cut.

Wikis and Social Software offer an opportunity for sustainable team building. Not just when you have gained adoption through effective practices so people share and connect while doing their daily work. But specific team activities.

Team building begins with vocabulary — developing a shared language. Eugene joked that half the team was wiki purists and the other half were old school emailers (which aside from language also meant we needed agreement on what modalities to use when). There was five years of social software learnings documented in our wikis. And a practical understanding of how most corporate users actual work. Some of it meant learning other’s definitions and some new terms had to be developed.

Now all of that could have occurred in meetings, and some of it did, but this is where the wiki comes in. Wikis ask users to share control over a commonly editable resource. They also ask groups to gain agreement on how to use the tool to be effective. And when there is a well defined goal for the collaboration it even generates value.

Simple conversations occur that lead to simple agreements like “let’s use these four tags, for these four kinds of information — and lets agree to pay attention to pages and posts with this tag on a daily basis.” While it seems mundane at first, the team not only develops a shared language, but a way of working with it.

A major automobile manufacturer customer used Socialtext for long term strategic planning. Beyond effective lightweight collaboration, they valued how it made transparent the ideas and preferences of team members — but also enabled them to gain agreement faster.

What’s also interesting is how this scales into mass collaboration. You can’t really call a group larger than 150 people a team, or pre-define the teams that really work at that scale. But you can develop a shared language at scale. One interesting facet of this way of working is what the inventor of the wiki, Ward Cunningham, calls “happy accidents.” When a person creates a link to a page that they don’t think exists yet, but finds someone has already created a page by that name. They not only discover existing work to build upon, but use of language to agree upon — and the people behind it.

Next time you have a new team member, and thusly, a new team, consider these simple practices for team building:

• Project shared notes in a wiki page while meeting
• Start an initiative to document best practices, kicking off with a conversation about basic language and how to structure information architecture. Revisit as a group on a regular basis until it takes off on its own.
• Augment your next leadership offsite with an Wiki Eventspace to
  • flush out the agenda beforehand
  • have participants create profiles including answering topical questions
  • organizer communication
  • shared notes and in-session conversation
  • structure new initiatives on the fly
• Look for major exceptions to business process to rapidly form an expert group focused not just on resolution in rapid time, but documenting learnings in the process
• Look for common editing exercises, from mission statements to press releases
• Encourage rich profiles, blog posts and wiki expression not just about work, but the things that help others understand the identities behind their words and work. Even if its blogging about cats. If you clamp down on tone, it wont be fun (especially compared to paintball). This is not a directed side activity, and these conversations occur in the lunchroom and by the watercooler anyway, just with less distribution and persistence.

And if you are still looking for a directed side activity, there is of course, a Teampedia.

Comments (1)