There is no such thing as best practice for Enterprise 2.0


Dion Hinchcliffe has written a useful post titled Going beyond the hype: Identifying Enterprise 2.0 best practices, reviewing some of the work in the space, and with the intent of building a broader catalog of best practices.

There is already valuable information in the post, and I’m sure Dion’s research will yield useful insights. However I have to say upfront don’t believe in the concept of “best practice” with regard to almost any business activity, particularly with Enterprise 2.0. Managers may love the idea of finding and emulating “best practice”, but trying to do that is a setup to failure.

Just as our individuality as people is often hidden, we are gradually understanding that every organization is different.

For the last year in my future enterprise speeches I have been describing how there are two layers to organizations: the commoditized layer of standardized processes, and the differentiated layer of ad-hoc networks. Best practices can useful apply to standardized processes, but far less so in facilitating connection and collaboration across diverse organizations.


In his post Dion points to my Enterprise 2.0 Implementation Framework and says:

Ross Dawson has done a good job recently on the subject of Enterprise 2.0 methodologies with his Enterprise 2.0 implementation framework. As good as it is, it doesn’t emphasize what seems to be emerging as ground zero issues around risk, control, and trust with Enterprise 2.0. These are some of the key issues that will have to be managed most closely in any major social computing effort.

If these issues don’t appear to be emphasized enough, then I will need to redesign the framework. While Dion and I use slightly different language, anyone who has heard me speak or worked with me on implementing Enterprise 2.0 will know that I repeat ad nauseum that governance is the vital and critical enabler for Enterprise 2.0.

I also repeatedly emphasize the importance of the central element of the framework: Iterate, refine, experiment, and learn. The reason this is so critical is precisely that the solutions are different for every organization. It is impossible to import ‘best practices’ from elsewhere and expect them to work. The key competence is being able to try things in your own organization, see how they work, learn from them, and iterate to discover what works in one specific context.

There is no competitive advantage from using a guidebook of best practice. There is immense potential competitive advantage from going through the challenging and never-ending path of building a truly high-performance organization that fully taps the potential of its people.

I am sure that Dion’s work will prove to be very useful. But even labelling something “best practice” creates a mindset of replicating others’ processes that is likely to lead to failure in implementing Enterprise 2.0.

[UPDATE:] Dion has linked here from his post – he is clearly a genuine believer in the value of debate and discussion (and so absolutely qualifies for Enterprise 2.0 guru status 🙂 ).

  • I tend to agree with Dion. You need best practices in order to understand where the high bar is located and a blueprint of how to get there.
    Not understanding how other companies are generating success seems counter-intuitive. Why reinvent the wheel?
    Then your Iterate, refine, experiment, and learn makes a lot of sense.

  • I had basically the same reaction as you, Ross, when I read Dion’s post this afternoon. I dislike the term “best practices” and generally use “common practices” instead. Because that’s what they are — practices that are common to all organizations that ape another’s proven way of doing something.
    Borrowed processes must be fit to an organization’s unique strategy, culture, and technology set. Deploying a perceived “best practice” without modification (or at least critical review) often yields a poorly performing process and never provides competitive differentiation.

  • Mark, I am absolutely not saying that you don’t study other companies and learn from their experiences, successes, and failures. As such I certainly don’t question the value of Dion’s work.
    However it is a mistake to label them ‘best practices’ in the case of Enterprise 2.0. We can call them ‘lessons learned’, ‘case studies’, ‘success factors’, ‘useful practices’ or many other names.
    Thanks Larry, ‘borrowed processes’ is a phrase that helps us understand why this is problematic.

  • Ross,
    Good post and I think you do make a key point that collections of best practices can only raise you to the greatest common denominator.
    However there is certainly utility in using the knowledge that’s come before you to get to that point.
    In other words, you can (and should) still go after unique competitive advantages while building on the lessons learned and successful techniques of others.

  • I am involved in the AEC Industry (architecture, engineering, construction), where “best practices” continues to be the mantra for success. I agree with Ross and Larry Hawes: “Best practices” are, at best, examples of how others have developed and implemented competitive strategy. They are valuable in planning for resiliency, but without modification, they are unlikely to lead to differentiation.

  • I do agree with you Ross.
    In fact, in the setting up of a business, there are many conflicting drivers. We can come across more than one possible ‘right’ solution.
    Whether the architecture of the new business is a good choice is usually not known until many months or even years later. Changes and additions are inevitable changes after putting the original architecture to test.
    Unfortunately, there is no “cookbook” for enterprise integration solutions. Most integration vendors provide methodologies and best practices, but these instructions tend to be very much geared towards the vendor-provided tool set and often lack treatment of the bigger picture, including underlying guidelines, principles and best practices.