It came in response to a post of mine about Enterprise 2.0 adoption where I wrote that:

Boyd's drawing a really important distinction here. In our daily lives, we are all members of various groups: our families, neighborhoods, church groups, ethnic groups, etc. Also at work, we are members of groups: departments, business units, project teams, carpools, weekend soccer players, etc. These are collections of people--more or less dynamic, more or less formal--who share some common set of attributes, activities, or interests. At the same time, we all have our personal networks--the individuals whom we know and interact with. There is of course a lot of overlap between a person's groups and her network; we know many of the people in our groups. But an individual's personal network typically spans multiple groups. My network, for example, includes my colleagues at Socialtext, my former McKinsey colleagues, my neighbors in Philadelphia, the other parents at my childrens' day care, and so on.

When Boyd says that Enterprise 2.0 is about personal relationships in networks and not group membership, I think he's saying that the point of Enterprise 2.0 is not to enable existing organizational groups, but to empower and mobilize social networks for getting work done in new ways.

Who's right? I think we both are.

Boyd makes a really important point about social networks. Web 2.0 is waking us all up to how powerful it is when social networks are made transparent. From a professional standpoint, a worker's long-term career development,  sense of belonging, job satisfaction, mentoring and guidance, etc., are often driven more by social networks than by formal groups. That trend will accelerate as social networking takes off in earnest within enterprises.

But it's important to recognize that the fundamental unit of collaboration is the group. Departments, divisions, business units, teams, committees, etc., are the wheels on which almost all companies run. That's not an Enterprise 1.0 or an Enterprise 2.0 thing; it's a reflection of the fact that collaboration around tasks of any size requires continuity and accountability.

This isn't an either/or thing, however. The sweet spot for Enterprise 2.0 lies at the intersection of group collaboration and social networking. As I've blogged about before, Enterprise 2.0 has business impact when it's integrated in-the-flow of everyday work. For most workers today, it's their group work that's in the flow. Social networking becomes truly valuable--and generates meaningful organizational adoption--when it's layered on top of, and appropriately integrated with group collaboration.

• Emergent Approach: Community has little or no structure at launch, and a structure emerges over time
• Highly Structured Approach: Communities have a detailed, thought-through taxonomy at time of launch
• Adaptive Approach: The community launches with a few very broad categories, from which structure emerges and develops over time

Foster advocates the Adaptive approach in most cases as being the most flexible and easiest to implement. I wholeheartedly agree, and will chime in with a few supporting observations.

I've seen plenty of examples of communities that launched with a high degree of structure. Many of them worked...after a fashion. But these "communities" usually are really publishing tools where a few people post things and everyone else consumes. (I've seen this a lot in professional services firms, which tend to have large knowledge management or practice staffs whose very job it is to post industry updates, pitch packs, methodologies, etc.) This isn't necessarily a bad use of the tools; many companies are much happier on a collaboration platform than on a larger, more expensive, and less user-friendly Content Management System. But it's not exactly community.

I've also seen examples of successful communities following the emergent approach, but this tends to work best with very small groups (e.g., under 30 or 40 people), and where there's extremely strong momentum going into the project.

With respect to the Adaptive approach, I think it's very important to pick the right types of categories. Because of Wikipedia, many people think "structure" has to be something encyclopedic like industries, geographies, market segments, etc. But what I'm seeing in the field is that a structure is often most effective when it guides a user as to the types of actions or activities the tool supports. In that spirit, here are some structural categories worth considering:

• Instead of email
• Meeting notes
• Feedback
• Big wacky ideas
• Overheard from customers
• Questions and Answers
• Reusable documents
• Company processes

What other categories have you seen work well? I'm curious to hear!

The other day, I saw a really great example of an in-the-flow collaborative tool at Acumen Fund. When project champions Brian Trelstad and Rob Katz  set out to implement a knowledge management system, they quickly realized that the organization already had all sorts of processes and mechanisms for capturing knowledge and ideas. The question was how to tap into those resources in a way that would create transparency, access, and reuse across the organization's four locations in Hyderabad, Karachi, Nairobi, and New York.

Brian and Rob came up with some really great techniques to redirect Acumen's flow of work through the collaborative workspace:

• "Instead of email": Acumen already had a culture of sending company-wide emails containing interesting articles and thoughts and triggering discussion threads. But those threads were lost in everyone's in-boxes and archives. So Brian and Rob created a button called "Instead of Email" and approached Acumen's top emailers to start posting their messages to the shared workspace. Acumen even created a set of email aliases that allow users to send emails to Instead of email. (The language gets a little counter-intuitive...kind of like going to a Start menu to shut down your computer.)
• Meeting notes: Acumen already had a culture of taking detailed meeting notes, especially at company-wide "Monday Morning Meetings." Those notes are now taken online, automatically tagged as meetings, with a standard naming convention including the date and meeting name. Acumen's leadership team reinforces use of the workspace by posting agendas and notes in the workspace rather than email
• Contact details: The company directory, complete with contact information, conference room dial-ins, and other logistical details are all kept in collaborative workspace. It may not be sexy, but it's mission-critical information and it keeps people coming back. And putting it in the wiki makes it easy to keep up to date.
• Office clocks: With offices in four time zones, Acumen's staff is constantly calculating local times for meetings. Rob found a Google widget for international time clocks, and dropped it into the workspace. It was cheap and really really useful.

Finally, there was the way Brian and Rob launched the new workspace. They called an office-wide meeting in New York (Acumen's biggest office), and kicked it off with a scavenger hunt. Participants were given 20 questions to answer from information that was already in the workspace. It was a fun way to launch the effort and, more importantly, it forced everyone to log in and try it out for themselves. The winning team got a pair of Starbuck's cards, which they promptly gave to the runners-up. "We don't like coffee", they announced proudly. "We just wanted to win."

White is right to warn IT managers off the build-it-and-they-will-come approach. And I really like the idea of a simple diagnostic to assess an organization's readiness to embrace Enterprise 2.0, but I think White has the wrong list.

White's list runs together many different types of collaboration: working across organizational silos on specific tasks, working within an organizational silo on specific tasks, codifying personal knowledge for general consumption, picking up the phone to call someone you know, picking up the phone to call someone you don't know, etc. The cultural conditions vary significantly by the type of collaboration, so you can't lump them all together this way.

The common denominator across the list is collaboration. But being "collaborative" is a pretty low bar these days. People in almost all knowledge-intensive roles have to collaborate on project teams, in meetings, around deliverables, etc. There are very few jobs left where you can be effective working all by yourself.

And people already have a collaboration tool: Email. Even the most "uncollaborative" people send dozens of emails a day.

So the meaningful question here is not "Is your organization collaborative?", but rather "How will your organization collaborate?" Will your employees collaborate through email, or will they use Enterprise 2.0 tools like blogs, wikis, social networking, RSS feeds, etc.?

As I see it, the difference between email and Enterprise 2.0 boils down to a few fundamental contrasts:

• Enterprise 2.0 posits the group as the primary unit of activity; email posits the individual
• Enterprise 2.0 requires high-speed network access; email can accessed offline, via BlackBerry, etc.
• Enterprise 2.0 is the challenger; email is the incumbent

In that spirit, let me offer up a much simpler version of the White/Hansen checklist:

1. Do employees work in groups or teams? (Extra credit if individuals typically work with multiple groups in parallel or group membership changes frequently)
2. Do employees have constant network access, or are they frequently offline due to travel, field visits, etc.?
3. Do employees use multiple online tools to complete their daily work?

If the answer to all 3 questions is yes, you've got a pretty good shot at Enterprise 2.0 adoption.

The other week, I was meeting with a project team at a large retail bank who is bringing Socialtext into their organization. It was a cross-functional team, representing different parts of the IT organization. One of the participants was the manager responsible for the company's document management system. He wanted to know how this project would change his world. Would Socialtext replace the DMS? Would the two work together?

It's a fundamental question. Companies have already made six-, seven-, and even eight-figure investments in their document management systems. Those systems house thousands or even millions of documents. And while many companies are attracted to the ease and flexibility of Enterprise 2.0 collaboration tools, they are understandably jittery about potentially cannibalizing document management systems which have so much investment and content behind them.

The first thing that companies should understand is that document management and collaboration are distinct activities. Document management is all about workflow, control, and risk mitigation. Its objective is summarized perfectly by the two words in its name: "documents" and "management". It got its start in the legal departments of pharmaceutical companies, who were concerned to make sure that their companies were producing documentation in full compliance with regulatory requirements. A DMS thrives where there are a) documents already being created as part of a business process; and b) those documents need to be closely checked in, checked out, supervised, edited, approved, and stored following a consistent and audit-proof process.

Collaboration, by contrast, is all about people working together to share ideas, notes, questions, comments, etc. Collaboration does not typically follow a standard process; it is much more free-form and free-flowing. Documents are not typically the format of choice. Asking a question or creating a meeting agenda or to-do list doesn't require a document; it just requires typing some words and putting them where other people can see and edit them. That's why so many people simply fire off an email when they collaborate; it spares them the unnecessary step of creating a document.

When you look at it this way, document management and collaboration don't have very much to do with each other. So why is there a question about how the two relate?

The two activities get confused because document management, like collaboration, involves creation of content by multiple people. For many companies, the DMS is the first tool they implemented that enabled more than one person to touch a single, centrally stored piece of content. And the document management vendors began to capitalize on the opportunity by introducing document-centric team rooms (like Documentum's eRooms, for example.) As a result, many companies began to use the DMS as a collaboration tool. The DMS wasn't very good at it. It required every piece of collaborative content to be saved as a document. Search was cludgy or non-existent, and everything had to be filed in a nested folder structure. But it was better than nothing, or email.

Last week I saw first-hand a good example of this phenomenon recently at a major executive search firm. They wanted a way to collaboratively publish questions, comments, slides, bios, etc., and engineered an entire intranet around eRooms. It was cludgy, and adopted primarily by power users who took the time to create a Byzantine taxonomy of folders and sub-folders.

All of which brings me back to my meeting with the retail bank. When asked about the relationship between DMS and collaboration tools, what I said was that some of the content in a typical DMS really belongs there. These are the documents associated with highly regulated processes. But most of the content in a typical DMS--to-do lists, meeting notes, press clippings, conversations, working papers, personal observations--doesn't really belong there. It's in the DMS because there was no good place to put it. That's where a collaboration suite can do a much better job. A good collaboration suite can liberate that content from the tyranny of documents and nested folders, and will encourage people to use it for actual working materials.

In many cases, you will want to integrate the two. Law firms, for example, are absolutely dependent on their document management systems to manage their filings and other legal documents. But we're increasingly seeing them set up collaboration suites to capture all the discussion around the documents, how to use them, what they mean, and so on. The two systems are integrated with links from the collaboration suite into the corresponding DMS records.

What I'm saying amounts to this: Use your document management system to manage documents, and use your collaboration suite to collaborate.