Ethnography, which literally means people-writing, is one way anthropologists study communities. They write very detailed and uninterpreted descriptions of what the people living in them do and say. These raw and unstructured accounts can be almost like diaries.

Most computer services are doomed to fail because they’re based on wishful thinking about the way their users should behave, not how they actually work. This is where ethnography comes in. Just like good user statistics, it forces you to stare the gloriously illogical humanity of people’s behavior square in the face. Only after you’ve got a feel for that can you create something that might fit into their lives.

Defrag was full of visionaries, academics and executives, people used to creating new realities, and changing the way people work. One of the most useful open spaces I attended was a session on how to bring web 2.0 tools into big companies. What amazed me was their visceral loathing of the imperfect tools already being used. My suggestion that there might be some valid reasons to email a document as an attachment rather than collaborating on a wiki was met with a lot of resistance. An example is the fine-grained control and push model for distribution that email offers. Senders know exactly who they’re passing it to, and though those recipients can send it on to others, there’s a clear chain of responsibility. With a wiki, it’s hard to know who has access, which is tricky in a political environment (ie any firm with more than two people).

Digging deeper, especially with Andrew McAfee, it felt like most of the participants had encountered these arguments as smokescreens deployed by stick-in-the-muds who disliked any change, which explained a lot of their hostility to them. It felt to me like the reason they are so effective as vetoes to change is that they contain some truth.

This smelt like a interesting opportunity, with a chance to take useful technology currently packaged in a form only early adopters could love (where’s the wiki save file menu and key command?) and turn it into something a lot more accessible to the masses, requiring few habit changes.

As a foundation for thinking about that, here’s some psuedo-ethnographic observations on how I’ve collaborated on written documents. They’re written from memory, and I’ve structured them into a rough time-line, and conglomerated all my experiences into a general description. This makes it not quite as raw as real ethnography, but it’s still useful for me to organize my thoughts.

• Someone realizes we need a document. This can come down as a request from management, or it can be something that happens internally to the team. The first step is to anoint someone as leading the document creation. This often happens informally if it’s a technical document, and often ends up the person who’s identified the need. If it’s a politically charged document, the leader is usually senior, and often someone with primarily management duties.
• Then, they figure out if it’s something that can be handled by one person, or if it really needs several people’s inputs. There’s a difference between documents that are shared for genuine collaboration, and those which are passed around for politeness’s sake, without the expectation of changes being made. Assuming it’s the first kind, there will be a small number of people in the core group who need to work on it, very seldom more than four.
• If it’s documenting something existing, somebody will usually prepare a first draft, and then comments are requested from that small, limited group.
• If controversial technical decisions or discretion are involved, then the leader will often do informal, water-cooler chats to get a feel for what people are thinking, followed by a white-board meeting with the core group. An outline of the document is agreed, with notes taken on somebody’s laptop, and often emailed around afterwards.
• If someone’s trying to sell the group on an idea, they may create a background document first. This is usually sent as an email, with either content in the message, or a wiki link.
• In most cases, the leader’s document is emailed around to the core group for comments. No reply within a day or two is taken as assent, unless the leader has particular concerns, and follows up missing responses in person.
• For very formal or technical documents, changes will be made in the document itself. More often the comments will be made in an email
• thread, and the leader will revise the document herself with agreed changes, or argue against them by email, or talking directly to the person.
• Documents being collaborated on are rarely on the wiki. Word with change tracking enabled is the usual format. Standing policy and status documents are two big exceptions. They’re almost always on the wiki, but may not appear there until they’re agreed on.
• Final distribution is usually done by email. For upwards distribution to management, this will be as a document or email message. For important ones, this is often only a short time before or even after a personal presentation to the manager who’s the audience, to manage the interpretation.
• For ‘sideways’ delivery to colleagues, a wiki link may be used, though the message is still sent by email, and might be backed up with an in-person meeting.

This is just a brief example, but looking through these raw notes, a few interesting things leap out at me. Who sees the document at each stage is important to the participants. It’s possible to argue that this is a bad thing, but it’s part of the culture. We aren’t using our wiki for most of our document collaboration, it’s still going through email and Word, which might be partly connected to this.

It’s a useful process, it’s a way of looking at the world that helps me see past a lot of my own preconceived ideas of the way things work, through to something closer to reality. Give it a shot with your problems.