If you take the cynefin approach for working in complex environments you first Probe then Sense and then Respond in order to develop emergent practices. Backward-looking good or best practices are inadequate for changing complex environments. Constant probes of the environment are necessary to see what works.
Enterprise performance should be looked at from the perspective of perpetual Beta. The values and culture can remain stable while the tools and practices keep evolving to take advantage of the situation. Perpetual Beta means an acceptance that we’ll never get to the final release and our learning will never stabilize. This is quite different from perpetual Alpha, or never getting to something concrete, as Jay Cross commented here several years ago:
What’s beta and what’s not is a state of mind. Many people try to go into release prematurely: they put defective product on the market. (By productizing people, I mean locking in on attitudes, structure, opinions, etc.: becoming rigid.)
Life as beta is uplifting. You have the opportunity to streamline things, to respond to feedback, to become a killer app.
Lots of alphas are claiming beta status now. They debut on life’s big stage long before they’re prepared to play the part.
Does perpetual Beta equate to doing lots of pilot projects? Ross Dawson is a strong proponent of pilot projects for implementing Enterprise 2.0 and lists five characteristics of great pilots: Enthusiasm; Roles & Functions; Skills; Personality & Network:
The primary way in which pilots projects will become visible to other people the organization and adapted to new issues is through the personal networks of the pilot team members. Strong personal networks within organizations emerge through both personality, organizational role, and work history (e.g. having worked in multiple divisions or locations). In most organizations networks are fairly strongly correlated to longevity in the organization, meaning that recent recruits are unlikely to have strong personal networks.
On the other hand, Gartner’s Anthony Bradley says that piloting does not make sense for social media projects:
This practice is not prudent for social media where the software complexity should be minimal and the primary goal is to get people interacting. Community participants are fickle and unforgiving (especially external communities). You may only get one shot at catalyzing community formulation. Don’t pilot, test, prototype, or experiment on the community. Don’t artificially restrict participation. The law of numbers is a critical factor in building a thriving and productive community.
A key factor I see in these two articles is that it is important how you define a “pilot” project. If it is viewed as something done on the side and not part of the real business, then it may be doomed to failure. If being involved in pilot projects is a normal part of work, then it fosters a culture of life in perpetual Beta. You can still cancel projects or go in a different direction, but there is a cultural commitment to learning by doing. It’s the difference between our pilot and your pilot.