The Yin and Yang of Enterprise 2.0, the scruffy-neats, and INNATS

The success of user generated content sites and communities such as MySpace, Wikipedia and the Blogosphere leads many to question the merit of imposing any structure on collaboration. Leading thinkers like Jim McGee and Bill Ives recently offered their ideas and sought opinion from others on the FASTForward blog.

Bill asks whether To Align or Not to Align? How Structured Should Enterprise 2.0 Initiatives Be? He notes "I never saw a knowledge management or collaboration effort succeed with the ‘let’s build it and see what happens’ approach." But later on in the post, Bill points to the benefits of allowing for individual creativity, fueling the growth of communities ranging from MySpace to individual employee blogs at IBM. He concludes "If a firm had the resources and commitment, a dual implementation strategy would make sense."

Jim McGee charts The Newest Battle Between the Neats and the Scruffies:

The technologies of blogs, wikis, and social media that collectively comprise the emerging notion of Enterprise 2.0 celebrate scruffiness as the essence of success in knowledge-intensive enterprises. The claim, backed by appropriately messy and sketchy anecdotal evidence, is that a loose set of simple technologies made available to the knowledge workers of an organization can provide an environment in which the organization and its knowledge workers can make more effective use of their collective and individual knowledge capital. Grass roots efforts will yield value where large-scale, centralized, knowledge management initiatives have failed.

Jim admits to starting life as a Neat, but over time he is slowly converting to the Scruffy camp. The change follows his witnessing the power of grass roots efforts to outperform the imposition of structure in the form of detailed taxonomies and expensive KM and collaboration platforms developed in the last decade.

But Jim hasn't entirely let go of the Neats. And maybe that's the important point.

Yesterday, I posted a case study about an IT project team at ShoreBank. The group achieved wiki fast overnight adoption. Their experience doesn't differ much from other high performing case studies with use cases as diverse as Competitive Intelligence in the Pharmaceutical industry and Test and Evaluation in the US Department of Defense.

A basic label structure for the team in the ShoreBank case provided a framework and set of expectations to set the group on a path of sharing meeting notes, status reports, issues and other material that relate to given milestones. The goal of their collaboration is, therefore, well understood and easily followed, but not limited in any way.

The key was the provision of "just enough" structure in the collaborative environment, along with freedom and flexibility to be creative with content structure through the use of labels, links and content display. The success emerges from the Yin of Coordinated Collaboration and the Yang of Collaborative Creativity, with provision for the chaos with which we experiment and learn.

Andrew McAfee recently wrote an entry titled "It's Not Not About The Technology (INNATT)" to explain how technology alone can't solve problems but that INATT (with one Not) "denies that there can be improvements, incremenmtal or radical, in the ability of technologies to accomplish important goals." Technology is a critical ingredient, especially, he says "as the IT toolkit available to help with collaboration, innovation and knowledge sharing has recently become a great deal richer and better."

As pundits and consultants argue for INATT, they also argue for INATS, pointing to a few examples like Wikipedia as their benchmarks for a structureless approach. But, in fact, as I have argued in the past, See Best Practice and the Wikipedia Big Brain, Wikipedia actually has overbearing structure. So, as McAfee argues for INNATT, I argue for INNATS: Its Not Not About the Structure.

The Scruffy approach says Knowledge work isn't predictable, but starting from scratch every time devalues the very point of knowledge: to learn and adapt our processes in order to perform faster, produce better products, and improve our livelihood. Otherwise, we would all be caught in the stone age, re-inventing the wheel. Structure, however minimal, is an essential seed for progress.

A hybrid approach leverages what we learned, while offering the creative room to solve new problems and develop new and better ways of structuring our collaborative work.