I spoke about Enterprise 2.0 at the Collaborative Technologies Conference last week, and had a great experience.  The most interesting part of the session (for me) was kicked off by Rod Boothby, who said that his clients were asking him whether they should implement blogs or wikis for internal use.

I initially responded that there was really no need to make this choice.  After all, why wouldn’t a company truly interested in Enterprise 2.0 do both?  As the room kept talking about the issue, though, I came to see that it was a legitimate decision point, and one that opened up a really interesting question.

The decision between corporate blogs and wikis is most obviously one between individual and group authorship.  But it’s also one about policy as enforced by technology.  The policy in this case is whether person A has the right to change person B’s contribution.  Such a change is impossible with standard blogs, and is the default with standard wikis.  If a company implements blogs alone, therefore, it has a different set of collaboration policies than if it implements wikis alone, or if it implements both technologies.

Some wiki enthusiasts I’ve talked to are adamant that the technology should remain a blank slate —  a completely freeform collaboration environment.  The only ‘rule’ is complete equality:  anyone who can see the content can edit the content, any edit can itself be edited by anyone, and any edit can also be undone (or re-done) by anyone.  As I’ve discussed before, while this sounds like a recipe for anarchy it’s actually often a path to emergence.

The meritocrat in me adores this aspect of wikis, but as an observer of how organizations actually get work done I wonder if it’s going to be the right answer in the longer term.  

Sometimes technologists and/or business leaders impose structure on collaborations out of a reflexive and misguided desire for control.  But sometimes they do so because the work being done actually benefits from a bit of structure, even if it’s a lot less formal than a complete ERP-embedded business process such as  taking a customer’s order and shipping it from inventory.  

Bug tracking is a good example.  Coders use pretty sophisticated, and pretty structured, software to keep track of bugs as they crop up, to assign responsibility for them, and to clear them when they’re resolved.  And coders have also become pretty heavy wiki users in a lot of companies because wikis are great tools for bringing a lot of minds to bear on a thorny problem (as Eric Raymond said, "given enough eyeballs all bugs are shallow." ).

So should wiki software for coders include bug tracking functionality?  If it did, programmers wouldn’t have to use two separate collaboration tools —  one to report on bugs and one to collectively solve them.

This might not sound like a big deal and maybe it’s not, but collaboration tools can proliferate quite quickly.  I currently use email, IM, a calendaring program, a blogging engine, and a bunch of wikis.  It’s not possible for me to search or tag across all of them, there’s no good way to interlink their content, and I’ve had to get familiar with several user interfaces and command sets.

I think of all of these as tools to help me communicate and collaborate, and I don’t perceive any of them as imposing a lot of structure on me.  It would be beneficial to me if at least some of them were rolled into one platform.  And it would be beneficial for HBS as well, because fewer walled gardens means more emergence.

But this rollup of tools would mean that completely freeform and generic tools —  blogs, wikis, email —  would be combined with a group calendaring tool that did only a couple things and did them in a pretty structured way.  Most people, even diehard advocates of unstructured collaboration, probably wouldn’t have a problem with this.  But what if the collaboration environment also included some or all of the following?:

• A way to rate contributors, similar to eBay ratings or Slashdot karma
• The ability to conduct polls or collect votes
• ‘Official’ to-do lists kept and cleared by the project manager, boss, team lead, etc.  In other words, organization-level bug tracking.
• Approve-then-publish functionality that gave someone the authority to review collaboratively-generated content, then publish it to the Intranet, Internet, PR department, etc.  

None of these sound fascist on their own, and even when combined they don’t feel like they’d take all the life out of Enterprise 2.0.  But they would make the online collaboration environment less than totally freeform.  

The interesting trick for technology adopters, and for technology vendors who want to sell to them, will be figuring out the appropriate types and amounts of structure to include within platforms for unstructured collaboration.  I’m pretty sure the final form will be less than completely freeform, but (I hope) not too much less. 

In my MBA class this past semester I introduced the Enterprise IT (EIT) module about a third of the way through the semester.  I explained that we’d be studying information technologies that let business leaders impose new ways of working —  new processes — on their organizations.  To get them thinking about what lay ahead, I asked them something like:

"When should you deploy Enterprise IT?"

For the most part I got what I was expecting —  answers included:

"When you have to comply with regulations like Sarbanes-Oxley"
"When you want to be sure that a process is done the same way everywhere"
"When you want consistent data throughout the company"
"When current systems are legacy spaghetti."

One of my students was Polish, and so presumably had some experience with authorities imposing their ideas.  He said simply "When you’re sure you have the right answer."

This caught me up short because it was so true and so glaringly obvious, but I’d never thought of the issue that way.  Like a lot of people involved with EIT, I’d been carrying around the unexamined assumption that if smart people spent time thinking about how they wanted a business process to flow, they’d get it about right.  I’d seen this approach work so often in the EIT efforts I’d studied (for example, at Cisco, CVS, and Evergreen Investments) that I’d started thinking of it as the default for introducing new workflows.

But what if you don’t have any good idea what the new workflow should be?  Or you’re not sure what the critical considerations are?  What if you’re trying to do something novel, something for which EIT vendors don’t yet have good templates?

In these circumstances, do you simply have to take your best shot at pre-defining the right processes, then embedding them in Enterprise IT?  Or do you have to give up on the idea of  using IT to facilitate amorphous or highly innovative processes?

In their wonderful book The Social Life of Information, John Seely Brown and Paul Duguid make a distinction between the process — —  a cross-functional sequence of tasks that need to be executed in order and with efficiency —  and the practice.  A practice is a community of people who have something in common:  an interest, a job description, a body of expertise.  Whereas the process crosses borders, the practice stays within them.  

Seely Brown and Duguid argue that current corporate IT does a much better job supporting the process than the practice.  For the past dozen years, businesses interested in improving their processes have been able to select, adopt, and exploit ERP, CRM, SCM, eProcurement, and all the other flavors of Enterprise IT.  

Businesses interested in improving their practices, meanwhile, have had what?  Knowledge management systems were sold and bought on the promise that they’d strengthen communities of practice, but have had a dismal track record.  As I explain in my recent Sloan Management Review article, this failure stems in large part from the fact that KM systems presupposed (in other words, imposed) the structure of the knowledge they were intended to capture and disseminate.   They were in fact another flavor of EIT.  

So have any information technologies really helped foster communities of practice?  Adam Cohen’s book The Perfect Store covers the early history of the global phenomenon that is eBay.   Founder Pierre Omidyar believed deeply in fostering community, and in not imposing lots of process up front.  Cohen writes "Omidyar’s routine when he received an email with a complaint about another user was to respond to the author, send a copy of the email to the other person in the dispute, and tell them both ‘You guys work it out.’"  After doing this for a short time, Omidyar had the great insight make the discourse among community members, both positive and negative, part of the community itself.  The process of leaving feedback and the member ratings that are so central to eBay’s success are the result

I saw something similar when I studied Alibris, the online intermediary for rare, used, and out-of-print books.  The company started as Interloc, a simple inventory listing service for professional used bookdealers, who could post the books they had for sale and check if any of their colleagues had a book they were looking for.  Only after watching this technology support the practice of booksellers for over four years did Alibris executives decide to try to support the process of bookselling.  They  built an eCommerce engine and shut off the old listing service.  

The new system was clearly an EIT —  it assigned users into roles (e.g. buyer or seller), arranged tasks into sequences, assigned decision rights (for example, Alibris started monitoring fulfillment and gave itself the right to delist dealers with low fill rates), and increased all parties’ interdependence.  And it succeeded far, far better than most other independent eMarketplace / B2B exchanges.¹  Alibris learned about the process by watching the practice.  The practice was visible because it made use of what I call a Network IT platform, or an online forum where participants can engage in unstructured interactions.  

Two of the biggest NIT platforms on the Internet currently are Craigslist and Wikipedia.  Craigslist is almost certainly the world’s largest and most popular source of classified ads, and Wikipedia is the planet’s biggest reference work.  Finding fault with both of these platforms has become a cottage industry (and some of the critiques have merit), but the fact that they’re both enormous and continually growing should surely tell us something.  Either millions upon millions of people are being duped  by these two sites, or they’re demonstrating real value to their users.  I suspect it’s the latter.

From the start, both Craigslist and Wikipedia have benefited from and facilitated strong communities of practice.  And at their start both sites cared very little for process.  Like eBay and Alibris in their early days, they were largely freeform environments; they allowed people to come together, but didn’t tell them what to do once they got there.

Over time, however, the leaders of both Craigslist and Wikipedia decided that they needed to institute some processes.  As I used Craigslist a couple weeks ago to unload an old TV, I learned that I couldn’t post the same ad in both the ‘free’ and ‘furniture’ areas of the ‘for sale’ section.  I also learned that I couldn’t delete my ad then instantly re-post it in order to have it show up at the top of the chronological listing.

I was trying to game the Craigslist system in some of the most obvious ways possible.  And after watching countless similar attempts, the leaders of Craigslist decided sometime in the past that it wasn’t in the best interests of the site to allow such shenanigans, so they put in place some automated checks on the behaviors.  In other words, they watched the practice to learn about appropriate processes, then embedded these processes in software.  

Wikipedia has done precisely the same thing over its history, and it has also codified a lot of its rules in words, rather than in code.  Wikipedia has extensive sections on official policies, guidelines, and proposals that contributors can refer to.  It’s easy to contribute to Wikipedia without being aware of any of them; they serve primarily to settle disputes or questions that have come up repeatedly in the past within the community.  

So it’s clearly possible for a freeform online community of practice (what I call a pure Network technology) to evolve some processes (and so become something closer to Enterprise IT) without losing its soul.  What’s critical, it seems, is for the leaders of the community to observe it over time and keep asking themselves what rules, policies, constraints, workflows —  in other words, what processes —  would be helpful.

eBay, Alibris, Craigslist, and Wikipedia show how smart business leaders have migrated their organizations’ emergent structures to imposed ones.  The impositions aren’t abrupt or made in a vacuum; they’re done for demonstrably good reasons.  When the transition from emergence to imposition is managed this way there’s really little tension between the process and the practice.  In fact, they reinforce each other with when they come together with a bit of technology and a bit of leadership.

¹Alibris was sold to Oak Hill Partners in May of 2006.  It still operates as an independent eMarketplace for books.

As I’ve discussed here a few times, individual enterprises have a couple big advantages over the Internet as a whole as they work to encourage the use of new platforms for communication and collaboration.  Business leaders can shape their companies’ cultures and incentives to drive blogging, tagging, wiki contributions, podcasting, etc.  On the Web, in contrast, cultures have to be built from scratch (as this memoir from Larry Sanger makes clear, culture-building at Wikipedia has been intense, ongoing, and contentious) and incentives come mostly from within contributors themselves —  their desires to be altruistic or more productive.

The obvious big advantage of the Web over the enterprise is its massive scale.  With hundreds of millions of people online, it’s not too surprising that about 2000 of them have apparently devoted much of their lives to Wikipedia, becoming what that community defines as ‘very active users.’  Some other Web-wide platforms are also big enough to benefit from the power law of participation and so gain the benefits of emergence.

Another big advantage of the Web so far, and one that’s a bit less obvious, is the fact that its participants can choose their levels of anonymity.  As a New Yorker cartoon pointed out in 1993,  "On the Internet, nobody knows you’re a dog."  People can choose exactly how much they want to reveal about themselves as they participate in Web platforms.  It’s perfectly possible for me to maintain my anonymity and set up a blog, comment on others’ blogs, rise up through the ranks of Wikipedians, set up a MySpace page, look for a mate or a date on Craigslist, post a bunch of photos to Flickr, etc.  As I did all of this, any required communication could happen via email, IM, IRC, etc. using aliases that hid my true identity.

Of course, this is a huge double-edged sword.  Anonymity and the difficulty of ascertaining true identity are great boons to trolls, terrorists, spewers of hate speech, spammers, predators, hackers, and all the other folk who reverse network effects and reduce the Web’s value for the rest of us.    

The drawbacks of the Web’s anonymity are real, but so are its advantages.  Anonymity lets people express themselves without fear of reprisal, and without being subject to the possibly harsh judgments of their peers.  It can let them bring important truths to light and whistle-blow without fear of losing their jobs, demolishing their careers, or losing their standing in a community that means something to them (recall that Mark Felt was a high-ranking FBI official while he was acting as Deep Throat.).

It can also let them be several people at once.  Many people have interests wholly unrelated to their professional lives, and would prefer that the two not mingle.  It’s not that these outside interests are sleazy; it’s just that they involve different communities, different vocabularies, different norms, etc.  Web platforms can be a great way to participate in many separate communities without having them bleed into each other.

In short, online anonymity has its drawbacks, but it accelerates self-expression and the good that goes along with it.  But anonymity is very hard to come by inside the enterprise, and digital anonymity is close to impossible.  Let’s say I wanted to send our new Dean Jay Light a note telling him some things I think he should know about the burdens and oppression suffered by HBS junior faculty (this is a purely hypothetical example; we actually have a great working environment).  I’d want him to have confidence that the note actually did come from a junior faculty member here, but I wouldn’t want him (or anyone else) be able to trace it back to me; I’d want to be the Deep Throat of HBS.

So what would I do?  A paper letter or an email from a Gmail or Yahoo! account could have come from any Yahoo.  An email from my HBS account, however, immediately identifies me.  I don’t have any good way to digitally communicate within this community as a member of the community, but with anonymity.

Now let’s flip the problem around and imagine that Dean Light wants to get the most honest responses possible from the junior faculty (or the  research assistants, current MBA students, staff, alums, etc.)  on issues he considers important.  What would he do?  Have lots of one-on-ones?  Set up a suggestion box?  Set up a special-purpose email address?  And what if he wanted us to  be able to react to each other’s answers?  Would he set up focus groups facilitated by a third party?

Each of these methods would probably yield some useful results, but they all fall short of fostering maximum freedom of expression while at the same time ensuring that all contributions actually come from within the community.  

These two goals are actually not mutually incompatible.  In fact, they can both be easily realized with current tools.  The key is to include a third party into the mix in addition to the enterprise and its workforce. The role of this third party —  let’s call it a go-between — is to provide assurances to the enterprise that communications are actually coming from designated contributors while also assuring contributors that they’ll remain anonymous to the enterprise, and to each other.  

The mechanics are pretty simple.  If Jay Light wants to find out what the HBS junior faculty think about a set of issues, he directs the go-between to send each of us an email with instructions, a password, and a URL within the go-between’s domain name.  We go to the URL and enter our passwords.  We’re then assigned special-purpose usernames (something like ‘juniorfac1xx”) and given access to all the platforms (discussion boards, wikis, blogs, chat sessions, etc.) and channels (Web-based email) that Jay has set up.  If he wants us to see each other’s replies, he uses platforms; if he doesn’t, he uses channels.  We then fire away.  If he wants to follow up with any of us the go-between forwards his email to us and lets us reply using our special-purpose usernames.  

To reassure me that HBS couldn’t use its servers’ log files to find out who was saying what, I’d want to make sure that all my contributions were made within the go-between’s domain name.  And Jay would want to be sure that if anyone started using the platforms to post threats or harassments, then HBS could learn their true identity and take action to protect the community.  This implies that the enterprise, the workforce, and the go-between would have to agree in advance on a few rules of engagement.  And that we’d all have to trust the go-between to respect them.

In this scheme, the fact that true identities could be revealed would probably be enough to keep most people from using the go-between to pursue vendettas or launch personal attacks.  The role of go-between is tailor-made for software as a service.

I’m excited about Enterprise 2.0 because I think it allows legitimately new modes of collaboration — it lets people work together in ways that were just not previously possible.  The capability to have anonymous online contributions and dialogues within the enterprise is potentially a quite valuable addition to the Enterprise 2.0 toolkit.  This capability would let companies have difficult conversations even when there’s not a high level of what my colleague Amy Edmondson calls psychological safety —  "a shared belief held by members of a team that the team is safe for interpersonal risk taking."  IT certainly doesn’t make this shared belief any less important, but it can be a substitute for it in narrow but important ways.

It’s been exciting to watch awareness and discussion of Enterprise 2.0 spread across the blogosphere over the past few months.  The term appears to have taken root and started to blossom.  More importantly, the concepts underlying the term are being debated, refined, and propagated.  It doesn’t have a Wikipedia entry yet, and Google Trends says today that "Your terms – "enterprise 2.0" – do not have enough search volume to show graphs," but something tells me that this is just a matter of time.

Voices and Venues

I’ve learned a lot from reading what Ross Mayfield, Dion Hinchcliffe, Nick Carr, Peter Rip, JP Rangaswami, Sean Park, Ray Lane, John Hagel, Steve Eisner, and many others have had to say about Enterprise 2.0 and related topics.  Comments and trackbacks left here have also been highly valuable, and have introduced me to a lot of people and writing I would not have known about otherwise.

It seems that more and more conferences these days are including sessions, panels, keynotes, etc. devoted to Enterprise 2.0 topics.  The Gartner Symposium/ITxpo and reboot8 recently finished up, and coming up there are Wikimania, the CTC, Interop, the Web 2.0 conference, and certainly many others.  These events should help spread ideas and enthusiasm more widely, and I bet their Enterprise 2.0 sessions will be well attended.  I just gave a talk on the topic at the HBS reunion (for the classes that graduated 5, 10, 15, 20, and 50(!) years ago).  I was pleasantly surprised both by  the number of people who came and by their levels of engagement.  A lot of them were already experimenting with blogs, wikis, and other social software inside their companies.).

Emerging Consensus

In addition to topics I’ve posted on here, there seems to be convergence around a few other linked themes:

Enterprise 2.0 technologies don’t respect existing horizontal and vertical boundaries within organizations.  These tools don’t care much who you are or where you fit in the org chart.  In their pure form they accept contributions regardless of source and display them regardless of audience.  Many have pointed out that this is likely to make lots of people uncomfortable.  As Max Weber wrote over 80 years ago, "Every bureaucracy seeks to increase the superiority of the professionally informed by keeping their knowledge and intentions secret…Bureaucracy naturally welcomes a poorly informed and hence a powerless parliament—at least in so far as ignorance somehow agrees with the bureaucracy’s interests."  Knowledge and intentions both become more widely visible with Enterprise 2.0.

CEOs, CIOs, and users welcome this development.  I’ve given Enterprise 2.0 talks here at HBS to participants in our most senior executive education program, to owners and founders of their own small and medium-sized companies, to IT/IS managers, and to alumni.  Reactions from all these groups have been highly positive.  One of the owner/founders stopped my spiel, looked around the room, and said to his colleagues something close to "Hey everyone, if we trust our employees, and if we really do believe that they’re out most important asset, and if we think that we have a healthy corporate culture, then we have to do this stuff."  Lots of other postings I’ve read make the same point — that top managers and technologists want to deploy these tools.  

Some middle managers don’t. Weber’s quote probably applies most strongly to the population of middle managers who are used to acting as the main conduit for information into and especially out of their groups.  Prior to the network era, these folk could exercise pretty effective control over how the ‘rest of the world’ perceived their groups by filtering and selectively presenting information.

Enterprise IT like ERP reduced the ability of middle managers to control the flow of structured transactional information (how much inventory do we have?, how many orders did we ship last month?, how long did it take us to get paid?, etc.).  Enterprise 2.0 technologies threaten to do the same for unstructured knowledge-based information.  These technologies bring new architectures of participation.  As Mitch Kapor brilliantly said, "Architecture is politics."  And Ross Mayfield pointed out that Enterprise 2.0 overturns previously encoded political bargains.

Simpler is better.  A very thoughtful email I got from reader TR made a great point:  "Wikis/Blogs etc. are effective because they’re simple and people can get things done quickly. I know this is a simple point, and I know you’ve made it (when describing Wikis), but what if this point overwhelms all the others in significance?"  Indeed, what if?  I love writing about highfalutin concepts like emergence, but it’s important to not lose sight of the fact that people use these tools because they work for them, and they work in large part because they’re so easy to use.  We should all tape to our walls wiki inventor Ward Cunningham’s driving question:  "What’s the simplest thing that could possibly work?"  Doing so might help us overcome our innate desire to use technology to impose structure, and also help companies deliver IT more cheaply.

A Fault Line

Debate continues about whether Enterprise 2.0 is about new infrastructure or about new modes of collaboration.  I’ve tried to be very clear that to me it’s the latter, and not the former.  Enterprise 2.0, in other words, is about new communities, not communities’ new plumbing.  If we keep talking about the plumbing we’re going to lose the attention of business leaders.  And that would be a shame.