Tools & Technologies

Thoughts on Andrew McAfee's "The 9X Email Problem", Oct 14

Andrew McAfee, an Associate Professor at the Harvard Business School recently opined on The 9X Email Problem. In the melting pot were some thoughts from a marketing research seminar on consumer product adoption failure, groupware vs. Enterprise 2.0 and email vs. Enterprise 2.0, leading through to a call-to-action to Enterprise 2.0 provides to think about how to make their wares 9X better than email. I have some reflections and comments that I want to share about his thesis. You need to understand a couple of things in advance, however, mainly about the framework in which I’m writing this:

  • I’m not a Professor at Harvard Business School, nor have I had my work published in the Sloan Management Review. Thus Andrew has a greater aura by implication of his organizational affiliation and publications history. (LOL, I’m wearing the T-shirt I purchased from HBS in the pic on my blog!)
  • I have had a strong professional interest in all things collaboration-related since doing a Masters degree on collaboration technology in business in 1994.
  • I am absolutely fascinated by (or is that “obsessed with” … I got up at 4.30am on Saturday morning down here in NZ to write this) the idea that collaboration technology can benefit teams and groups, but do not subscribe to the concept that newer is always better. And I’m a huge fan of well-reasoned thinking that can withstand an informed cross-examination.
  • I don’t work for, nor do I consult to, IBM or the Lotus people. However, many of them are professional colleagues, and a number of them I count as friends (a statement which is equally true and valid for people in the Microsoft and Enterprise 2.0 communities). In terms of my work, I actually work for a competitor to IBM/Lotus.
  • Finally, adoption of new technology instead of what we call an email client today is an area that I’m thinking a lot about at the moment, and will being doing so for some time. This isn’t merely a passing interest for me. It fact, it is core to my professional existence.

Why does “Emergence” Trump Every Other Consideration?
Before diving into an analysis of Andrew’s argument, I need to detour to an examination of a term he advocates frequently: emergence.

In his May 14, 2006 blog post entitled The Mechanisms of Online Emergence, Andrew makes the following points:

… Emergence is the appearance of global structure as the result of local interactions. It doesn’t happen in most systems; what’s necessary is a set of mechanisms to do critical things like connect the system’s elements and provide feedback among them.

The Web’s emergent nature doesn’t stem from the fact that it’s a huge collection of digital documents; if the Library of Congress were digitized tomorrow and put on line, it would not constitute an emergent system. The Web is emergent because it’s the dynamic creation of countless people around the world interacting with each other via links as they create new content.

This is a key difference between the public Internet and private Intranets. Public Web sites are built by millions of people, while most Intranets are built and maintained by a small group. Emergence requires large numbers of actors and interactions, but Intranets are produced by only a few people (even though they are passively consumed by many.). In addition, most Intranet pages aren’t as heavily interlinked as pages on the Internet.

Another important difference is that Web 2.0 has accelerated the rate of emergence on the public Internet. I think of Web 2.0 tools and technologies as accomplishing two important goals: increasing the number of people who are contributing content (and the ease with which they can do it), and increasing the number of ways to let content creators (and consumers) interact with each other. These new interactions are the further mechanisms, beyond linking, for emergence — for letting patterns and structure emerge from low-level behavior.

I have two general comments to make on “emergence” as a concept when applied to enterprise settings:

  1. Limited applicability to the enterprise … Most enterprises don’t have enough people to permit the “emergence” that Andrew talks about. See slides 32-33 in my August 23 speech at a New Zealand conference where I examine the applicability of social bookmarking in small and medium-sized enterprises.
  2. Limited explanatory power for decision making in the enterprise … Emergence is definitely not the primary decision criteria for technology within a business enterprise; getting stuff done amongst a collection of actors is. If “emergence” helps, great. But it doesn’t reign supreme.

Does Notes Allow Structure to Emerge?

After I was done talking about the glories of Enterprise 2.0 at the New New Internet conference, one of the attendees asked how I could be confident that the new generation of collaboration technologies was going to succeed to a greater extent than had the previous generation of ‘groupware,’ the most popular version of which was probably Lotus Notes. I answered that groupware actually imposed a surprising amount of structure on people’s interactions, and that because Enterprise 2.0 technologies let structure emerge, rather than imposing it, they would be more popular. (paragraph 10)

I assert that Andrew is not considering the historical antecedents of groupware usage and development in the enterprise when he makes this statement, and by virtue of not doing so, the conclusion is wrong. At the point in time in which a “groupware” system is deployed, there is no “structure imposed” on the organization. That structure emerges over time as the people in the business appropriate the groupware technology to help them complete and fulfil the requirements of their jobs. If they’re given permission by IT to let that structure emerge, or if IT works side-by-side in the traditionally espoused IT-business partnership approach to do the same, then structures emerge over time that meet the working conditions and goals of a community / team / group. I think Andrew’s error is looking at a groupware deployment 5-10 years after it’s gone in and concluding that it has “imposed structure” … that’s blatantly untrue. If it was, then we’ll be having this same intellectual argument in another 5 years, by which time Enterprise 2.0 tools and technologies will have become ingrained into the work practices of current workers, and thus new hires will be expected to embrace it, and thus it will “impose structure” rather than letting it emerge.

For example, a groupware platform like Lotus Notes offers incredible capabilities for “structure to emerge”, in two complementary and robust ways:

  1. Emergent Structure in Content … A Notes application like a discussion database when first created is empty. There is no structure in content, in categorization (“tags”), in topics, etc. It all emerges over time through the contributions of the people involved. Ditto with a team workspace database … there’s nothing to start, but the content emerges over time as the community / team / group works on whatever project or end-goal they are engaged with. Given that this is the “emergence” of which Andrew speaks with respect to Web 2.0 technologies on the consumer Internet, I argue that his charge that “emergence” is not possible in Notes is without foundation.
  2. Emergent Structure in Design … A copy of Domino Designer, an understanding of “forms” and “views” via three chapters in a book or a two-day course, and the community / team / group can start with a structure that works on day one, and let it emerge over time as they figure out the nuances of what they want to emerge. With respect to adoption of this, it isn’t the fault of Notes that few enterprise IT departments at this juncture in history are willing for power end-users to have Domino Designer and to do their own development; that’s an IT department decision based on their professional experience about where and how to permit emergence to reign. From my perspective, it is unlikely to be any different with Enterprise 2.0 tools and technologies over time; I know this isn’t the perfect example (because it is drawn from the consumer Web 2.0 space rather than the Enterprise 2.0 space), but witness the increased structure that is being placed on Wikipedians. In the beginning, structure was able to emerge; over time there are more rules and procedures that impose on ongoing emergent structure.

In summary, I advance the argument that Andrew has taken an incorrect position on “emergence” in traditional groupware platforms like Notes, and encourage him to revisit his conclusions based on a re-examination of the underlying principles actually at play.

Why is “Enterprise 2.0” Clearly Different than Groupware?

In most companies, groupware didn’t solve the problem; it wasn’t that much better than email. The current generation of Enterprise 2.0 tools that I and other have been writing about is clearly different than groupware, and we believe it offers advantages. But that’s not really the critical consideration. The critical consideration is brutally simple: are these tools 9 times better than email for collaboration? (paragraph 13)

Let’s examine Andrew’s analysis and assertions.

With respect to groupware vs. Enterprise 2.0 …
From the professional experience I’ve had in the field, the research papers I’ve written and the research papers that I’ve read, I lend some agreement to Andrew’s assertion that “In most companies, groupware didn’t solve the problem“, but disagree with the reasoning that “it wasn’t that much better than email“. Groupware (eg, Lotus Notes, as that’s what Andrew has commented on) as an idea offers wonderful capabilities and in my view, has clear and understandable intellectual benefits over email assuming that (1) a clear case is established between the needs of a user community / team / group and what Notes has to offer, (2) there is someone who is tasked with iteratively fitting (helping with the “emergence” to use Andrew’s term) the design constructs of Notes to the community / team / group, and (3) the group is willing to engage and change their work practices.

As one example from the academic literature, look at the findings of Karsten (1999) (see also references below) in her review of 18 major case studies on the implementation and use of Lotus Notes in organizational and work contexts between 1992 and 1998. Karsten concluded that the best way to group the case studies was on “how the organizations approached the task of implementing Notes and their commitment to it” (p.48), and found three groupings:

  1. Exploratory, conservative or cautious use of Notes … provided minor consequences
  2. Well-planned core applications … provided restrictive but positive consequences
  3. Extensive use of Notes, with users taking an active role in incorporating Notes applications into their work … led to major organizational changes

Companies in Group 3 experienced the following benefits (with items #1 and #2 shouting “emergence” related to “groupware” … gosh!):

  • Countries became closer; colleagues learned about each other as individuals and started to converse in an informal fashion (p.56)
  • Application development was conducted as a careful process, with prototypes and user involvement (p.56)
  • Change processes were viewed as learning and development opportunities by the users (p.57)

Guess what? Exactly the same issues, potential downfalls and routes for success are going to be experienced by Enterprise 2.0 advocates. I don’t see the difference.

With Respect to Email vs. Groupware …
Andrew said that the failure of groupware in “most companies” was directly due to the fact that it “wasn’t that much better than email”. Let’s consider the evidence by looking deeper at some classic groupware applications and examining the viability of this assertion. Classic groupware applications that are clearly better than email are:

  • Help Desk for Issue Tracking and Closure … Users or help desk staff can fill out a trouble ticket, manually assign the item to an IT support person (or have that automagically done based on a matching between the attributes of the problem and the skills of IT staff), track the progress of the ticket through its lifecycle (and therefore make progress and problems visible to the many), and have rules-based escalation to ensure that service level agreements between IT and the business are met or exceeded. After the fact, the Help Desk manager or analyst can review what’s gone on via reports, and provide additional training to IT staff on problematic areas. You can’t do this merely with email and the lack of groupware database engine.
  • Workflow as Codification of Best Practices … Workflow applications have taken their share of heat for “imposing structure” on interactions between people, but get over it … the fundamental theory of workflow is to route work between people, according to a set of rules that have been developed (either unilaterally or in conjunction with group analysis), and thereby to help people tasked with making a business process happen be successful. At some point in time, the rules have to emerge. At some point in time, the rules have to be codified into a workflow. At some point in time, those rules will be tweaked or modified to handle “emergent” conditions. And over time, if the system is used well and “wisdom of the crowd” makes the rules better, the workflow system should approach best practice. A workflow system is going to seem “restrictive” to a new hire, but a more intelligent analysis of the history of the system on their part, and an ongoing willingness of the current owners to examine the rule engine when that makes sense, makes workflow (1) emergent, and (2) better than email. And finally, groupware platforms like Notes have for a long time permitted intelligent integrated between workflow databases and a user’s email inbox.
  • Threaded Discussion Forums … When used and adopted properly, a threaded discussion forum makes conversations clear to a group of people in a non-channelized way, provides an easier way of tracking what was said historically, and can even integrate with a user’s email Inbox through topic alerts that the user has requested.
  • Customer Relationship Management (CRM) … A collection of inter-related Notes databases can be used for customer relationship management amongst a community / team / group. One database can hold records for people, be linked to another one that holds records on opportunities, projects or interactions, which can be linked to another one holding records about potential suppliers, etc, etc, etc. These inter-linked databases can emerge over time as the community / team / group understand new / better things they want to do, and can even integrate with the email Inbox to remind people about upcoming action items or to summarize what has happened in the past hour or day. Although there are now commercial off-the-shelf (COTS) or commercial off-the-web (COTW) products that address CRM, (a) that hasn’t always been the case, and even then (b) they may not fit the enterprise IT architecture and strategy that has been set with respect to database platform, directory of choice, backup strategy, security strategy, and so on.

And that’s just four examples that I’ve commented on. A groupware platform like Notes gives you many opportunities to do stuff in a way that is better than email, whilst at the same time letting structure emerge. My conclusion: Andrew’s assertion lacks explanatory power for the so-called failure of groupware, and therefore can not be relied upon for predicting the success of Enterprise 2.0 in its stead.

Let’s look at the problem from the other direction: what are early adopters of Enterprise 2.0 technologies using these wonderful tools for, and are they different?

  • Socialtext provides wikis for the enterprise. One of its customers is Dresdner Kleinwort Wasserstein. Socialtext’s case study on the use of wikis at DrKW says that there are three popular uses of the wiki: for managing meetings (eg, creating the agenda in advance on a wiki rather than by email), brainstorming and publishing (random ideas that develop over time into a firm document), and creating presentations (for clients, drawing on the contributions of geographically-dispersed team members). I’m delighted for DrKW that they’ve found a collaboration technology that works for them, and I’m delighted for Socialtext that they have such a referenceable customer, but those are very simple things that Notes/Domino shops have been able to do for years and years and years. Conclusion based on these three data points: there’s no difference between the applications and uses to which Enterprise 2.0 tools are put vs. “groupware”.
  • Mike Radomski works at an organization that has recently embraced Atlassian Confluence for collaboration and knowledge sharing. Proffered uses are (1) internal and external system and database documentation, (2) meeting minutes, (3) a portal to “glue” other information systems together, (4) central calendaring, (5) conference summaries, and (6) more. As I said in my July 24 2.0 Report, “Sounds like standard stuff that Lotus Notes/Domino shops have been doing for the last 15 years or so … so what’s the big difference?“. Again, my conclusion based on these five data points: there’s no difference in use.
  • Rod Boothby wrote a series recently on the use of Enterprise Web 2.0 scenarios, and suggested that blogs could be used to create project pages for all new projects so as to (1) improve communication within the project team, (2) ensure others in the organization know what is going on within the project, and (3) build a searchable reference for future use. Again, as I said in my July 24 2.0 Report, “given that Rod works for a global firm that has a very large deployment of Notes/Domino, and that what he’s outlined can easily be done on that platform, why the push for something different?

With Respect to Email vs. Enterprise 2.0 …
In exactly the same vein in which I’ve examined email vs. groupware, I conclude that there are some areas in which email is better than Enterprise 2.0 applications, and equally some use cases where it makes more sense for Enterprise 2.0 applications to be used. Enterprise 2.0 applications do some things better, and some things worse. For example, the adoption of Enterprise 2.0 collaborative workspaces generally causes a proliferation of different spaces and places for people to check for new things, and thus an increased divergence of places where their work-related information is stored. There are precious few collaborative workspace products on the market today that in totality make things easier for the individual users vs. email.

In Summary
The intellectual problem I have with Andrew’s change that groupware didn’t solve the 9X problem and that Enterprise 2.0 is different and therefore might, is that “groupware” and “Enterprise 2.0” in my view are more similar than disparate in what the respective technologies clusters offer, and secondly, given that a groupware platform like Lotus Notes can currently be used to offer “Enterprise 2.0” point applications, I express less hope than he that inter alia Enterprise 2.0 will succeed where groupware has apparently not.

Channels and Platforms are both Needed; Not Either/Or

… As I wrote in my initial SMR article, email is a channel technology. It creates a private conduit between the sender and receiver. Other parties don’t know that the email was sent, and can’t consult its contents. Wikis,, Flickr, Myspace, Facebook, and YouTube, on the other hand, are all platform technologies. They accumulate content over time and make it visible and accessible to all community members.

Prior to the arrival of Enterprise 2.0 technologies, companies had few effective platforms for sharing knowledge work, and no platforms that fostered emergence. So the new tools are not direct substitutes for email; instead, they’re intended to provide capabilities that email can’t. Will they succeed? It depends heavily, I believe, on whether companies and their managers want technology platforms for collaboration. This desire will be an important factor in solving email’s 9X problem. (paragraphs 21-22)

Kudos and high praise for the various technologies on the market today–eg, email, instant messaging and telephones–that create a “private conduit” between the sender and receiver. Long may they continue to exist and prosper! Not every conversation or piece of information is for public disclosure; channels for private discussions and ruminations and thinkings are absolutely essential today and into the future. What Andrew paints as a huge negative, that “other parties don’t know that the email was sent, and can’t consult its contents” is a huge benefit of using email where such privacy is required.

Unlike Andrew, I flatly disagree that “prior to the arrival of Enterprise 2.0 technologies, companies had few effective platforms for sharing knowledge work, and no platforms that fostered emergence“. As I’ve already argued in this response, that is absolutely false assertion, and makes Andrew appear as the very “Enterprise 2.0 shrill” (I can’t find the link) he once said he doesn’t want to be. Such platforms have been around for ages under the terms “groupware” or “collaboration technology”, and a flat dismissal of such historical products and platforms does nothing to provide intelligent guidance to IT decision makers and CIOs in these current times.

In reflecting on my response above, these are the points that stand out to me:

  • The collaboration-fostering capabilities of Enterprise 2.0 are nothing new. Such capabilities have been around for over a decade, under various product names and genres. Flatly dismissing what went before in favor of the new-new thing is unwise for those in organizations who are tasked with making intelligent decisions about how to help knowledge workers do their stuff well.
  • Whilst “emergence” is a nice concept, it’s not the be-all-and-end-all. And regardless, Andrew is wrong in advancing the position that only Enterprise 2.0 point solutions and/or platforms offer “emergence” capabilities; Lotus Notes, a platform he writes off, has offered such emergence capabilities since its first release onto the market.
  • Both email and “collaboration” offerings are needed. It’s not an either/or.

Karsten, Helena (1999), Collaboration and collaborative information technologies: A review of the evidence, The DATA BASE for Advances in Information Systems, 30 (2), see ACM Digital Library (subscription required to download PDF)

Categories: Tools & Technologies