Andrew McAfee’s Sloan Management article defining Enterprise 2.0 is available for download, so I took the opportunity to reread it, after a recent chat over coffee with Jordan Frank of Traction Software.
The article, at least. MIT Sloan Management Review, with support from IBM, is making a set of ‘classic’ (thanks!) articles freely available to all comers. So the full text of my original SMR article “Enterprise 2.0: The Dawn of Emergent Collaboration” can be downloaded here.
I don’t know if this is a temporary or permanent arrangement, so I’d suggest acting quickly.
One of McAfee’s central arguments is on the importance of emergence in successful Enterprise 2.0 initiatives. Here’s the way he puts it:
Second, the technologists of Enterprise 2.0 are trying hard not to impose on users any preconceived notions about how work should proceed or how output should be categorized or structured. Instead, they’re building tools that let these aspects of knowledge work emerge.
This is a profound shift. Most current platforms, such as knowledge management systems, information portals, intranets and workflow applications, are highly structured from the start, and users have little opportunity to influence this structure. Wiki inventor Cunningham highlights an important shortcoming of this approach: “For questions like ‘What’s going on in the project?’ we could design a database. But whatever fields we put in the database would turn out to be what’s not important about what’s going on in the project. What’s important about the project is the stuff you don’t anticipate.” [p.25]
In an accounting or ERP system, the system’s designers specify all aspects of workflow, database design, and information structure in advance. Users are expected to select from among pre-defined choices and enter only such data as the designers have provided for. In designing a system for emergence, the designers leave a number of these decisions open; waiting for users to fill in the blanks. So, for example, instead of locking down a taxonomy for categorizing documents, the designers might provide a tagging system to allow a folksonomy to emerge from the idiosyncratic choices of each user.
The attraction of emergence is twofold. One is the realization that conventionally structured approaches have generally failed when tackling knowledge intensive problems. Knowledge work and knowledge workers don’t mesh well with the structuring techniques appropriate to industrial work.
The second is the perceived success of emergent approaches behind current Web 2.0 success stories on the Internet. It’s easy to see the power of emergence in such examples as flickr, facebook, and technorati.
Transplanting those experiences inside the boundaries of the organization is no simple task. What works at the scale of the public internet may not generate sufficient momentum within the confines of a single organization. Moreover, Internet success stories ignore or gloss over the failures and also-rans. Failure in the market is tolerated in ways that don’t translate well inside organizations.
You want the energy and creative outcomes that can come from a successful emergent approach, but you can’t simply rely on unaided market forces to fuel the process. “Unaided” is the key notion. Emergent successes in the market benefit from scale and viral strategies, but they don’t happen by accident. For starters, there is a marketing strategy and plan that exists in parallel with a technology implementation plan.
Enterprise 2.0 efforts within organizations also need a marketing plan to accompany their implementation plans. Like any marketing plan, this plan must identify and characterize its target market of potential users. In particular, the plan needs to identify those potential users who are most likely to benefit from the new capabilities and whose successful use of the technology will be interpreted as an endorsement to be emulated.
Is a marketing plan, by itself, sufficient to allow the other aspects of an Enterprise 2.0 implementation to emerge from use? Appropriate scaffolding and careful seeding of content will prove more useful. A complete taxonomy, for example, may overwhelm a small set of potential early adopters. On the other hand, an empty tagging system will prove too much of a blank slate for users more accustomed to the structures of conventional systems. Providing a sample of suggested tags or categories coupled with some live content can point users in the right direction.
Supporters and early adopters will also benefit from coaching and mentoring on how to use selected technologies to accomplish their goals. This coaching would focus on working out strategies for how to use the technology to accomplish specific business and organizational goals. This requires a different kind of engagement between the implementation team and the target user group. In particular, it entails introducing the user population to key design questions and issues that would typically have been dealt with by the implementation team.
In some respects, “emergence” is a fancy organizational development word for “messy.” The more our systems must deal with the complexities of the real world, the messier they must be to accommodate that messiness. Large scale organizations in general, and IT organizations in particular are not generally comfortable with messiness. Calling it emergence helps. But the fundamental need is to acknowledge that it is more useful to learn as we go and build our systems accordingly, than it is to force fit these systems into structures that cannot contain them.
