Getting Kind of Hectic

The top story of the latest (February 26) issue of InformationWeek is about Enterprise 2.0, and contains a lot of very interesting information.  The headline of the main story is "Most Business Tech Pros Wary About Web 2.0 Tools In Business: ‘Enterprise 2.0′ must overcome concerns about security and return to get a foothold in business, InformationWeek Research Finds." but I find most of the content decidedly less pessimistic than this headline.  Related stories examine mashups, offerings from major IT vendors, ways to get started, the problems with email and "Why we like the ‘Enterprise 2.0′ label."

Also today in Computerworld is a story on the Defense Intelligence Agency’s use of E2.0 tools like blogs and wikis.  I wrote earlier about the great New York Times Magazine story on the same topic.  Since then, it appears that momentum has been building.  The Computerworld story contains the assertion from Lewis Shepherd, chief of the DIA’s requirements and research group at the Pentagon, that "Across agencies, wikis and blogs are becoming as ubiquitous as e-mail in terms of information sharing."  Wow.

I’ll write later with more detailed reactions to this new content.  Let me just note for now that these stories are all about the use of new collaboration, information sharing, and personalization technologies, not about how these technologies are developed or how they’re delivered to users. In other words, they’re using something close to the relatively narrow definition I proposed of Enterprise 2.0.  As I wrote earlier, E2.0 defined this way engages business executives, managers, and users rather than causing their eyes to glaze over.

What do you think of the InfoWeek and Computerworld stories?  What did you learn?  What did you strongly agree or disagree with?  And what other required reading on this topic have you come across recently? Leave a comment and let us know.

 

   

Lots of students come to my office to talk about ideas for cool and useful technologies.  Very few walk in and show me one.

Abraham Murray and Tijan Watt, two second year HBS MBA students, have developed an intriguing technology.1  It’s called Doodleboard, and it’s a multimedia online whiteboard.  This is freeform collaboration taken to its logical extreme; users can draw, type, upload and paste images, insert shaped, and include links.  It’s also synchronous, so several people can work together and see each others’ changes in real time.

Its inventors describe Doodleboard as follows:

"Doodleboard is an innovative web startup led by a pair of
Harvard Business School students. Doodleboard is an infinite, real time and
multi-user whiteboard written in AJAX. The hosted web application allows
multiple users to directly collaborate in the same shared whiteboard. Users
can add text, shapes, images, or draw directly on the board, and changes are
immediately synchronized among all users. A simple use case might involve a
project manager annotating a screenshot of an application under development
so that contractors understand the changes desired. The company recently
launched their public alpha. For more information you can visit
www.doodleboard.us or read their blog. Also, check out their screencast."

I can imagine many enterprise uses for this technology, on its own and as a complement to other collaboration technologies.  

Abe and Tijan would love to have people visit their public beta, experiment with Doodleboard, and share their thoughts and comments.  Please do!


1I’m supervising Abe and Tijan on their field study this semester, but have no financial interest in their venture.

 

Tear Down These Walls!?!?

Euan Semple responded to my last post with his trademark blend of acuity and courtesy, and I’m glad to see that he thinks we’re violently agreeing; I do, too.  His former colleague at the BBC John Howard also responded via a comment to my post, which is worth reproducing:

Andrew I think your worries over walled gardens are over cautious. These sorts of tools (if you choose the right ones!) all produce RSS and are driven through a browser. Data no longer sits in a database hidden behind an opaque data access layer, it’s available as RSS and URLs, and can be linked too. To really make this stuff fly in an organisation you need an aggregation tool to close the loop.

Howard’s comment highlights an excellent question:  what’s the real problem if some E2.0 environments are mutually inaccessible walled gardens?  If, for example, I’m a member of three distinct corporate wikis, each of which is accessible only to its members?  If I work in sales, which has set up an internal ‘blogosphere’ open only to the sales staff, and also for the North American division, which has done the same thing?  After all, as Howard points out, my RSS reader will let me know when anything of interest has changed in any of these environments, and my browser will let me skip among them with no effort at all.  So how big a deal is it that these environments are walled gardens?

The only honest answer is that we don’t really know yet, and maybe this kind of technology Balkanization will turn out to be no big deal within enterprises.  But I can think of two reasons why it might be a problem, or at least sub-optimal.  First, if employees can’t search, link, and tag across all Intranet content, then emergence —  the appearance of high-level patterns and structure as the result of many low-level interactions —  is limited.  

On the Internet if we can see it we can link to it, and that link is useful to everyone thanks to the PageRank algorithm and its cousins.  It’s the same with tagging, thanks to Del.icio.us.  These low level interactions give rise to an elaborate and emergent Web-wide structure. People realize how important these structuring interactions are, as evidenced by the recent controversy over Wikipedia’s decision to make its internal links ‘no follow.’  

If an Intranet consists largely of mutually inaccessible E2.0 environments, how does the cream of the content rise to the top?  How does any employee know where the best stuff is?  Even if the Intranet’s search capabilities were advanced enough to keep track of all employees’ access rights and show them results from all the content they were allowed to see, and only that content, the quality of these results would still be impaired.  It would be impaired because there are by definition fewer low-level interactions (links, tags, etc.) across several walled gardens than within a single one; the whole point of the wall is to keep such interactions from happening. So I don’t see how a Balkanized Intranet can display as much emergence as a single E2.0 platform can.  Is this a big deal?  We’ll have to stay tuned.

The second reason that walled gardens are sub-optimal has to do with an phenomenon that my colleague Karim Lakhani calls ‘broadcast search.’  This is simply the process of asking the world to help you find a solution to your problem.  It’s an old technique; the English government used broadcast search early in the 18th century to solve the problem of finding a ship’s longitude at sea.  Parliament offered the equivalent of about $12 million to anyone who could ‘find longitude.’  The prize was eventually won not by a famed astronomer or scientist of the day, but by the self-taught Yorkshire clockmaker John Harrison.1

As this example illustrates, it’s advantageous to broadcast your search as broadly as possible, because you don’t know in advance who’s got the relevant knowledge to help you solve your problem. So assuming there are no confidentiality issues, why would you post your problem only on the lab wiki when you could post it company-wide?  

And why wouldn’t you do it as visibly as possible so that others could benefit from the knowledge generated? My students this semester have started using our course wiki to ask and answer tech questions.  So far, these range from somewhat geeky —  how do I keep a bot from harvesting email addresses from websites I maintain —  to the fairly basic —  what is RSS, and how do I use it?  So far, every one of them has been answered quickly and well.  What’s more, now everyone who cares to look knows what RSS is and where to download a reader.  So a ‘normal’ search process for answering this question would have made one person smarter; the broadcast search process made as many as 80 people smarter.

None of the above, of course, implies that there are no good reasons to have a walled garden.  Sometimes a team wants to collaborate in private, for very good reasons.  JP Rangaswami, when he was the CIO of DrKW, put in place what I thought was a very smart policy:  he deployed a single, public, bank-wide E2.0 environment, then built private environments by request.  This probably isn’t the universally optimal policy, but it does illustrate that there are ways to address the tensions between the benefits of commonality and the desire for privacy.

How else is this tension being managed?  How is your organization grappling with the issues of E2.0 Balkanization and walled gardens?


1Dava Sobel’s wonderful book Longitude tells the story of Parliament’s broadcast search and Harrison’s improbable solution.   Harrison’s original timepieces have been restored and are on display and running in the National Maritime Museum outside London in Greenwich.  Many readers of this blog will be enthralled by them.  In addition to being fundamentally important pieces of technology, they are also beautiful.

In my morning keynote at last week’s FASTForward conference I stressed the criticality of senior management involvement in Enterprise 2.0 initiatives.  I do this in all of my teaching, consulting, and expounding on the topic because my experiences have shown me that simply deploying the new tools of freeform digital collaboration and expecting Web 2.0 dynamics to appear behind the firewall is a very poor strategy.  I often use the shorthand "If we build it, they will come" to describe this strategy, then talk about why it doesn’t work and what managers, especially top managers, need to do to encourage Enterprise 2.0.  

I argued in my keynote that Enterprise 2.0 technologies are going to have the effect of making companies less alike, even though the technologies themselves are cheap, widely available, and straightforward to install.  This apparently paradoxical result stems from the fact that even though the ‘raw materials’ of E2.0 — the tools themselves — are easily obtainable, the ‘finished goods’ of E2.0 — an Intranet that has lots of the desirable properties of the Internet, yet few of its drawbacks —  are valuable, rare, inimitable, and non-substitutable (the so called ‘VRIN’ attributes).  The job of management, I said, is to lead the work of converting these raw materials into finished goods.

At a lunchtime discussion that same day, I heard a very different view.  It was articulated most clearly by Euan Semple, who has a great deal of street cred on the issue.  Euan was a key figure in the BBC’s sustained and apparently quite successful E2.0 efforts, and now helps other organizations articulate and execute their new visions for collaboration and knowledge sharing. It was a real pleasure to meet him and hear what he had to say.

This pleasure was mitigated a bit when I heard Euan disagreeing with some of the key points I’d tried to make in the morning speech (although he made his points very gracefully, and without any sharp elbows).  In particular he stressed that senior management could really screw up E2.0 efforts by intervening in them too forcefully, too early, too often, or in too hamhanded a fashion.  He described one of his tasks at the BBC as providing cover for the nascent E2.0 initiatives and protecting them from too much ‘management.’  As he talked I recalled the great Dilbert cartoon in which his pointy-haired boss appears behind him saying "I’ve decided to be more of a hands-on manager," then gives directions like "Move the mouse… up… up… over… more…  NOW CLICK IT!! CLICK IT!!"  Clearly, this is not what any of us want.

As I listened to Euan and others during our discussion I heard a few key points:  

  • E2.0 efforts can and do succeed when they’re bottom-up rather than top-down.  If they’re bottom-up they’re more likely to be in response to a real and immediate business need, as opposed to being an abstract good idea or headquarters desideratum.
  • E2.0 efforts can lose their cachet or ‘cool factor’ when they enter the mainstream. They’re not pirate radio any more; they’re corporate rock.
  • Official E2.0 deployments often come with so many policies, procedures, guidelines, codes of conduct, and warnings (both explicit and implicit) that they choke off any real activity.  For example, many of us have seen long, formal policy statements on employee blogging that read as if they could be reduced to one sentence:  "We really don’t want you to blog."
  • E2.0 initiatives are delicate experiments, especially in their early stages, and they can easily be derailed by clumsy intervention even if it’s well-intentioned.
  • You can’t impose self-organization.

These are excellent points, and I agree with all of them.  But as I listened to Euan talk about what did at the BBC and elsewhere, his activities sounded a lot like the managerial work I’d outlined earlier in the day:

  • Coaching
  • Rewarding
  • Leading by example
  • Setting expectations, norms, and practices
  • Building culture

So perhaps we’re really not far apart after all.  In fact, as the head of Knowledge Management at the BBC, I’d say that Euan actually was a senior manager.

In addition, one of the reasons I emphasize the role of top managers is that in some cases middle management will be hostile to the approaches and tools of E2.0.  As I wrote earlier, not everyone wants information and knowledge to be widely visible and flow freely within an organization, because they have something to hide or because they gain power, centrality, or status by acting as a gatekeeper.  A coalition of top managers and front-line knowledge workers is often the best coalition to do battle against such turf-protectors.

Finally, the main problem I foresee with a bunch of discrete bottom-up E2.0 initiatives is that they can easily become a set of mutually inaccessible walled gardens (in fact, this might be the default outcome).  When this is the case, the Intranet is not like the Internet; instead, it’s like a set of discrete and unconnected Internets, each of which must be separately navigated, searched, tagged, etc.  The Internet is phenomenally valuable to us because there’s only one of it —  one vast and constantly growing web of information that we can skip around with ease thanks to its densely interconnected structure, one that (like a geodesic dome) gets stronger as it gets bigger, and one that displays emergence.  Perhaps the best reason for an organization, especially a larger one, to insist on a single E2.0 environment, and to impose its technical standards (but not its content) is to create the conditions for an Intranet that has all these properties, or at least a real shot at attaining them.

What do you think?  What are the drawbacks and advantages of top-down and bottom-up support for Enterprise 2.0?  And how different are they, really?

I spent Thursday and Friday last week in San Diego at the FastForward conference.  The conference’s blog became a repository for thinking around Enterprise 2.0 in recent weeks, and I’m pleased to report that the event itself did its website proud.  I unfortunately missed Ray Lane and his keynote, but I did get to meet many people whose work I’ve been admiring for a while, including Tim O’Reilly, Dave WeinbergerEuan Semple, David Lavenda, and Adam Carson.  I also got to catch up with (among others) Rod Boothby, Kathleen Gilroy, my former student Joyce Haas (another MBA with a great geek job), and my colleague on the DrKW and Zara cases Anders Sjoman.

I participated in three sessions at FastForward:  a keynote speech in the morning, a lunch at which Jeanette Borzo and I discussed with attendees the results of an Economist Intelligence Unit survey on Web 2.0 awareness among senior corporate managers, and an afternoon roundtable with about 30 very well-informed and opinionated attendees.  Even though the first of these involved speaking to about 1000 people, it was by far the most comfortable because it was a one-way flow of ideas.  

The latter two events, in contrast, involved a great deal of back and forth.  And they caused me to start rethinking some of my most deeply held convictions about Enterprise 2.0.  The next few blog posts will discuss the challenges posed by others’ experiences, viewpoints, and arguments to my own, and the resolutions and conclusions I’ve reached so far as I’ve tried to digest what I learned at FastForward.  

I want to start by recounting a discussion I had with Tim O’Reilly that struck at the very heart of what I mean by Enterprise 2.0, namely my definition of it.  As I posted here earlier, my definition is:

Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.

Social software enables people to rendezvous, connect or collaborate through computer-mediated communication and to form online communities. (Wikipedia’s definition).

Platforms are digital environments in which contributions and interactions are globally visible and persistent over time.

Emergent means that the software is freeform, and that it contains mechanisms to let the patterns and structure inherent in people’s interactions become visible over time.

Freeform means that the software is most or all of the following:

  • Optional
  • Free of up-front workflow
  • Egalitarian, or indifferent to formal organizational identities
  • Accepting of many types of data

Tim coined the term ‘Web 2.0′ and his conversation with me and remarks to the audience at FastForward reinforced his most recent definition of the term:

Web 2.0 is the business revolution in the computer industry caused by the move to the internet as platform, and an attempt to understand the rules for success on that new platform. Chief among those rules is this: Build applications that harness network effects to get better the more people use them. (This is what I’ve elsewhere called "harnessing collective intelligence." )

Tim is entirely correct about the importance of network effects and collective intelligence within Web 2.0, and therefore also within Enterprise 2.0.  Every Web and Enterprise 2.0 application I can think of gets better as more people use it.  So is my definition above at best incomplete and at worst inaccurate?

Definitions of constructs like Web 2.0 and Enterprise 2.0 are hard because to be useful they have to be short (no one’s going to read or refer to a one-page definition) yet they also have to convey what’s important and distinctive about the construct —  what sets it apart from other related terms.  And as I was working to define E2.0, I felt that network effects weren’t the key differentiator.  Email, Web 1.0, and virtually all communication technologies, after all, are subject to network effects; they all become more valuable to each user as the number of users increases.  

So my definition instead emphasizes another ‘rule for success:’ the use of technology platforms that are initially freeform (meaning that they don’t specify up front roles, identities, workflows, or interdependencies) and eventually emergent (meaning that they come over time to contain patterns and structure that can be exploited by their members).  I continue to see these as the key points of differentiation between E2.0 technologies and previous corporate collaboration and communication tools.  Email is a channel, not a platform; groupware is not freeform and typically not emergent; and knowledge management systems were essentially the opposite of freeform —  they presupposed the structure of the knowledge they were meant to capture.  

My definition is an attempt to highlight these differences, and to point users, managers, and technologists to three key groundrules for establishing Enterprise 2.0:

  • Build platforms, not channels
  • Make sure they’re initially freeform
  • Build in mechanisms for emergence.  These mechanisms include links, tags, powerful search, and in the case of prediction markets prices and bid/ask spreads.

Tim’s definition, it seems to me, provides insight on another critical topic:  how to make sure that Web 2.0 and Enterprise 2.0 technologies continue to deliver value over time.  My definition stresses emergence, but doesn’t acknowledge the fact that a 100 person wiki will display more of it than a 10 person one, or even than 10 separate ones with 10 members each.  Tim’s emphasis on network effects highlights the importance of common platforms rather than fragmented and mutually inaccessible ones, and also reveals a ’secret ingredient’ for platform designers:  make sure your offerings get better as more people use them.  This will turn people from mere users into evangelists, and from fragmenters into unifiers.

I’m not going to alter my Enterprise 2.0 definition, because I don’t think that network effects are the key differentiator between E2.0 techs and those previously available.  But I am going to recommend that everyone interested in these technologies should repeat "Enterprise 2.0 is subject to network effects" as a mantra and thank their guru Tim O’Reilly for giving it to them. 

Wikipedia (B)

A few people have commented that the Wikipedia case Karim Lakhani and I wrote (available here under GFDL) doesn’t resolve the issues it raises, and has an abrupt ending.

This is as intended.  HBS cases read often like journalistic narratives, but their goal is to stop well short of telling the whole story.  Instead, they aim to tee up a set of issues to be discussed in class.  If the case itself resolved all those issues, there would be little to talk about.  So we try to write them so that they lend themselves to good in-class discussions.  

To facilitate these discussions we faculty assign a set of assignment questions along with the case.  We ask students to read the case with these questions in mind, and to come to class prepared to talk about them, presenting their analyses, conclusions, points of view, justifications, recommendations, etc.

Here are the assignment questions I’m planning to ask my MBA students when I teach the Wikipedia case later this semester:

  • If you were the administrator who volunteered to close out the Articles for Deletion process about the "Enterprise 2.0" article, what would your decision be?  What tools, if any, do you have to make sure your recommendation is followed? 
  • Peruse a few Wikipedia articles on subjects where you have some interest or expertise.  What do you think of them?  Are they thorough?  Accurate?  Useful?  Across all of them, how even is the quality?
  • How do Wikipedia’s processes for creating and modifying articles ever lead to high-quality results?  How much do the encyclopedia’s policies and guidelines help?  What ensures that a contributor will follow them?
  • What are the most important differences between Nupedia and Wikipedia?  Why did Nupedia generate so few articles, and why does Wikipedia generate so many?
  • Are you a Wikipedia deletionist, inclusionist, or something else?  Why is this your philosophy?
  • Do you agree that at the time of the case Wikipedia is a bureaucracy?  Why or why not?

I’ll let you know how the class goes…

 

Powered by Wordpress