Everyone who works on enterprise collaboration software knows that organizational adoption is really important, and can be hard to achieve. Yesterday's Socialtext 3.0 launch has introduced an exciting new twist. In fact, I think it has completely changed the social software adoption game--for the better.

Socialtext 3.0 is going to appeal to non-power-users, or what I call the "I don't care about the latest gadget, I just want to do my job" crowd. It's not just the smooth user experience, personalizable dashboard, and global navigation (though those things certainly help.) To my mind, the real game-changer is the integration of social networking into the Socialtext collaboration suite. Socialtext 3.0 has bridged the gap between group collaboration and social networking. That is going to have a profound impact on enterprise adoption.

Finding people within companies, especially large companies, is a killer app. On virtually every corporate intranet, the Company Directory is by far the most heavily used application. It often accounts for north of 70-80% of intranet search activity. Even your least techno-savvy colleagues understand the need to find colleagues. So it's relatively easy to get a new user to try the tools.

As new users start to use the tools, they quickly wake up to the possibilities. Public social networking sites like Facebook and LinkedIn are penetrating the mainstream over-30 crowd at a surprising rate. More and more people are realizing that looking a person up in the phone book is only one way to find her. Best of all, it's fun and addictive.

Once people try it, social networking has a unique ability to jump across organizational silos. Blogs and wikis led the charge of social software into the enterprise world. Those forms of collaboration are wonderful, but they can be difficult to scale beyond the department level. Individual teams and groups derive tremendous value from using blogs and wikis in the flow of their daily work. But the thing about daily workflows is that they tend to center around a defined group of members and business process. Even when one group is rockin' and rollin' on blogs and wikis, moving to another group within the same company can be a challenge. Each new department or team is a brand new adoption curve.

Harvard Business School Professor Andrew McAfee has blogged insightfully that social networking's strength is the way in which it discovers, utilizes, and reinforces weak ties across a distributed social network. In an enterprise context, that means that social networking allows people to identify and connect to colleagues outside the usual suspects. Since those colleagues are almost always in a different group, department, team, business unit, etc., social networking has a natural ability to span across organizational silos more easily than other social software applications.

Because of the way Socialtext has integrated social networking with group workspaces, social networking adoption triggers adoption in other areas as well. The actions of my colleagues in Socialtext People automatically directs my attention to the workspaces they're working in. That pulls me into conversations and documents that are new to me, and reinforces my use of other parts of the collaboration suite.

From an adoption standpoint, this is a whole new world.

• |
• Permalink

Dawn Foster of Fast Wonder Consulting recently posted a really useful, practical discussion of different types of structures for corporate communities. She puts corporate communities into three categories: emergent, highly structured, and adaptive.

• 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!

• |
• Permalink

I blog a lot about the importance of in-the-flow collaboration: the idea that organizations adopt collaborative tools only when those tools are integrated into the flow of daily work. That idea resonates with a lot of readers, but so far I haven't said very much about how to do it.

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."

• |
• Permalink

This week a couple of customers I've been working with are unveiling their new corporate intranets...on Socialtext. What's interesting about both customer is that they didn't set out to replace their intranets. Originally, they were looking for knowledge management systems, to replace existing M-drives and document management systems. But as we started working together, both customers had an a-ha moment when they said, "I don't see why we wouldn't use this as our entire intranet."

These customers reflect a fundamental shift in the way companies are thinking about their intranets. Companies don't traditionally think of their intranets as places to collaborate. Since their creation in the 1990s, intranets have been seen as publishing vehicles, places where employees come to consume information published centrally. In the intervening years, intranets have improved on many dimensions. They've become more attractive, more dynamic, more animated, and more personalized. But they haven't really become more collaborative.

As companies have begun to embrace Enterprise 2.0, many began to add collaborative tools like blogs, wikis, social networking, etc. Not surprisingly, collaborative tools first made their appearance as specialized destinations separate from the intranets themselves. Intranets sometimes linked to those tools, and sometimes didn't. The intranets themselves were almost never collaborative places.

That's beginning to change. As companies digest the implications of broad-based collaboration, they are looking at their intranets as collaboration opportunities. They are using the intranet to distribute publishing of critical information, addressing every intranet's single biggest problem: keeping information up-to-date. They are adding spaces to post ideas and innovations right on the intranet homepage, and weaving social networking into the very fabric of their company's information flows.
 
Better still, companies are using Enterprise 2.0 tools to reduce the cost and accelerate the launch of their intranets. A traditional intranet launch (or re-launch) project within a mid-size company can easily take a year or more. Debates over design, publishing access, and information architecture consume months before end users see anything. In the Enterprise 2.0 model, companies can build intranets much faster and more iteratively, getting a first draft in place within a few weeks and filling in the details over time.

This blurring of publishing and collaboration mirrors the broader trend on the consumer web. In the early days of Web 2.0, collaborative tools like MySpace and Facebook were isolated applications that users navigated to from traditional publishing portals like Yahoo! Increasingly, however, these collaborative spaces are becoming the platform through which users access all kinds of content and applications.

As one pundit put it (can someone help me out with the attribution?), for today's users, MySpace and Facebook are the internet. I predict that in three years' time we'll be saying something similar about intranets.

 

• |
• Permalink

The National Computing Centre in the U.K. has posted an interesting article by Martin White on Achieving effective Enterprise 2.0 adoption. The center of the article is a list, developed by INSEAD's Morton Hansen, of 10 statements to diagnose an organization's readiness to adopt Enterprise 2.0. It includes things like:
-Employees feel that they have a duty and a freedom to help others even if there is no immediate benefit, and indeed even a short-term impact on their own work performance.
-Employees willingly work together with colleagues from other units to solve specific problems.
-The organisation has clearly stated principles related to the value of teamwork and cooperation.
-Examples of good practice and success in knowledge exchange are given wide publicity and recognition.

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.

• |
• Permalink

What's the relationship between a document management system (DMS) and an enterprise collaboration suite like Socialtext?

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.

• |
• Permalink

Business Week just published a must-read article called "The Knowledge Handoff: How corporations are scrambling to tap the expertise of baby boomers before they retire." I'm really glad to see this story being picked up. Many of the companies I talk to, from pharmaceuticals to construction, are worried sick over the expertise that is coming up for retirement in the next 10 years. They're desperate to retain it, but don't know how.

Business Week got some important things right here. Most importantly, the stories recognizes that companies won't solve the problem by cramming employees into classrooms and handing aging boomers a piece of chalk. Instead, the article counsels that "companies should encourage soon-to-be retirees to use digital tools like wikis, blogs, and instant messaging." Business Week frames the issue as a generational gap, arguing that boomers need to use high-tech tools to communicate with Gen Y'ers.

Business Week is giving good advice, but for the wrong reasons. It's not that Gen Y'ers can only communicate on wikis and IM. The real insight--the one I wish Business Week had focused on--is that when employees use Enterprise 2.0 tools (like wikis and blogs) to collaborate, they create valuable assets which endure even after their creators have retired. If more boomers did their work in collaborative tools instead of emails and other private forms of correspondence, their colleagues would retain access to their ideas post-retirement. Just think of it as professional immortality.

Professional immortality. If that's not a good reason to use a collaborative tool, I don't know what is.

• |
• Permalink

The other week I flew Southwest for the first time in a while. (I was headed from my home in Philly to Pittsburgh for a customer meeting.) Along the way, I got an interesting and unexpected lesson in the value of self-organization.

Usually, I fly on United (San Francisco is a hub) or USAir (Philly is a hub). Both of those airlines are as traditional as you get, and seating is always a problem. Because I travel on business, I usually book my tickets later than vacation travelers. That means that seat availability is poor, and invariably I get stuck in the back of the plane. I hate sitting in the back of the plane. It's not the back of the plane per se that I hate, but the hassle of getting in and out. I'm a big guy, I usually carry my baggage on the plane, and I'm often rushing to make a business meeting. So I don't like the discomfort of moving down the aisle, and I resent the time that I lose waiting for all those people to get off the plane ahead of me.

Southwest seating works differently. There are no pre-set seat assignments. You can sit wherever is available. You do, however, get a boarding priority assignment based (I assume) on when you bought your ticket and how much you paid for it.

When I got to the airport this morning, I discovered that my boarding priority assignment was a high number. I would be one of the last to board the plane. So I assumed that I would, once again, sit in the back of the plane. Probably in the middle seat.

So imagine my surprise when there were aisle seats available in Row 3 on the outbound flight. On the return, I got an aisle seat in the first row bulkhead. And it's not as though the flight was empty. Roughly 60-70% of the seats were occupied. It just turns out that the seats I like--the ones right up near the front of the plane--aren't nearly as popular as I had always assumed. My co-passengers walked right by them in order to sit in the middle of the plane and towards the back.

Why did the other passengers choose to sit where they sat? Bathroom proximity? More leisurely deplaning?  I have no idea. You'd have to ask them. But clearly their preferences are different from mine. Like Jack Sprat and his wife, we complemented each other's preferences nicely. More importantly, by self-organizing we seem to have done a better job optimizing for everyone's happiness than we do it the old-fashioned way: by having some self-appointed ticketing agent decide where we ought to sit.

Why don't the other airlines do it this way?

More to the point, what can Southwest teach us about the organization of ideas? So often,w e try to do to ideas what United and USAir do to passengers: organize them according to some central notion of where they ought to sit. But what happens when we let the ideas organize themselves? It may sound like anarchy, but then again Southwest's open seating sounds pretty chaotic until you see it in action.

• |
• Permalink

A recent conversation with Brook Manville reminded me of a question that has been puzzling me for a while: Why don't philanthropic foundations think more about networks?

The traditional philanthropic model revolves around money. Foundations have it, and nonprofits need it. So the foundations give it to the nonprofits in the form of a grant. There's a lot more to it, of course, but that's the basic idea.

Money is important, but it's not everything. When I talk to friends and colleagues in the nonprofit sector, what I hear again and again is a desire for knowledge. A charter school in Oakland wants to know whether a particular after-school program is a good use of their limited funding. A clinic in Tanzania wants to know how to increase compliance with a malaria treatment regimen. A music school in Philadelphia wants to know whether it should invest in commercial software to manage its box office.

There are a lot of reasons why nonprofit executives are hungry for knowledge. They work on particularly stubborn problems. The sector is highly fragmented and specialized. The absence of a strong market mechanism and regulating institutions allow bad management practices to endure. But in the end, nonprofit executives are doing what executives in every industry do: trying to learn from the experiences of others to improve their own performance.

If there is one thing that we've learned from the Web 2.0 phenomenon, it's that interpersonal networks are extremely effective in addressing these kinds of knowledge needs. Nonprofit practitioners benefit enormously when they connect with other nonprofit practitioners doing the same type of work. If I'm trying to increase compliance with a particular drug regimen in Tanzania, it is incredibly useful for me to connect with other practitioners who have done (or at least tried to do) the same thing in other parts of Tanzania, sub-Saharan Africa, or the South Side of Chicago. I can learn from their successes and their mistakes, and dramatically accelerate my own learning.

This knowledge transfer is already happening, but not effectively. Face-to-face conferences are expensive and often logistically impossible. In the absence of good public sources of knowledge, personal networks are even more important than in the for-profit sector. But like all personal networks, they don't scale efficiently.

It's not hard to imagine a better way. I'm envisioning an online knowledge networking tool for nonprofits. Nonprofit executives could go there to join discussions, share and access documents, describe case studies, find experts, create affinity groups, etc. Think of it as a standing online industry conference for nonprofit executives. And you don't even have to get on a plane.

Somebody needs to host this party, and philanthropic foundations are the natural hosts. In the near-term, each foundation would create a site exclusive to its funded organizations. Being supported by a particular foundation would not simply be a matter of receiving funding. It would also include an invitation (and a corresponding obligation) to become an active participant in a network of practitioners. The more wisely a foundation invests, the more powerful its proprietary network would become. I could even imagine a time when grant renewal decisions were determined by the quality of a fundee's participation in the network, and when inclusion in a foundation's proprietary network became more important to nonprofits than the accompanying financial support.

Bill and Melinda, are you listening?

• |
• Permalink

One of the questions I get most frequently is: "If anyone can edit a wiki, how do you protect the organization from misinformation or, worse yet, from vandalism." So I was really happy to see the following paragraph in yesterday's New York Times article on Diplopedia, the State Department wiki for the diplomacy community:

What if someone creates disinformation or vandalism? Mr. Johnson was asked in Egypt -- a not-infrequent question when the topic of wikis comes up. He pointed out that unlike Wikipedia, Diplopedia does not allow anonymous contributors, so bad actors could be tracked down. He then observed, "There are plenty of ways to commit career suicide; wikis are just the newest one." (my emphasis)

Give that man a cigar! (That man is Eric M. Johnson from the State Department's eDiplomacy group.) Vandalism and misinformation may be legitimate concerns on public sites like Wikipedia, especially after high-profile missteps like the infamous Siegenthaler incident. Inside the firewall, however, it's a complete non-issue.

The difference is that inside the firewall, every comment, edit, blog post, and personal profile are automatically attributed by to the author by name--by real name, the name on your door plate, your email, your desk stationary, and your pay stub.

We all have many opportunities every day to flame each other, vandalize each other's work, and spread faulty or under-scrutinized information around the workplace. I could fire off a few choice emails or leave some nasty voicemails right now that would really upset some folks. Why don't I do it? Human decency, professional courtesy and, yes, a desire not to get fired, all have something to do with it. But it's not because I can't.

Until just a few years ago, most workers did not have access to tools which would allow them to mass-publish content to their peers. We now have that access in the form of blogs, wikis, discussion boards, personal profiles, and other collaborative tools. That's a big change. But it doesn't mean that basic standards and behavioral norms will suddenly fly out the window. I'm happy to see the State Department call that out for the myth that it is.

• |
• Permalink