Understanding Enterprise 2.0 Tolerances & Scale

We're at an interesting intersection in the collaboration world where projects both large and small tend to be discussed with the same terms. This can be very confusing to the lay person since it's hard to know what sort of scale is being described.

We're at an interesting intersection in the collaboration world where projects both large and small tend to be discussed with the same terms. This can be very confusing to the lay person since it's hard to know what sort of scale is being described.

Small and medium business needs are typically very different to 'enterprise', which in general business usage tends to refer to companies with over one hundred million in revenue. This can also be misleading however since many 'enterprises' are in fact federations of autonomous smaller business units.

As I've discussed previously, planning at an appropriate scale and for anticipated growth or shrinkage is critical to the success over time of a collaboration environment. It's relatively trivial these days to set up a 'software as a service' browser based, pay-as-you-go collaborative environment, and/or on premise wikis, but driving efficient uptake and usage is a much more substantial task.  Technology, while not trivial, isn't really the issue: culture change is.

I've had the pleasure of participating in two Enterprise 2.0 conferences in the last couple of weeks in the USA and Europe respectively, and some ubiquitous patterns have emerged for me from those experiences.

The European Enterprise 2.0 scene is a Ginger Rodgers to the USA's Fred Astaire: Europeans are doing everything the US is doing but backwards and in high heels, or rather also in multiple languages and cultures. Although English is the lingua franca of international business online, providing compelling reasons to persuade participation in European online collaboration can be culturally more challenging than in the English speaking US and UK.

(Asian cultures, with fundamentally different language character sets on top of huge cultural differences, are an order of magnitude more complex... but that's the subject of another post).

Like the San Francisco Enterprise 2.0 conference, the Frankfurt Enterprise 2.0 Summit was mostly a gathering of the faithful, with a few curious attendees exploring the business potential of applying whatever 'Enterprise 2.0' is. While sophistication and understanding of the nuances of the current state of the 2.0 nation has great value, the bigger, simpler picture can be very illusive to the (hopefully) intrigued bystander, and this can be made far more confusing by failure to understand concepts of scale.

One minute we're talking about a few agile wikis, the next Sharepoint as a platform or a substantial Jive SBS or Telligent environment. Our intrepid exploring bystander's background may be a small entrepreneur, a 'single silo' medium sized business, a representative from a small department of a large company, a global business exec tasked with joining multiple silos for greater awareness and efficiency, or any number of other variations. Each use case is very different, and while the technologies selected to solve specific business issues may have a commonality, the context of their application will be crucially different.

The collaboration challenges of a small sized business are likely to be fundamentally different to the needs of an enterprise division: some of the homogenizing evangelistic E2.0 enthusiast language encouraging adoption can be dangerously misleading. Successful collaboration by definition touches most parts of a company or unit - that's the whole point - but tailoring a perfect fit for needs is vital. Loose off the shelf framework application or emulation of something that seems to have worked in another company fails to understand the tight tolerances required in any high performance machine operating efficiently, to use an engineering analogy.

Mature larger companies are often akin to large cities. Los Angeles or London for example have grown over time to consume and incorporate the towns around them, forming a complex network of places within a greater whole. The navigation systems connecting this urban fabric develops to match the travel patterns of inhabitants. Enterprise information architects in equivalent large companies should be like town planners watching traffic patterns closely and anticipating need.

Small business is in contrast often like a single campus community, hopefully rapidly growing and feeding off its surroundings. The commonality is broadband internet connectivity, which like the transport options connecting small campus to large city makes all sorts of interesting collaboration possible. Add in the realities of globalization and associated clustering of business entities and it's easy to see why the concept of business 'performance fabric' is seen as a critical collaborative trade competitive advantage.

Helping planners of collaboration understand these concepts is vitally important to prevent the adoption of milquetoast tentative pilot schemes, which are typically experiments to try and find business value through experimentation.

Peter Drucker, the brilliant management guru who defined the term 'knowledge worker', was clear these employees or partners couldn't be controlled but must instead be motivated and given integrative collaboration environments to excel. Common goals, values and sense of purpose empower them to succeed on their own terms.

As an advocate of decentralization and against 'command and control' management, Drucker was clear knowledge workers would collaborate effectively as a community if driving to specified business objectives. While the new 2.0 technologies realize this and facilitate execution, strategic planning in many cases lags behind broadband application development and are not aligned with Drucker's clarity of thought.