Glacial Erratics

Concrete Collaboration

April 25, 2003

Anne and others, in various places, have reminded me that although I may like it there, living in the land of abstraction doesn't often change things in any immediate sense. So, since she's been suggesting that her husband and I need to provide some concrete advice on how buzzword-compliant collaboration can improve "respect in the workplace" and "help people do their jobs better right now" here's something that worked for me. I'm drawing directly on my own experience managing what was, for a while, an extremely high performance team. There's nothing new or revolutionary about this, but people don't often do it and I wish they did, so maybe writing it down has some value. No guarantees, context is everything; results will vary with degree of application. This method has a bias towards a certain work style. Explaining this briefly does not do it justice but time, at the moment, does not allow more. Thus you might find this rather, well, unexciting. And excuse any missteps, I've probably left out something important, but this is a blog after all.    (0000H8)

This recipe applies to small teams working synchronously and in-person. It assumes that the participants are performing some kind of "knowledge work" in which maintaining a good flow of information, understanding and context is important. It may apply equally well in other situations. I suspect it would.    (0000H9)

First:    (0000HA)

  1. Make a group email list.    (0000HB)
  2. Archive it.    (0000HC)
  3. Use it for all internal communication.    (0000HD)
  4. If your group makes regular contact with other groups have that contact go through the email list (send and receive) but designate one role that responds to those contacts. The responder role should rotate amongst the group members.    (0000HE)
  5. When communication occurs somewhere other than the email list, backload it to the list for the archive and to keep everyone informed (e.g. meeting minutes)    (0000HF)

That makes for a lot of email but it has several benefits:    (0000HG)

  1. It enforces learning.    (0000HH)
  2. It exposes shortfalls in people's understandings which can then be remedied.    (0000HI)
  3. It automatically creates an archive of much of the tacit knowledge in the organization that can later be refactored as training materials, project documentation, reports, etc.    (0000HJ)
  4. It identifies individuals in the group that have special skills which can be put to greater use. (Or to put it another way, the secretary, the source of all the how-to knowledge, can be glorified; merit goes where merit is deserved.)    (0000HK)
  5. It maintains or at least informs the narrative or script that drives activity.    (0000HL)

That alone addresses some of the needs that Anne mentioned but there's more. A system like this, when managed well, encourages a sense of openness and discussion that can often lead to innovation. It also frees up the mind from remembering context and how to do the job by creating a system of external cognitive aids that by there mere presence (i.e. even if you don't use them but just know they are there) install some confidence, understanding, and a sense of place and belonging.    (0000HM)

Identifying those external structures as cognitive aids is what leads to the abstract meanderings and tool building that is usually happening on this weblog. What are the mechanisms, metaphors, analogies and patterns that support those cognitive aids?    (0000HN)

PurpleNumbers, for example, are a tool to enhance the accessibility of document based cognitive aids. They provide a way to create handles to artifacts out there in the world.    (0000HO)

All of this emailing of course comes with significant cost in overhead. It's a lot to read and there has to be someone in the group, usually the manager, who process managerial directives and other big picture bits of context into the flow of information (this is a crucial part of the activity, requiring a manager that is fully converted and committed to the religion). Those are time consuming activities.    (0000HP)

My opinion is that calling it overhead does the activity a disservice. If the job of a "knowledge worker" is to smartly process knowledge, then managing communication is a crucial part of the job. My experience has been that the performance enhancement that results from increasing the access to context and knowledge makes up for the supposedly lost time.    (0000HQ)

Many people react to this prescription by saying they don't have time do the email or they simply don't like having email play such a large role in their activity (for example, they are too busy out with clients trying to sell things). I'm not sure how to respond to that. Again, my experience has been that the increased knowledge and access to knowledge that results from all the sharing results in increased performance and synchronicity between participants (using the sales example again, salespeople are more able to sell products and services that actually exist, at the right prices and with the correct specifications).    (0000HR)

Certainly there is a limit to the number of people that can work with this kind of scheme. I suspect it is somewhere around 10 people.    (0000HS)

My concerns with systematizing collaboration fit in with this picture. The above is not something you can foist on a group of workers by managerial decree and all of sudden there will be higher performance and greater respect in the workplace. You have to have to have commitment from all the participants. Getting that commitment is a chicken and egg problem which might make another topic some other time.    (0000HT)

Comments

1/3
On April 26, 2003 01:53 PM BillSeitz said:
2/3
On April 26, 2003 09:36 PM Anne said:

Thanks, Chris! This whole discussion has been interesting and thought provoking. I know my emphasis on practical application isn't for everyone, but any bit of illumination helps. Really, I don't mean to player hate. ;)

3/3
On April 30, 2003 06:17 AM Chris said:

Bill: I think Wiki's are a valuable addition in some cases, but they usually require an adjustment in work styles which may be too much for an evironment that is a bit resistant to try new stuff.

Email has much deeper penetration than wiki. Getting people to use something they are already using, but in slighty different way is a smaller step to take but is an investment with very high returns.

Or, in other words, baby steps, or Rome wasn't built in a day.

Sending...